On Aug 1, 2006, at 4:13 PM, Mathieu Bouchard wrote:

On Sun, 23 Jul 2006, hans@eds.org wrote:

...

I see that you are working on PDP. FYI: Tom doesn't maintain the code in that CVS, its just an import. He's released a 0.12.5. Rather than checking in changes to the code that's there, which will either have to be discarded or merged, how about importing the new version?

I haven't figured out "cvs import" yet. I tried doing it on GridFlow 0.8.2 (an obsolete version but then I thought it'd be good to have every release in the pd CVS). The importing of GridFlow 0.8.1 was done manually using a zillion commits, which I'd like to avoid in the future. Do I have to do "cvs remove" on all the 0.8.1 files first? If so, that could explain why "cvs import" didn't work (???).

I've been trying to figure out "cvs import" using http:// ximbiot.com/cvs/manual/cvs-1.11.22/cvs.html; is that manual sufficiently explaining it?

I cc'ed the dev list since others may also shed light and/or benefit from this discussion.

I think what "cvs import" is meant for is when you are using third party code but making minor modifications to it. Pd's use of portaudio would be the perfect example. Then when you want to upgrade portaudio, you would use "cvs import" to handle the merge so that your changes are included. Ideally, this is the way that we would handle the pd/portaudio tree.

If you are basically just mirroring and don't care about blowing away any changes that might have been checked in since the previous import, then you can just copy the new release to the CVS-controlled directory and do one big "cvs commit" for the whole externals/ gridflow tree.

.hc