Daniel Patterson wrote:
> 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 ;-) ).
That's right. Still, I feel this is different from checking out the trunk
at the state of a specific revision number, e.g. for fixing something. Then
again, I could 'svn copy $URL/tags/Build_123 $URL/branches/fix_of_Build_123'.
Well..... maybe.
> 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).
I just copied that from your post ;-) I guess the URL might be used to
narrow a search for a property. What I would like best is a 1:1 match
between a label/alias/mnemonic name (that can be specified during commit)
and the subversion revision number, so that I can freely use the name
wherever the subversion revision number is valid. But as a compromise,
finding the svn revnum by searching for a specific property would be
a very big step ahead - if I could get that, I'd happily use it.
> 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?)
My favorite idea does not involve the URL, the labels apply to the whole
repository. Subversion should reject a label thas has been used before.
(Maybe there could be a secret admin tool that allows changing a label
in very rare cases, e.g. a typo, but other than that there should be no
change.)
Using 'revpropfind', hmmm... I guess the URL would be needed, or you
might get something completely unexpected (if someone else used the same
label-property).
>> 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.
Would it be possible to set up some automatism to checkout the whole
repository or a branch as it was when I made the tag, like:
svn co $URL@`svn log --verbose --stop-on-copy $URL | fiddlescript`
where "fiddlescript" does some processing and returns exactly one svn
revnum? Preferably the one I want ;-) (I think the URL is always needed
to specify the root of the checkout.)
> 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.
*nod*
>> 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.
"Server templates" is IMHO a *great* idea, that would solve the problem
that the tools don't know about the user's convention.
> 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.
What's a DAG?
> daniel
Thanks a lot
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 16 21:43:58 2005