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

Symbolic names for revisions

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2004-04-16 00:07:12 CEST

On the user list a discussion (Road map 1.1) about labels came up.
Ben suggested discussion on this list before raising an issue.

Users expect to see the symbol name (label) when viewing the
history of an item. Users expect to be able to use the symbolic
name where a revision number can be used.

Use of svn cp to /tags cannot solve the problem as its an expensive
operation to work out where an item was copied to.

One suggestion was to be able to give symbolic names to revisions
and support returning the symbolic names in the appropriate APIs.

Are the names globally unique in a repository?
* are duplicates allowed? If so what is the resolution order?

Are the names associated with an item in the repository?
* would need to show up in the history of an contained item
   to be useful.

Below is one of Ben's comments on the feature.


Here is Ben's comment on the suggestion:

From: Ben Collins-Sussman <sussman@collab.net>
To: Jeremy Pereira <jeremyp@jeremyp.net>
Cc: "C.A.T.Magic" <c.a.t.magic@gmx.at ...snip... Scott
Subject: Re: Roadmap for 1.1

On Mon, 2004-04-05 at 09:22, Jeremy Pereira wrote:
> (revision
> aliases are simple to implement so there is probably a philosophical
> reason why the developers haven't implemented them).

Not really, it just never occurred to us as important. We've been using
the global revision numbers themselves for so long (to do merges,
annotate issues, etc), we've never felt the "itch" to refer to them by
human names.

This wouldn't be very hard to write. In the general case, we need some
sort of API for finding all revisions that contain a specific property
name/value. At the moment, this is already happening when we convert a
date to a revision. The RA->get_dated_revision() API scans all the
revisions, reading their 'svn:date" property and returns exactly one
revision. We just need to generalize this idea. It just that nobody's
bothered to do it yet.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 16 00:07:34 2004

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.