[ On Tuesday, June 20, 2000 at 17:02:50 (-0400), Laird Nelson wrote: ]
> Subject: Re: When is it appropriate to update a major version number?
never in CVS, but perhaps always elsewhere...
> The problem is that version control systems like SCCS (and some versions
> of RCS, to a lesser degree) didn't realize (or didn't care :-)) that
> there were these two identifiers. All you had was the one "revision
> number". That revision number is of course the VC identifier
> *only*--used only to uniquely identify a version of a file and for no
> other purpose--and SCCS probably never intended it to work double duty
> as the CM identifier as well.
I can't speak directly for the SCCS designer(s) of course, but I am
fairly certain that I'm not the only person to ever use the "Release"
part of the SID to commonly identify the current release of an entire
group of files. Unfortunately the authors of the O'Reilly "Applying RCS
and SCCS" book made the mistake of deprecating this practice despite my
attempts to describe its merits to them, and regardless of the fact that
none of the reasons they give are valid in any way whatsoever.
The fact that SCCS branching policy works perfectly with this scheme of
freezing a release is further evidence of its merits....
There is, after all, no reason to ever increment it otherwise, and thus
no reason to ever even store or show it either! :-) I.e. if it had not
been intended to be used as a common release identifier, usually across
a group of files (but of course not necessarily), then the delta tree
would probably have looked more like this:
+- 2.1 --> 2.2 -->
/
1 --> 2 --> 3 --> 4 --> 5 --> 6 -->
\
+- 4.1 --> 4.2 -->
In any case the use of the release number to mark releases simplifies
the simple scenario enough that using symbolic tags on every file is not
only unnecessary, but in fact would greatly complicate an otherwise
simple solution to the problem of release identification.
> But people are clever and crafty and realized that you *could* use this
> VC identifier to store all sorts of policy information in a kind of
> numeric code (2.x usually is shorthand for "part of the second release
> of the product"; 3.1.1.4.5.7.2.3 usually means that you're way off on an
> integration branch somewhere, etc. etc.). All you had to do was define
> rules for how to interpret the numeric code. So they started shoving
> all sorts of information into this poor little revision number and a
> whole software release nomenclature was born (version "2.0" of a product
> is more "mature", so it goes, than version "1.3").
The problem is that people try too hard to encode meaning into the
actual numbers. They should still be keeping one level of indirection,
just as you normally never use an inode number to refer to a file (and
never except in dire circumstances refer to the actual sector numbers to
locate the file contents). Release numbers (and branch numbers) need to
be mapped to a more meaningful release (branch) identifiers.
With SCCS it is still necessary to assign branch numbers if you want to
be able to create multiple branches and manage sets of files with a
common release policy (at least if you hope to enjoy the performance
gains of late branching), so this does imply mapping at least some types
of policy directly into SIDs.
> Along came some latish version of RCS (I'm sure I'm mutilating VC
> history here, but the thought's what counts :-)) which lets you mark
> things with any old label you like (sort of). Voila: the CM
> identifier. Now there was a version control system that *made explicit*
> both the concept of a revision number--the internal VC identifier--and
> the "tag" or "mark" or "label"--the public CM identifier. It was
> expected that the revision number would no longer be used to store the
> CM identifier information, since it was already being used to store the
> VC identifier information.
While symbolic lables have their advantages they often only serve to
unecessarily complicate the internals of any tool like CVS that tries to
use a lower-level revision control system. If CVS, for example, had
kept the relationship between "release" numbers and tags more direct,
and maybe even if "late branching" had been avoided so that branch
numbers could be meaningful, then things would certainly be a lot
different now!
> So, you may ask, if the revision number is so all-fired internal to
> systems like RCS and cvs, why provide the ability to update or mess with
> it at all? A good question which is usually swept under the rug of
> "backwards compatibility". The answer is, more forcefully, that ability
> probably *shouldn't* be provided, but cvs is a good citizen when it
> plays with old RCS files so it gives you the ability to mess around.
> Why even provide the ability to see it? Because in between
> CM-sanctioned versions of files may exist little unblessed revisions of
> files that you discover (usually as a result of a drastic edit) you
> need.
That pretty well sums up the history as I remember it....
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
