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.
Gerhard Fiedler schrieb: > > You probably can fix your problem quite easily by avoiding cvs import. I > > use the recursive add functions of WinCvs or TortoiseCVS in a situation > > like this. I find them more predictable than import :) 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 - I thought exactly this task could/should be performed by repeated "cvs import" on a vendorbranch. This assumption is true for vendorbranches in general. But the drawback of this solution is, that using multiple vendorbranches screws up the trunk in the way I mentioned in my previous mails due to the behaviour of "cvs import". Thanks for your help enlightning the situation! One last question: What are multiple vendorbranches good for at all, if using them will screw up the trunk? (...just wondering...) Johannes -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser