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.
Johannes Kilian wrote: > 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 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" :) > One last question: What are multiple vendorbranches good for at all, if > using them will screw up the trunk? (...just wondering...) This would have to be answered by someone who actually uses the cvs import command :) Gerhard