[cvsnt] Multiple vendor branches
Jo.Kilian at gmx.de
Wed Mar 14 08:28:12 GMT 2007
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...)
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
More information about the cvsnt