[cvsnt] Re: "cvs commit -r " problem

Fri Jul 22 17:54:39 BST 2005

Rick Genter wrote:
>>-----Original Message-----
>>From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org] On
> 
> Behalf Of Matt Schuckmann
> 
>>Sent: Friday, July 22, 2005 12:31 PM
>>To: cvsnt at cvsnt.org cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook
>>Subject: [cvsnt] Re: "cvs commit -r " problem
>>
>>
>>I've heard people on this board say exactly what Bo said many times
> 
> and it
> 
>>bothers me.
>>While I agree that there is rarely (possibly never) any reason for a
> 
> user to
> 
>>require a specific revision number I don't agree that revision numbers
> 
> are
> 
>>strictly internal.
>>They are a way of refering to a historical version of the file, the
> 
> most
> 
>>common use of them might be for a code review in which the reviewee
> 
> tells
> 
>>the reviewers to look at specific revisions of specific files. If the
>>revision numbers are going to go away in the future how will we refer
> 
> to
> 
>>specific historical versions of a file?
>>
>>Matt S.
> 
> 
> Tags.
> 

Tags? You're joking, right?

I agree with Matt: I need a logical way of specifying a particular point 
in a file's history for all kinds of configuration management purposes.

Speaking from a certification-driven environment viewpoint ...

Why in the heck would I want to tag every single incremental revision of 
a file when the automatically assigned revision number is a perfectly 
valid way of doing so?
The whole point of CVS is to reliably and automatically maintain 
historical revisions of files. Doing that is completely pointless if you 
can't track and identify those revisions. And what better way than with 
sequentially assigned revision numbers? Maybe I'm missing something 
fundamental, but if we lose revision numbers then we've lost half the 
point of CVS in the first place.

Please ... if it ain't broke (and it isn't), don't fix it.

j.