[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: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-05-11 07:37:44 CEST

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

  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.

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

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

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

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 07:39:48 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.