Hi,
>>> 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.
This is exactly the point where things get dangerous, and the point why
developers haven't implemented a label(-like) solution yet.
*at it's simplest, yes*: So implementing something like this would make
your life better, but you would prefer a more complete solution, right?
Complex labels: multiple revisions? multiple directories? both?
Mutable/unmutable labels: so, not just a label, but a label you can move
arround if necessary. With history? (Because you would want to know if
someone decided to move a label to a different version of the file.)
Existing files/new files: Add new files when you're creating your label.
With/without modifications: Being able to store modified files in your
label?
Do you mean these kind of complex ideas?
>
>> 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)
Where's the poison in changing a location, instead of changing a
revision number? As far as I can tell, both mean you have to change 1
argument of the command to a different one.
Look, I understand you don't like changing the location, I really do.
Looking at it from a CVS point-of-view it seems very strange. But other
than that I haven't heard an argument yet. (or I have missed it, maybe I
am blinded by SVN ideas?)
> 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.Also it's
You do know that it's possible to:
1. Set read-only access to the 'tags' (or 'label' in this case) part of
the repository right? You can do this for everyone except for the person
who's going to label things.
2. Set a pre-commit hook (this is actually a feature, not a hack) to
prevent *changing* subdirectories of the 'tags' directory, while
allowing to *add* a new label.
You know, it's not fair to ask for mutable labels in one part of your
message, and complain about mutable labels in a different part of the
same message... Do you want labels to be able to change or not???
> 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.
Please!!! Name the flexibility I'm missing because I've created a copy
instead of just a label. (I seriously can't think of any.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 16 20:31:39 2006