[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion "labels" vs. "tags"

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-05-31 22:47:53 CEST

Julian Foad wrote:
> Tim Hill wrote:
>> Yes, this is certainly one way. The main objection I have to the
>> current scheme is that tags are just a convention, and as a result the
>> toolchain cannot use the implied REV# information directly -- it has
>> to be manually imputed by a user and translated by him/her to a REV#
>> for consumption by the toolchain. This makes scripting/automation
>> difficult for some common SVN operations and adds burden to the dev
>> process.
> Please give an example (stating the desired task and showing actual
> commands for doing it) of a situation in which the user has to do this
> "translation".

What I'm getting at is that a tag is not _just_ an alias for a revision number,
and you shouldn't have to convert it to a revision number in order to use it in
common situations. You should be able to specify it directly in the command -
not within the "--revision" parameter, because it isn't just a revision, but
somewhere in the command.

For my example of where you don't have to manually convert it to a revision
number, I'll find the difference between "foo.c" as it was at tag TAG1 and now:

svn diff --old=$TAGS/TAG1 --new=. foo.c

I'll admit again that this syntax is not quite as brief as you might want, but
it's not grossly inappropriate either, is it? Also, I'll admit again that
using an environment variable like that is flakey and not really acceptable in
more complex situations, but that's irrelevant to the argument that the user
needs to translate the tag to a revision number manually.

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 31 22:48:41 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.