Alexander Holler wrote:
> Because I'm stumbled somewhat late about the fact that revision numbers
> are global, even in between different projects, I would find it good if
> that would be mentioned in chapter 2.
I agree with the suggestion to improve the docs, but I just wanted to throw in
my 2 cents here, reading between the lines of your e-mail. Something that is
commonly done in CVS is using the $Revision$ keyword as an version number for a
file, even going so far as to expose that information (for example by using that
as the $VERSION number in a Perl module).
However, as I found out on the CVSNT list from the main developer of that
branch, the $Revision$ number does not monotonically increase (especially when
dealing with branches) in a fashion that is completely compatible with the usage
as a version number. In particular, use of multiple vendor imports or multiple
branches within CVS will not do what you would think. Also, altering the
Revision through 'cvs admin' commands can lead to lost revisions and corrupted
RCS files. Essentially, the CVS $Revision$ is an internal book-keeping value
which looks something like a version, and within a relatively narrow set of
usages can actually be used as a version number.
Similary, Subversions $Rev$ keyword is only guaranteed to be a monotonically
increasing value, only this time at the repository level rather than at the file
level. It is an internal representation of continued changes to the entire
repository, and does not (even with a single project repository) lend itself to
use as a version number. It doesn't map well to a project version at all (less
so than the CVS $Revision$).
While many people have used $Revision$ in CVS to substitute for a version
number, and haven't had problems, that doesn't mean that the Subversion $Rev$
keyword will lend itself to the same purpose. A module version is better stored
in metadata (for example as a property), rather than using the $Rev$ value raw
(or even cooked) as a substitute.
I've been working on a replacement for the current keyword handling which may
make it possible to eventually substitute keyword from a property value (don't
hold your breath), which would be ideal for usage in this fashion.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 13 00:13:00 2005