On 26-Feb-06, at 3:00 PM, Rob van Oostrum wrote:
> [snip]
>
>> This is what I was going to suggest, EXCEPT I think the property
>> should go on the branch you are labeling. So it would be a property
>> of the top directory in your WC. That way there is still the
>> separation of unrelated labels and the same label name can be used in
>> different projects in the same repo.. e.g. "last_merge" can be in
>> ProjectA/trunk and ProjectB/trunk and each will point to a different
>> revision.
>>
>> The repo root could also be used for repo-wide labels.
>>
>> Scott
>>
>
> So when searching for a tag, your wrapper script would have to
> traverse
> ALL branches, and somehow figure out how to chose between duplicates?
I haven't got the foggiest idea what you are talking about. What I
proposed would not require any of that.
> How would it even know where to look for these branches?
What branches? I suppose "last_merge" was a poor choice for my
example label. The point I was trying to make is that a label that
is placed *on the branch it refers to* makes more sense to me than a
cheap copy of that branch in some other part of the directory tree.
It requires no awkward ---stop-on-copy log weirdness to figure out
what and when it is referring to. It does not require the
enforcement of a particular usage policy through hook scripts and
repository layout.
Using the "tags" directory method, what stops a completely unrelated
source tree from being copied to the tags directory of some project?
Another hook script that *I* have to write? Sure the concept can be
hacked on to cheap copies, but it's sloppy and error-prone. It's
just fundamentally not the same thing and this insistence to make it
mean the same thing when it doesn't seems very odd to me. Perhaps if
Subversion had a reasonable way to truly force "tags" to be tags and
not some random copy of anything it would make a little more sense.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 27 17:47:38 2006