(Previous mail sent directly, brought back to the list:)
> Phyrefly wrote:
> >> What's the big difference?
> >
> > I repeat (again): ease of use for the non-technical.
> k, I understand, this is probably the most convincing and best
> understood argument (I guess).
This seems to be the one point everyone is not getting, or ignoring,
by showing, in some cases, very complex solutions to the use cases I
am suggesting would be made easier by labels.
>> My users check out latest code from trunk, and an earlier version from
>> trunk. Why should they be forced to create and use a branch (which is
>> what a tag is) just to make a revision number easier to remember
>> (which is all a tag should be)?
> So you say this:
> It's purely an alias for a revision number, like (myLabel == 213) and
> nothing more?
At it's simplest, yes. There are some more complex ideas being
suggested too, which I think would be a benefit (complex labels,
mutable labels etc), but this is the simplest version, yes.
> Do you mind explaining a Use Case for this? (I'm sorry, you probably
> already mentioned one, but I can't find it...)
The most simple example is the export of a labelled version of a
project in the repo. Tim has presented a lot of more involved ones.
The general case is being able to replace an arbitrary number with a
sensible word in all other svn commands (without changing the URL, the
command syntax or anything else, see my first point)
>> As to the 8 different versions of "label" - each suggestion you gave
>> is a limitation on a global solution, not a different solution
>> entirely.
>
>True, I was only suggesting that with this many people and this many
>different versioning systems it's (almost) impossible to find a solution
>which fits into everyone's expectations.
>> If it was deemed important to limit this functionality
>> programatically, it would be easy enough to add a few lines to the
>> config file.
>> ([allow_complex_tags=true/false][allow_mutable_tags=true/false]
> > etc. If any history was needed for labels at all, it would merely be
> > a list of revision numbers, hardly much overhead at all, especially
> > when compared to maintaining a new branch.
> Please don't look at it as a branch. It's only a branch if you use it
> like a branch.
>
> It's not always a marble if it's round, only if you would play like you
> would with a marble.
It's a branch if it's implemented like a branch. Because it's
possible to treat it like a branch (commit further revisions, etc) - I
have to configure more things to stop it being used as one. It's a
hack, basically, to make a branch feel a little like a label... in the
implementation, it's a branch, with everything that implies. But most
importantly, it's NOT just a link to a prior revision, it's a copy of
that revision in another place in the repo, meaning that it loses some
of the flexibility that a label would have.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 13:37:16 2006