On Jun 17, 2005, at 1:30 PM, Rule, Chris wrote:
> After reading all the posts on this subject and pondering, I think
> come to the conclusion that if revision numbers are going to be
> used in
> any communication with end users of the product, then the version
> releases has to include what revision it came from. The end users also
> assume (or have to be told) that revision numbers always increase.
> way, if they see that a particular bug was fixed in revision 1234 but
> they have version 12 that came from revision 1200, then they
> automatically know they don't have the fix. Without the revision
> association to the version, the note that a bug was fixed in
> revision x
> is meaningless to them.
This is an overly simplistic model. It assumes that the 'project' is
a single directory in the repository that progresses forever into the
Most software uses branches and tags for release management. That
means software comes from long-lived branches, which are themselves
independent directories in the repository.
In other words, in the case of Subversion itself, it's meaningless
for someone to say, "I have revision 1200 of the svn client!"
Revision 1200 of what branch or path? Do you have (r1200, /trunk)?
Or perhaps (r1200, /branches/1.2.x)? Those are two completely
different things. If somebody asks me, "so, does that mean I have
the bug fixed by r1153?", there's no way for me to know. I don't
know which paths were changed in that revision, nor whether that
change was ported to my branch.
The revision number alone isn't enough to point to something in the
repository; you need a (revision, path) pair.
Again, take a look at how Subversion (and many other projects) do
their release management. Global numbers are used to specify
specific commits, but they are *not* used to indicate the "version"
of a piece of software. The *names* of the branches and tags are
used for that:
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 17 20:56:41 2005