[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: Brian Huddleston <brianh_at_huddleston.net>
Date: 2005-05-11 09:12:22 CEST

----- Original Message -----
From: "Daniel Patterson" <danpat@danpat.net>
To: "Brian Huddleston" <brianh@huddleston.net>
Cc: <users@subversion.tigris.org>
Sent: Wednesday, May 11, 2005 12:37 AM
Subject: Re: Mnemomic names for revisions

>> Yes, that would be awesome.
>> What *I* really want though is for a label to be a first class citizen.
>> There are any number of answers, I think, if we want to homebrew a
>> solution.
> 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.

Yeah, I don't disagree there which is why I like the simple "mnemonic names
for revisions" idea.
Each revision can have a simple string alias. The client code simply
converts it to a revision number under the covers like it does with dates.

> 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".
> If you don't want your tags changing once they're made, put
> a pre-commit hook in place to stop that.

Sure, that's how I'm setup right now.

>> 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.

Only from the command line. :-)

None of web front ends I've played with let you diff tags/R9_3_1234 with
tags/R9_3_1235. All of them let you diff revisions though. If we had nice
transparent aliasing then boom I'm done.

>> 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.

That would be extremely cool and I think it would solve the tool problem
nicely. Joe Developer is creating a plugin for the SuperNova IDE. He needs
to map the "tag" function in his IDEs generic VCS interface to something on
the subversion side. He simply uses the server side configuration hooks,
asks what the "tag" directory is for whatever he's current working on and
voila he's done.

If such a thing were in place you could also implement svn tag and branch
subcommands fairly trivially (and their existence would then embolden tool
writers to include nice GUI shortcuts to all of this.)

>> Subversion implements tags in the same since that Windows Explorer
>> implements tags. You can designate a folder and copy things over there.
> Except that you can enforce stuff (like, you could pre-commit hook
> to enforce the name of a label). You can even require that a
> separate mechanism is run to make albels (like, a button on a webpage).
> You also have full history of every change.

Yes. I hope you'll excuse my hyperbole. :-)

> daniel


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 09:14:44 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.