> 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.)
A command like 'svn diff -r v1.0:v1.1' should walk up the directory
tree to find the tags, and to convert them to revisions.
To display the tags and their revisions could be implemented as 'svn
proplist -v TARGET', but should only pick the "svn:tag:" properties. The
author and date could also be displayed alongside the revision numbers.
Note the similarity of this solution to the current Subversion-like tags.
But instead of copying a TARGET@REVISION directory to a directory (named
TAG) in the tags directory, the REVISION is stored as the property value
of a property name TAG on the TARGET. And so it is easy to implement, and
not too different from Subversion-like tags.
As a side note I would like to get feedback on: One of the "problems" with
the notion that a tag is a full directory tree snapshot, is that it is
impractical to fully checkout the tags directory of a large project. I
estimate that a (full) checkout of Linux's tags directory (would have)
amounted to about 100 GB. Storing the tag as a full directory tree is of
course unneccesary, as the code has already been committed as
TARGET@REVISION. The above solution does not have this defect.
Håkon Hallingstad
---------------------------------------------------------------------
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:34:26 2006