Precisely. I raised this issue last year when pushing for some sort of
label scheme, and my motivation was not for CVS aliases. I will
re-iterate what I see as the major motivational reason for labels: the
reduction in the need to manually enter revision numbers.
Here's what I discussed with Julian Ford last year...
Essentially, I view an SVN repo as a two-dimensional space of a
directory/file tree dimension and a rev# dimension. A file/folder in a
repo can thus be located by an (URL,REV#) co-ordinate pair, and this is
typically done in many svn commands (the REV# many times being implied).
Now, in this model I view a tag as being (partly), a translation of an
(URL,REV#) pair directly into an URL. This provides a mnemonic and
visible record of this co-ordinate in the repo.
However, there is one problem with this translation: tags are not
first-class objects within SVN, they are just conventions. There is no
command-line way that I can directly express "use the REV# implied by
this tag" in SVN. Instead, I have to manually discover the rev# and then
manually enter it into an SVN command. This is cumbersome, error-prone
and not very scriptable.
I assert that THIS is the missing functionality in SVN and, in reality,
this is what people really need when they ask for labels: the ability to
tell SVN "use the rev# implied by this tag" directly in SVN commands in
the same way that HEAD etc are used today.
Translation: Tags express rev#s but are only used for OUTPUT. There is
an additional need for these rev#s to be available for INPUT into SVN
commands without manual transcribing.
--Tim
Ben Collins-Sussman wrote:
>You know, we already have the ability to attach arbitrary unversioned
>metadata to revisions. And that's exactly the sort of "label" that
>David Gale is talking about. If we had the ability to search
>revisions by querying revprops, we'd be done. David could invent all
>the revprops he wanted, and search on those revprops to locate
>specific revision numbers.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 27 23:23:23 2006