Re: CVS Version CHange

[david]

Greg Woods:
> 
> In CVS the release number of RCS-Id is like any useless and almost
> atrophied organ -- however it's impossible to give it up without
> also giving up backwards compatability of the internal repository
> structure.
>
It also is necessary as a "magic cookie" - an otherwise meaningless
but ordered reference to each revision of a file.  When referring to
releases, one should always use symbolic tags, but when testing it
is often necessary to know which particular revision one is using.

I've often found it useful to correlate the results of "cvs annotate"
and "cvs diff" with the results of "cvs log".  Sometimes there will
be code in a program that isn't working just right, and I don't know
what it was supposed to be doing, so tracking it down to the revision
that introduced it and getting the PR number out of the checkin
comment is very useful.

So, we can't get rid of the ability to see the revision numbers, although
I wouldn't complain if we got rid of the ability to specify them.
 
> Perhaps CVS should just hide the "1." from view, though doing that in
> the RCS keyword expansion would be fraught with problems too and it may
> still be needed in many command-line parameters.  Perhaps translating it
> into a symbolic value such as "TRUNK." wherever visible would be better.
>
Could be.  The RCS revision number looks too much like a standard sort
of release designation, and that leads to trouble.  It appears to
contain more information than is needed to specify a revision.  I
like the idea of giving the revisions simple numbers (as Subversion
does) to show their arbitrariness.
 
> > I agree that tags should be the _preferred_ way to do this, but I really do
> > not see why you are so vehemently opposed to manually forcing revision
> > numbers under special circumstances. What problems will this introduce?
>
While I'm not as vehement as Greg, I don't see any reason to manually
force revision numbers.  I see no point in it.  At best you can have
a crude, awkward, and easy-to-get-wrong substitute to what you can
do easily and reliably with tags.
 
> > Again, under special circumstances, not under day-to-day use.
> 
> The problem is that once it's been done then it becomes an every-day
> issue from then to the end of the life of the repository (unless it's
> undone, of course).
>
It can be very hard to undo.  I don't think that having such revision
numbers is that much of a problem, but if they are to mean anything
whatsoever it is an everyday issue, and it's simply not worth it.
 
> > The major drawback with tags is that they can be moved or deleted, without
> > any history of the changes.
> 
> If these sorts of things worry you then perhaps CVS is not the right
> tool for your needs.  :-)
>
Sometimes there is no "right" tool, but we've argued about that before.
 
> CVS is not very much of a policy enforcement tool, if any of one at all.
> (despite the abilities of features such as "taginfo" scripting hooks)
>
On the other hand, it is nice to have ways to avoid making irretrievable
mistakes (and removing or moving a tag can be that).  I've made many
of those in my lifetime despite knowing better.  As the CVS admin, I
managed to remove a branch tag from a directory once, and then modified
one of my principles ("Never hit the return/enter key before you
carefully examined what you've just typed") for doing such by adding
the clause "and it doesn't count as careful examination if anybody is
talking to you at the time".

Fortunately, later versions of CVS have made the particular error I
made impossible, but "taginfo" is still a reasonable thing to consider.
 
-- 
Now building a CVS reference site at http://www.thornleyware.com
address@hidden