Re: Major revision number compatibility?

[Eric Siegerman]

On Tue, Jan 29, 2002 at 01:46:52PM +0100, Thomas Eliassson wrote:
> Now when we start using CVS I see that we can 
> use 'cvs commit -r2.4 file.txt' to commit a file with a specific 
> revision number (in the example 2.4). Is this safe, or may we run into 
> some trouble later on?

This is safe, in the sense that CVS will handle it just fine; it
won't corrupt your data or start spitting error messages.

The problem (or *a* problem; there may be others) is that
forevermore, every time someone adds a new file, they'll have to
remember to say:
        cvs add -r whatever_the_major_revision_number_is_right_now myfile

Because CVS provides no way to specify that new files should get
a major revision number other than 1, people have to remember to
do it manually.  *Every* time.  If they forget -- and they will,
being human -- your revision-numbering scheme goes out the
window.

Oh, here's another problem.  What about minor releases?  Suppose
you want to release Version 2.3 of your software, but some file
is already up to CVS revision 2.17.  It is then *impossible* to
encode the release-version number in that file's CVS revision
number -- revision 2.3 is ancient history.

Basically, CVS (because of its RCS heritage) gives you enough
control over revision numbers to make you *think* you can use
them to encode version info, but not enough control to let you
encode it robustly.  And there's not much sympathy for "fixing"
the "problem", since CVS provides a better mechanism anyway, i.e.
tags.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
One ring to rule the mall.
        - Movie review headline, eye Magazine