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

RE: Roadmap for 1.1

From: Barry Scott <barry_at_barrys-emacs.org>
Date: 2004-04-04 16:52:48 CEST

At 02-04-2004 19:10, Sander Rijken wrote:
>On Fri, 2004-04-02 at 20:00, andy.glew@amd.com wrote:
> > SVN's copies allow you to map label name -> revision.
> >
> > People often want to go the other way: map revision -> label name.
> >
> > Consider Brad Appleton's "floating tag" usage model.
> > (Everyone should read what Brad has written about version control.)
>So what if you would include the revision number in the tag?
>You want this in particular for releases I think, so erm branch to
>something like repos/releases/version-1.0-r1234/

The problem is that as a tools developer I have no idea what conventions
a repos is using. To my mind any solution to the "label" problem has
to be embodied in an SVN API that I can call.

Being able to give a symbolic name to a revision is one possible solution.
Perforce, for example has such a scheme, its names are global to a repo.
SourceSafe on the other hand treats labels as local to a directory and
visible in its and its childs history.

As others have said when looking at the history of a file I want to know
what revisions correspond to key project events,"labels", so I can diff
say the 0.3.0 with 0.4.3, etc.

The current copy to tags method is no help, even if I could work out that
such a tags directory existed and where it was it would be very slow to
execute if the repo is not local.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Apr 4 16:54:00 2004

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

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