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
is
Have fun!
Dirk
---------------------------------------------------------------------
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