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