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
Received on Wed Nov 22 18:39:03 2006