Brian Huddleston <brianh@huddleston.net> writes:
>> export FOO=http://myserver/repos/tags/FOO
>> export BAR=http://myserver/repos/tags/BAR
>>
>> svn diff $FOO/myfile.cc $BAR/myfile.cc
>
> Repeat as necessary for each tag in your repository. Mine has 2558 at
> present. :-) Then write a nice hook script to push the new list of
> tags out to all the client machines (we do know them all right?) so
> that everyone can be consistent.
instead of an explicit push you'd keep the list in a property, then
the usual update would suffice
> The above also assumes that you're on a unix box (you can also do it
> under Windows, but it much clunkier) and that you're using the command
> line tools.
(you could install cygwin or msys on windows)
>
> 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])
> 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?
> 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?
> 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?
> (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.
>
>>> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 10 16:53:55 2005