RE: Mnemonic names for revisions

I really don't see the problem of creating tags as a tag directory. Don't
think of them as directories as much as a listing of your tags. In fact,
Subversion's implementation of tags can be better than simply aliasing a
revision number with a more mnemonic name.

You can have a hierarchy of tags. In many version control systems that have
tags, you have tags for daily builds, for weekly builds, for builds sent to
QA, for candidate releases, etc. Unless you use a naming scheme, there's no
difference between these tags and you could end up with hundreds -- if not
thousands -- of tags. Under Subversion, each type of tag could go into its
own tag subdirectory. Daily builds could be under ./tags/daily, weekly
builds under ./tags/weekly, releases under ./tags/releases, etc. Heck, you
could even give users their own tag subdirectory. They could save their work
as a tag under any name they'd like without affecting you.

Because each tag is a visible directory, you can easily get a listing of all
the tags with the svnlook command, or by just browsing the directory. If you
have a hierarchy of tags, you can easily just see the tags you're interested
in. How do you even get a listing of valid tags in CVS or RCS?

You can easily "delete" an obsolete tag by simply removing it from the tags
directory. Then, if you realized you need that "obsolete" tag back, you can
easily undelete it. I don't remember how to delete tags from RCS or CVS, but
if you could, you certainly couldn't bring them back.

The only complaint I have about the way Subversion implements tags. They're
simply another branch. It's too easy for someone to checkout a working
directory from your tags directory and create a new version of that tag. If
you use "svn checkout" to checkout from what you thought was a stable tag
area, you might be surprised to find changes since you first tagged that
directory.

Yes, you could use hooks to prevent users from committing new changes in the
tags directory, but I'd rather have something built in. In ClearCase, you
could "lock" a tag and it couldn't be moved to a new version of the file
until you unlock it. It would be nice if there was a way in Subversion to
"lock" a tag as soon as it is created (maybe have this as a default action).
That way, a developer can't simply modify the files on that tag. To modify a
file in a tagged directory, you'd have to get the administrator's permission
first.

-----Original Message-----
From: David Gómez [mailto:david@pleyades.net]
Sent: Friday, April 29, 2005 1:27 PM
To: users@subversion.tigris.org
Subject: Mnemomic names for revisions

Hi all ;),

I just was finishing reading the Subversion book before setting up my
repositories, and wasn't very happy about the tags naming scheme... ;). So
i've been browsing the list archives, and i've find out that more subversion
users already thought about this particular problem...

I know the topic has been already discussed in the list, but i'm not sure
about
the results:

Are mnemonic names for releases going to be implemented in future subversion
releases?

Call it mnemonic names, tags, aliases, whatever... I think it would be very
useful to associate names like myproject-1.0 to a certain revision number,
and
be able to use it in the -r parameter for the svn client.

One of the arguments about using the tags directory and 'svn copy' is that
it's
gives you a tag mnemonic and that svn copy is a inexpensive operation....,
but
it's not the same, because i'm _forced_ to create a tags directory to manage
tags, and that's precisely what i don't want. Tags should be more simple
than
that, just like revision keywords PREV, HEAD, BASE and COMITTED, a mapping
from a literal to a revision number.

Regards,

-- 
David Gómez                                      Jabber ID:
davidge@jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org