Mike Jellison wrote:
> I don't understand why updating a major version number is a bad thing.
Conceptually speaking, there are two identifiers for any file under
configuration management: the
identifier-that-the-version-control-system-assigns-to-it-to-keep-track-of-it-for-its-own-purposes
and the
identifier-that-is-applied-when-your-configuration-management-process-determines-that-it-should-be-applied.
I'll call the first one the version control (VC) identifier and the
other the configuration management (CM) identifier.
When someone says they want to bump the revision number from 1.X to 2.X,
they are actually saying something like this:
"My project or file has reached a point where my configuration
management policy says that I need to "bless" it with a new identifier."
For example, their project may be ready for release, or their bug fix
tasks may be all completed, etc. Note that they are *NOT* saying the
following:
"I don't trust my version control system to know what it's doing, so I
want to change the internal mechanisms it uses to keep track of files."
...even though by monkeying with the revision numbers that's **exactly**
what they're saying. Hold that thought in memory for a moment.
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.
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").
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.
So, recalling the earlier thought ("My project is ready to be blessed
with a new identifier for a reason dictated by my CM policy"), in RCS
you would tag certain *revisions* of certain files (identified by their
significant-only-to-RCS revision numbers) with the CM identifier--the
tag--of your choice, which could be a hell of a lot more expressive than
"2.X". For example, in my dumb example above you would tag the current
revisions (1.3, 1.56, 1.2947, etc.) of your files with, say, the tag
"RELEASE_2_20000620". Now when you refer to files, you refer to them
using the public/CM identifier--RELEASE_2_20000620--rather than the by
comparison rather scrawny revision number (which can now be left alone
by human beings to do its simple job of incrementing itself and keeping
track of branches).
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.
Finally, to state the obvious by now, cvs uses the notion of a tag as
the CM identifier and the revision number as the VC identifier.
Interestingly enough, you'll note that cvs handles vendor branches by
monkeying with the revision number which it has every right in the world
to do, as that number's only job is to uniquely identify a file (nothing
more, nothing less). So tag anything that might be interesting to you
later and get in the habit of referring to things by tags, not by
revision numbers.
So: a long answer, but I hope a useful one.
Cheers,
Laird
