----- Original Message -----
From: "Richard Lewis" <rtf@jabble.com>
To: <users@subversion.tigris.org>
Sent: Tuesday, May 10, 2005 9:39 AM
Subject: Re: Mnemomic names for revisions
<Snip/>
>>
>> If "labels" or "mnemonic names" is not a first class citizen, then
>> there isn't going to be any support for it in the tools.
>
> Surely not. Don't the guis already provide an easy way to make a tag
> from the trunk? (genuine question as I've only used the command line
> [where i have a simple svn-tag script] and psvn [which doesnt offer
> such a facility but could easily do so])
Alas...it is true.
>> I can't expect TortoiseSVN, viewcvs, joe random web viewer,
>> subclipse to support my random hack to simulate more traditional tag
>> functionality.
>
> why not? i would expect such interfaces to provide things over and
> above the command client. have you asked them to support labels?
How would they know how labels work? It is my random hack. :-)
Why would they agree to my random hack?
>> Heck, with one exception, none of the tools even let
>> you diff tags/R5_3_3456 with tags/R5_4_3455 despite the fact there
>> is command line support for it.
>
> i'm amazed by this! I'm sure it's just matter of time before this is
> provided. what is the advantage of using them over the command line
> if they dont give you this kind of thing for free?
*sigh* Because the command line is a command line and nothing else they do
in on the command line. I didn't say it was rational. It is just the way
people behave. (I use the command line for precisely that reason.)
People will put up with a lot to avoid switching modes.
>> All the tools, though, let you type in a revision ID to get a diff.
>> People just want to be able to type Beta_1 and Beta_2 into the two
>> boxes instead of 23422 and 23942.
>
> surely the answer is to enhance the tools to allow this, rather than
> subversion itself?
How? If it isn't standardized they aren't going to do it. If TortoiseSVN
decides to do it with tsvn:label on individual directories and ViewCVS
decides to do it by adding a magic rev prop called svn:revision-alias, and
Subclipes decides to do it by adding .subclipse file to every directory it
doesn't really get us anywhere.
>> (Well, I take that back, nearly everyone wants at least *that* I
>> think, after that point opinions diverge greatly. :-)
>
> which is why i'd prefer the enhancement in the tool: each tool can
> pick one way to allow extra stuff, and then people use the tool that
> fits their need best, ratehr than putting multiple versions into
> subversion.
See above.
>>
>>>> 4). Labels should be first class citizens. Creating a directory to
>>>> represent a label is really a hack -- especially since you need a
>>>> (so-far unpublished) hook to prevent someone from accidently changing
>>>> what a tag points to in order to do this job correctly.
>>>>
>>>
>>> But you'd also need a way to change which revision your label refers
>>> to, and hence a way to prevent someone changing your label... (surely
>>> if you can't trust your users to leave the tags alone you've got more
>>> problems than adding labels to subversion will support?)
>>
>> Not necessarily. I think a majority of people simply want a map 29845
>> to something more meaningful like R5_build_4. Revisions are
>> immutable.
>
> but would *labels* be immutable? if i make a typo an assign the label
> "r2.0" instead of "r1.0" i'd be screaming for a way to correct the
> mistake. so you need a way to change existing labels, and then a
> hook-script to disallow the change by default seems sensible! so seems
> to me that you wont gain much here.
Well the revision that r1.0 is pointing to is still immutable. :-) You
could still change it with an admin command if you needed to, but that would
be an explicit step.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 05:00:45 2005