[cvsnt] Multiple vendor branches
Bo.Berglund at system3r.se
Tue Mar 13 16:12:11 GMT 2007
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
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.
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On Behalf
Of Gerhard Fiedler
Sent: den 13 mars 2007 12:20
To: cvsnt at cvsnt.org
Subject: Re: [cvsnt] Multiple vendor branches
Johannes Kilian wrote:
>> If I understand you correctly, this shouldn't be. What says the cvs
>> of one of these rogue files?
> Yes you understood correct: this shouldn't be.
> I'm not sure whether this is a "special behaviour" of vendorbranches
> of "cvs import" - or a combination of both.
Ah, now I think I got it, and it seems I was wrong.
> 2. New files on the second vendorbranch (files that are new in
> comparison to the initial vendorbranch) were imported in that way that
> they exist as revision 1.1 on the trunk and 126.96.36.199 on the second
> vendorbranch. They don't exist on the initial vendorbranch.
I think this is how cvs import works. I normally don't use it, so
else with more experience with it may be able to confirm (or correct)
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 :)
cvsnt mailing list
cvsnt at cvsnt.org
More information about the cvsnt