[BOOK] Global revisions and different projects

[Alexander Holler <ah...@ahsoftware.de>]

I'm just talked to an already left Ben Collins-Sussman in the IRC about 
that subject, so I'm completing my thoughts here. ;)

As background: I'm coming from cvs.

Because I'm stumbled somewhat late about the fact that revision numbers 
are global, even inbetween different projects, I would find it good if 
that would be mentioned in chapter 2.
The concept of the global revision number (on trees) is explained really 
good, it's just not mentioned that this can be confusing when using one 
repository for different projects.

E.g. reading chapter 2 I'm always thought about one tree with one 
revision number conaining one project. Even the picture 2.6 has 2 
projects, in all contexts just the impact on one project is explained. 
So it's easy to oversee the impact on different projects in one repository.

But because that (a global rev inbeetween different projects) could be 
confusing, a note (in chapter 2) that for different projects, different 
repositories could make sense, would be helpful.

Kind regards,

Alexander Holler

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [BOOK] Global revisions and different projects

[John Peacock <jp...@rowman.com>]

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