Since this seems to be a part of a general argument pattern. I thought I
would respond.
----- Original Message -----
From: "Richard Lewis" <rtf@jabble.com>
To: <users@subversion.tigris.org>
Sent: Sunday, May 08, 2005 6:20 AM
Subject: Re: Mnemomic names for revisions
> David Weintraub <qazwart@gmail.com> writes:
>
>> 3). We want to be able to create labels, do diffs, etc., without
>> having to bother with URLs Doing "svn diff -rFOO:BAR myfile.cc" is a
>> heck of a lot easier than:
>>
>> svn diff http://myserver/repos/tags/FOO/dir1/dir2/dir3/myfile.cc
>> http://myserver/repos/tags/BAR/dir1/dir2/dir3/myfile.cc
>
> 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.
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.
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. I can't expect
TortoiseSVN, viewcvs, joe random web viewer, subclipse to support my random
hack to simulate more traditional tag functionality. 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.
Given the fact that the tags/ directory itself is pure convetion I guess
that isn't too surprising. Writing a nice easy to use GUI that diffs
arbitrary directory 1 to arbitrary directory 2 is probably difficult at
best.
At my shop even the developers rarely drop to the command line. I do, of
course, but I am the exception rather than the rule.
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.
(Well, I take that back, nearly everyone wants at least *that* I think,
after that point opinions diverge greatly. :-)
>> 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.
Branches-called-tags are not. It isn't about trust or preventing malicious
behavior its about preventing accidents. Unless you're a small enough shop
that someone is watching every commit, or a large enough shop to afford to
have someone dedicate their time to watching "tag" commits you're stuck with
doing a hook-script.
The hook script is doable, certainly, that's how we're setup, but it strikes
many people with a traditional SCM background as a bit of a hack to have to
write a script to enforce a semantic which they believe to be inherent to
the idea of a tag.
>>
>> =====
>> I think that the arguments made by the pro-label side for arguments 3
>> & 4 are quite reasonable. Having to use a full URL just to do a diff
>> can be a problem.
>
> I see why labels are useful, but I dont understand why you don't just
> write a shell script to do all this using properties (ie store the
> labels in property on the repository root, and get the labels using
> propget)
Slow would be the primary argument. Lots of custom code would be the other.
There is no svn speak to this point, for "Give me all the files that have a
propery named foo that is set equal to bar.
The argument about tool support also holds. Even assuming support for a
label querying, the labelling idea is a hack that shop X put together to get
the semantics they wanted and none of the tools are going to let them see
the difference between Release_1 and Release_2.
If you've got the staff and the time to write the tools yourself, then
you're always fine, but if you don't you're out of luck.
>> 3). Have an "svn label" command as an alias of the "svn copy". Well,
>> not quite an alias, but more of a shortcut:
>>
>> $ svn label FOO
>>
>> would be translated to
>>
>> $ svn copy <current URL> <URL>/tags/<path>
>>
>> or whatever is needed to actually create the tag directory.
>>
>> Sounds good?
>
> isn't this trivial to do by hand (eg as a shell script)?
Yes. Ideally, though, this would be a first class citizen and would have a
separate identity in the history. It could also keep people who thought
they were tagging, but typo'd the url from dumping stuff in the wrong
directory. Yes, as goes the oft repeated argument, "This is version
control. Just undo it.", but if it is simple for the tool to keep you from
doing something stupid then the tool should help keep you from doing
something stupid. :-)
That is, my ever so humble opinion at least. Do with it what you may.
-Brian
>
> ---------------------------------------------------------------------
> 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 Mon May 9 07:34:57 2005