[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-15 00:09:00 CEST

Dirk Schenkewitz wrote:
> Very good :-) I'd be happy if this gives me:
> "svn co -r`svn revpropfind --firstonly eq svn:label Build_123 $URL` $URL"
> and perhaps also:
> "svn co -r`svn revpropfind --laststonly eq svn:label Build_123 $URL` $URL"
> mentioned by Daniel Patterson, (although this is still quite lengthy to
> type.)

   Although I suggested some kind of ability to search revprops, I'll
   just make it known that I think it's simply better to do:

     svn co $URL/tags/Build_123

   (and it's nice and short like you want ;-) ). If you don't want
   labels that could change, use a pre-commit hook to lock them
   down. As I mentioned earlier, I think it's a really bad idea
   to make the namespace multidimensional (i.e. you're suggesting
   you need *two* bits of information, the label and the URL).
   By putting the label name as part of the URL, you automatically
   avoid namespace conflicts and ambiguity. (In your scheme, is
   a URL much use without a label, or vice versa?)

> Exactly - that's what I think it should do: label/give-a-name-to one
> revision number of the repository, especially *including* tags and
> branches. Because that's what I want to know: "What was the whole thing
> like at 'VERSION_1.0'?" If the branches were left out, I could not check
> out the branches as they were at VERSION_1.0, same goes for the tags. Of
> course, if there are several projects within one repository (why would
> you want to do that? Most likely because they share some code, isn't it?),
> then either the VERSION_1.0 should deliberately refer to all projects,
> or you should use a label like VERSION_1.0_PR2 or such - it would still
> apply to the whole repository, but one who is looking for PR1-revevant
> stuff can ignore it.

   And this can all be achieved right now without any special extra label
   type. Subversion is already recording all the information you need
   to fully reconstruct history. After you've made a tag, you can do:

     svn log --verbose --stop-on-copy $URL

   This'll tell you:

     a) At what revision the tag was made
     b) Where it was copied from (if that was some other arbitary
        revision, or indeed if it was a mixed-revision tag).

   From those bits of information, you can easily work out what
   branches were around at the time, etc.

   There are definetly situations where you have multiple projects
   with their own release lifecycle within the one repository.
   Shared code is just one situation that this might come up in.
   Another might be a long running project that branches, and one branch
   ends up becoming a product in its own right, with its own tags
   and branches. There are plenty more reasons.

> ...
> Here you assume that labels are implemented to be changeable. But if
> you just go with Tim Hill's suggestion and labels are immutable,
> one-time settings, you don't have that problem. Then it should be
> easy for subversion to enforce that any label is unique.

   By default, the directory naming convention does allow for changeable
   (but versioned) labels. However, you can turn that off with
   a pre-commit hook that prevents label changes. Then, you've got
   a system that works like Tim described.

   I think if the layout of the repository can be adequately described
   to the client using the upcoming "server templates" mechanism,
   then that'd solve all these problem. Then, Subversion could grow
   things like:

     svn-util tag X

   which reads the repository configuration to know where tags are
   stored, etc.

   Just as a side note, I think it's important to keep separate the
   ideas used for source code control (tags, labels, etc), and the
   "versioned filesystem" that Subversion is presenting. I've
   used "svn-util" as an example of how that kind of functionality
   might be divided. Tagging is *not* an operation that applies to
   DAGs, it's an idea from a higher level of abstraction, and should
   be treated such. Operations like "copy", "merge", etc, are all
   fundamental DAG operations. Things like "tag", "deliver", etc,
   are configuration management operations that you can use a DAG
   to implement.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun May 15 00:16:14 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.