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.
Subclipse has taken approach that is similar to this. See:
http://subclipse.tigris.org/branch_tag.html
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 30 21:53:40 2006