Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Wed, 14 Mar 2007 10:10:10 -0300, Gerhard Fiedler wrote: >> Bo Berglund schrieb: >>>> I also do this, and if I want to store the next release of the code I >>>> first erase the sandbox using Windows Explorer (but keeping the CVS >>>> subdir). Then I put all the files for the next release into the >>>> sandbox. Then using WinCvs i locate the broken link files (which have >>>> been removed in the next release) and do a cvs remove on them. All >>>> files that are unknown to CVS are then cvs added. Finally I do a cvs >>>> update then commit the new release. This way all files will be handled >>>> by the system and I will get the new release exactly as it was >>>> published. >> >> That's what I also thought what might be a solution to my problem. I >> just wanted to avoid all those manual steps of adding new files and >> identifying and removing removed files > > It sounds more complicated than it is. With WinCvs and flat view sorted by > file status, it's really quite straightforward. It doesn't take much longer > than it takes you to think "aha, they added this and removed that, hm, > interesting" :) > Gerhard, Do you still maintain a vendor branch for their code? So if I understand correctly, you're checking out their code on the vendor branch and manually deleting all the files except the CVS sub-dirs. Then installing the update to the sandbox and then committing the changes, add new files and removing deleted ones? I think I like it. I've been using import but their are a lot steps involved and the potential for screwup is always large. Thanks, Rick