> hakon@ion.no wrote on 06/30/2006 02:34:50 PM:
>
>> > I really don't want to open this debate again. :-) Here's a quick
>> > summary.
>> >
>> > The general feeling among subversion developers is that the 'label'
>> > technique of tagging (the way CVS does it) is an inferior strategy for
>> > tagging, because there's no accountability. In the model you propose
>> > (as well as in CVS) there's no record of anyone creating a label, nor
>> > is there any record of someone changing the label or deleting it. In
>> > the subversion defnition of "tag" (a cheap directory copy), the act of
>> > tagging is an historical event, recorded forever in the history. If
>> > someone deletes or accidentally changes the tag, that's recorded as a
>> > commit as well. A label/revpropsimply doesn't provide any of this
>> > sort of tracking.
>>
>> OK, so let me suggest another solution, and let me know whether this is
>> any better, or whether it is still not acceptable.
>>
>> Let's adopt Subversion's notion that a tag is a name for a specific path
>> on a spesific revision. (Instead of the suggested revision-only.) To me
>> that sounds like a property on the path.
>>
>> A 'tag' command could have the following interface:
>>
>> """
>> tag: Set a tag on a path and revision.
>> svn tag [-r REVISION] TAG [TARGET]
>>
>> Creates a TAG on TARGET ('.') referencing REVISION (HEAD).
>> """
>>
>> It may be implemented as 'svn propset svn:tag:TAG REVISION TARGET',
>> but --force should be required to override an existing TAG. (And
>> anyway, the change will be in the log history.)
>
> Are you saying that svn tag would perform a copy (make the Subversion tag)
> and also set a property on the source of the copy? A problem with that
> approach is that you can only set a property in a working copy, and the
> property change then has to be committed.
'svn tag' should only set the property on the source of the copy.
Hmm, "svn: Setting property on non-local target
'file:///home/hakon/tmp/svn/trunk' is not supported" Well, the rationale
for this (from comments in the source code), is that it is too easy to
override an already set property. I agree! That's why I suggested (above)
that such an operation should fail, unless --force is used.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 30 22:10:07 2006