You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Barry Scott <ba...@barrys-emacs.org> on 2004/04/15 22:07:12 UTC
Symbolic names for revisions
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.
Barry
Here is Ben's comment on the suggestion:
From: Ben Collins-Sussman <su...@collab.net>
To: Jeremy Pereira <je...@jeremyp.net>
Cc: "C.A.T.Magic" <c.a.t.magic@gmx.at ...snip... Scott
<ba...@barrys-emacs.org>
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
Re: Symbolic names for revisions
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sun, 2004-04-18 at 14:47, Barry Scott wrote:
> One of the use cases that I want to solve is being able to know which
> tags an item belongs to though out its history. This is an expensive
> operation in Subversion, basically you have to retrieve all the
> changed paths data and notice when the item you care about is referenced,
> taking into account renames etc.
>
> Some form of symbolic naming could help with this problem.
>
> A way of telling subversion that this copy is special (a tag)
> could help as well.
Here's where the conversation gets fuzzy to me.
I would like to know:
* The precise nature of the query you want to be able to make. (Is it
"which tags does any revision of this file live in" or is it "which tags
does a particular revision of this file live in"? Justify your answer
with a use case.)
* How "some form of symbolic naming" would help. (I don't think
Branko's recent proposal would help, for instance.)
* How "a way of telling subversion that this copy is special" would
help.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Symbolic names for revisions
Posted by Barry Scott <ba...@barrys-emacs.org>.
At 16-04-2004 03:42, Ben Gollmer wrote:
>I have trouble believing that people can't make Subversion work for them -
>it's totally flexible
Its not totally flexible. Its a database that has optimized some queries,
but others are very expensive.
>and scriptable. It seems that old work habits are the main roadblock.
One of the use cases that I want to solve is being able to know which
tags an item belongs to though out its history. This is an expensive
operation in Subversion, basically you have to retrieve all the
changed paths data and notice when the item you care about is referenced,
taking into account renames etc.
Some form of symbolic naming could help with this problem.
A way of telling subversion that this copy is special (a tag)
could help as well.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Symbolic names for revisions
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>Perhaps the solution is to reduce the "freeness" of the tagging and
>>branching scheme. If there was a fixed, enforced naming scheme for tags,
>>client interfaces could provide more facilities to the user. But it
>>would be against the spirit of Subversion... but.. why not creating some
>>way an administrator could write the branching and tagging scheme down?
>>Subversion could the provide extra management facilities, like enforcing
>>that people can create tags but not commit in them. And tools would be
>>able to download this file and use it to provide a much better interface
>>to the user.... Just some thoughts...
>>
>>
>
>This has come up on the list before, and I hope it never happens. One of the things that is so
>appealing about Subversion is the lack of conventions imposed on the user. If others need policies
>concerning tag commits, repository layouts, and so on, scriptify them (and chuck 'em in contrib/ if
>you want).
>
>I have trouble believing that people can't make Subversion work for them - it's totally flexible
>and scriptable. It seems that old work habits are the main roadblock.
>
>
Read again, I didn't say subversion should impose any convention. The
idea would be some standard way of describe the user's convention to
make it known to the client interfaces.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Symbolic names for revisions
Posted by Ben Gollmer <be...@jatosoft.com>.
On Thu, 15 Apr 2004 20:13:53 -0500, Nicolás_Lichtmaier <ni...@reloco.com.ar> wrote:
> Perhaps the solution is to reduce the "freeness" of the tagging and
> branching scheme. If there was a fixed, enforced naming scheme for tags,
> client interfaces could provide more facilities to the user. But it
> would be against the spirit of Subversion... but.. why not creating some
> way an administrator could write the branching and tagging scheme down?
> Subversion could the provide extra management facilities, like enforcing
> that people can create tags but not commit in them. And tools would be
> able to download this file and use it to provide a much better interface
> to the user.... Just some thoughts...
This has come up on the list before, and I hope it never happens. One of the things that is so
appealing about Subversion is the lack of conventions imposed on the user. If others need policies
concerning tag commits, repository layouts, and so on, scriptify them (and chuck 'em in contrib/ if
you want).
I have trouble believing that people can't make Subversion work for them - it's totally flexible
and scriptable. It seems that old work habits are the main roadblock.
--
Ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Symbolic names for revisions
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
> 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.
The problem I see with just adding aliases for revisions is that...
suppose you have this:
/prj/trunk
/prj/tags/release-1.0
The revision number is for the whole repository. So it applies to both
the trunk and the tag. It's not a point in the development timeline,
it's a state of the *repository*, which is not the same.
Perhaps the solution is to reduce the "freeness" of the tagging and
branching scheme. If there was a fixed, enforced naming scheme for tags,
client interfaces could provide more facilities to the user. But it
would be against the spirit of Subversion... but.. why not creating some
way an administrator could write the branching and tagging scheme down?
Subversion could the provide extra management facilities, like enforcing
that people can create tags but not commit in them. And tools would be
able to download this file and use it to provide a much better interface
to the user.... Just some thoughts...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Symbolic names for revisions
Posted by Ben Reser <be...@reser.org>.
On Thu, Apr 15, 2004 at 11:07:12PM +0100, Barry Scott wrote:
> 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.
In doing merging for 1.0.2 today it occurred to me that labels would be
really handy if they could reference more than one revision number.
That way we can mark changes on the trunk for a particular backport.
Then do a merge against the label, rather than separate merges. What
we're doing now isn't horrible, but this might make things nicer. (Yes
this is a drive by thought).
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org