Re: Updating revision number on a branch.

[Alan Dayley]

Heather wrote:

> Heh, I think you misunderstood my second message.  I meant that we
> wanted to make the change for cosmetic reasons, not that it WAS a
> cosmetic change.  After reading on how the branches are created, I
> understand why you don't want to mess with those.  However, I don't
> understand what the problem is with updating the revision numbers on
> the main trunk.  Am I seriously missing something because I see people
> doing this all the time? :)  Or are all these people just treading into
> dangerous waters?  And yes, we know how to use symbolic tags and have
> been using them, so the issue isn't that we don't know how to do that.
> This is just a curiosity thing at this point in time.  

As a general rule, I resist any changes "for cosmetic reasons" to a 
non-cosmetic process, tool or data.

For one example of a possible problem, see here: 
http://www.cvsnt.org/pipermail/cvsnt/2004-August/014385.html

ie. If you manually bump your trunk from 1.x to 2.x, will you always 
remember to bump the files in any folder (module) that gets added as 
your code base evolves?  Because, according to the link above, the files 
in that new folder will now be at 1.1.  Suddenly your 2.x revisions have 
1.x ones mixed in.  Now you need not just a tag naming policy but also a 
revision policy and procedure.

So, maybe manually bumping revision numbers does not "break" anything 
(despite reports of orphaned branches, other possible problems and 
experienced CVS people stating it should not be done).  But as soon as 
you do it, you are committing to control and maintain the meaning of 
that number instead of just letting CVS do what it wants with it.  If 
you want to take on more manual work, go for it.  Personally, I don't 
have the time.

Just my input as a CVS admin.

Alan