Tim Hill wrote:
> Felix,
>
> I cannot talk for others, but my intention has _never_ been to replace
> tags with labels, for the very reasons you state. However, you are
> talking about _your_ usage model for subversion. There are many, many
> installs where Subversion is used as little more than a historical
> time-machine for a simple, linear, development cycle. In these simple
> scenarios there is _NO_ "path" co-ordinate to manage, since there are
> no branches at all: everything happens on the trunk (yes, really!).
>
> This comes back to my basic argument: _Simple_ uses of subversion need
> a _simple_ way to symbolically track the timeline. Tags are not
> simple. Hence labels. Simple labels are not suitable for non-linear
> (read: anything except simple) dev cycles, and for that we have tags.
>
> --Tim
>
>
> On Nov 22, 2006, at 8:22 AM, Felix Gilcher wrote:
>
>> John Rouillard <mailto:rouilj@renesys.com> schrieb am Mittwoch, 22.
>> November 2006 16:53:
>>
>>> On Wed, Nov 22, 2006 at 09:49:01AM +0100, Robert Graf-Waczenski wrote:
>>>>> 2. How many labels can be attached to a revision? One? Any number?
>>>>
>>>> Only one. (Remember, we're talking *poor* man's labels here...)
>>>
>>> So adding a new label to the rev destroys the old label? I think this
>>> is wrong. Any given revision should be able to have the same label.
>>> Especially with mutable labels you may need to double label a revision
>>> with a permanent label (say PRODUCTION_2006_11_22) and a floating
>>> lable (CURRENT_PRODUCTION).
>>
>> I see you're trying to replace tags by labels. You really should be
>> aware that if a label is a revision alias it does not carry enough
>> information to identify a production release. Regard subversion as a
>> versioned filesystem. Every resource can be identified by 2
>> coordinates: a paths and a time coordinate. Time is what you specify
>> with the revision argument to the svn command unless HEAD is implied.
>> So what does a label "PRODUCTION" mean if it references revision X?
>> Is it
>>
>> componentY/stable/version1/ at revision X
>>
>> or maybe
>>
>> componentY/development/currently_broken/ at revision X
>>
>> Things get even worse when you have a repository as the apache
>> foundation [1] has: all ASF projects from ANT to xmlgraphics are in a
>> single repository - this is quite a common usecase. What does the
>> label "PRODUCTION" mean in this context?
>>
>> So you'd have to specify
>>
>> svn co -r"APR_PRODUCTION" http://svn.apache.org/repos/asf/apr/apr/trunk/
>>
>> or something similar instead of
>>
>> svn co http://svn.apache.org/repos/asf/apr/apr/tags/1.2.7/
>>
>> Which one of the two is more error prone? Without a doubt the first
>> one. What happens if you confuse which labels belong to which path of
>> your project? You may get build errors or even worse build and
>> release old, buggy versions. The current tagging mechanism is way
>> more suited to identifying frozen revisions such as "PRODUCTION".
>>
>> So what I'm missing in this discussion is what exact benefits do you
>> all expect from labels as revision ids? What about this:
>>
>> Make it possible to specify a svn url in the -r argument. If the
>> argument is an url, it gets replaced by the revision in which the
>> branch/tag was created. There are some corner cases (what happens if
>> the url does not point to branch etc.), but it would be possible to
>> create such an implementation as a shellwrapper to svn for testing
>> purposes.
>>
>>
>> regards
>>
>> felix
>>
>>
>> [1] http://svn.apache.org/repos/asf/
>>
>> --Felix Gilcher
>> Head of IT Development
>>
>> Exozet Berlin GmbH
>> Rotherstraße 20
>> 10245 Berlin
>>
>> eMail: gilcher@exozet.com
>> URL: www.exozet.com
>>
>> ---------------------------------------------------------------------
>> 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
>
>
At work we have a version control client that consolidates multiple
repositories into one interface.
In order to make it easier for some people to handle promotions, we
created a labeling system that was outside of the normal Subversion
system. It consists of a small SqLite database with a table holding
Repository Name, Label Name, Branch and revision.
The people who know Subversion create the shortcut entries, then
everyone else can use the shortcut entries to get to where they're going.
This works well when code is turned over for testing. The testers only
need to look up the project and the "Ready for Test" shortcut. The
system takes them to the correct branch and revision.
Brad Bruce
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 23 15:25:18 2006