[PD-dev] Re: checking in releases

[Hans-Christoph Steiner]

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/ 
gridflow tree.

.hc