On Aug 1, 2006, at 4:13 PM, Mathieu Bouchard wrote:
On Sun, 23 Jul 2006, [EMAIL PROTECTED] 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
_______________________________________________
PD-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
