On May 5, 2005, at 8:11 AM, Gerco Ballintijn wrote:
> David Gómez wrote:
>
>
>> Hi Gerco ;),
>>
>> On May 04 at 02:33:19, Gerco Ballintijn wrote:
>>
>>>> It's not really a BIG deal, but I would rather avoid having to
>>>> treat some parts of the tree as serving that sort of special
>>>> purpose and not as part of the organizational structure of my
>>>> data.
>>> This seems to be the main reason people want to have revision
>>> labels.
>>> They feel the workspace root *should* be the same as the
>>> repository root.
>>> This desire is however the opposite of the design choice chosen for
>>> the Subversion filesystem.
>>
>> And that's design is right for branches, but IMHO is wrong for tags.
>
> This notion and use seems to rest strongly on a one-project-per-
> repository assumption.
>
> If you have a repository with multiple projects/modules, you
> invariably want
> to tag/label specific projects. However, with revision labels all
> projects
> share all the labels in the repository, leading to same kind of
> name clashes
> and confusion you have with CVS tags, except worse since now even
> unrelated
> projects in the repository share labels.
>
> So, before you know it, there will be hierarchical revision labels for
> different projects within the repository or per-project revision
> labels,
> and we're basically back where we started, except with convoluted
> naming
> strategy.
Well, yes, revision labels could be attached to a path within the
repo. So you can have different labels for different branches at the
same revision. As someone stated earlier, they would like to use
revision labels so they can avoid dealing with long URLs to some tags
folder. They idea being that making a label would not change the HEAD
revision of the repo and would not add to the namespace of the
subversion filesystem, think of the revision labels as coming from a
separate index file, a file that would be maintained by the
subversion tools, so that svndumpfilter and most repo manipulations
would keep the labels referring to the correct content.
I think one possible implementation of revision labels could be like
providing a root to a subversion URL *and* the @123 revision suffix,
but allowing any user supplied path info to be placed between those
two bits.
e.g.
MyLabel = svn://Server/myProj/trunk/@543
svn cat -rMyLabel svn:src/test.c
note the use of a relative URL in the svn command. That command
would be equivalent to:
svn cat svn://Server/myProj/trunk/src/test.c_at_543
So if you didn't want to have labels associated with paths in the
repo, you could just put all your labels at the root. e.g. Label =
svn://Server/@634
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 5 16:00:51 2005