B. Smith-Mannschott wrote:
>> It's not a one word name, but I've refer to is as "the revision part of the
>> URL" or the "URL revision specifier".
> That's interesting! You seem to be using "revision" in the same
> fashion as Les Mikesell -- a usage I don't follow at all. I'd be
> curious to know where it originated.
> Every commit in Subversion creates a new /Revision/ of the *entire*
> repository, which typically shares structure with previous revisions.
> (The Subversion book has a nice figure illustrating this.) These
> revisions are ordered and numbered (thus the revision number).
It does, and this is useful in a transactional sense and to maintain
sanity when a newer chunk of the tree is moved under a long-unchanged
branch. But, the part you are interested in is always identified by a
path and a revision number.
>  http://svnbook.red-bean.com/en/1.5/svn.basic.in-action.html#svn.basic.in-action.revs.dia-1
> Given this definition, it makes sense to say that the subtree named by
> some URL has remained unchanged since revision N. (i.e. was last
> changed as part of the Nth commit.)
But it is normally irrelevant that some set of revisions n to
n+something are identical for a particular path. You either know some
number n or lower as a result of remembering/logging why you might want
it back, or you want the current HEAD and if or how much it has advanced
doesn't matter. Why does it matter to you that revisions
N+some_intermediate_value can be named but don't have changes under a
> By the same definition, it would
> *never* have occurred to me to refer to the tail of a Subversion URL
> (or equivalently a subtree of the repository) as the "revision part".
You always need the path for the location in 'space' and the revision
number for the location in 'time'. The contents are what you put there.
> In any event, I'm afraid your solution wouldn't work for us because of
> this clash with our usage.
What other usage can you have for a path and revision number other than
to identify the revision of the thing you want? Since the revision
numbers are global, there can't be any conflicts - that is, a path and
revision number can only refer to one set of contents, which is whatever
was there at the end of the relevant commit. Maybe you'd be better off
thinking of what is called the revision number as a transaction number
since it doesn't mean that contents were revised in all locations, just
that some change happened somewhere in the repository. So what you
always get are the contents of a location at the time the specified
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-19 23:05:59 CEST