[PD-dev] Re: checking in releases
hans at eds.org
Tue Aug 1 22:43:12 CEST 2006
On Aug 1, 2006, at 4:13 PM, Mathieu Bouchard wrote:
> On Sun, 23 Jul 2006, hans at 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/
More information about the Pd-dev