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

Re: Mnemomic names for revisions

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-05-11 11:04:58 CEST

Daniel Patterson wrote:
> The problem with a label is that it's going to have to inherit all
> the abilities that the current "recommendation" has. It's going
> to need history of it's own. It's also going to have to be able
> to deal with mixed-revision tags, which the "copy workspace to URL"
> does quite intuitively. That all sounds like a lot of repeated
> work.

No, as far as I understand, labels/aliases/mnemonics *must not* have
a history, exactly as a SVN revision number does not have a history.
The question "What was r54236 like at r77654?" makes no sense, exactly
as "What was Build_2004-05_custom_special like at r77654?" makes no
sense if "Build_2004-05_custom_special" is the alias for r54236.

> In addition to that, you add another dimension to the namespace.
> In your system, to refer to a label, you need [label,URL]. If you
> keep everything in the URL (as Subversion recommends you do right
> now), then you have an atomic piece of information you can pass
> around to refer to a "thing".

I have the impression that you got a different idea of the aliases.
AFAIU, the aliases should be aliases for the revision numbers and
fully equivalent to them.
(There could be a list of "alias <=> revnum" on the server (which
might be transferred to a client as well), the svn tools could look
up the revnum from the alias and then continue using the revnum.)

Please correct me if I got the wrong idea about it.

> If you don't want your tags changing once they're made, put
> a pre-commit hook in place to stop that.
>>What I, at least, really want to do is to feed Build_1 and Build_2 into
>>the text boxes of the diff command on WebFrontendX and have it do the
>>right thing.
> You could do that right now.

Could you describe how? I thought it's not possible.

>>As it is now, there is no meta-data, everything is by convention, and the
>>conventions aren't strong enough to embolden tool creators to use them.
> Rather than re-invent the wheel and create a new "blessed" property,
> perhaps some of the upcoming "repository templates" could be used
> for this. The server could describe the "policies" for the repository
> to the client, which would then know where in the namespace
> various concepts belong (like branches and tags). It could be a
> complex description language, or something as simple as
> saying "this repository complies with Blessed Structure 1",
> where the Blessed Structures are something like:
> 1) /branches /tags /trunk
> 2) /project/branches /project/tags /project/trunk
> 3) /branches /tags /projects/projectN
> etc. There are only a handful of these basic configurations that'd
> cover most of the ground. Everyone else would fallback to what
> they've got today.

This looks like an Absolutely Great Idea(tm) to me!! I'm not sure if it

Have fun!

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 11:07:23 2005

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.