[Danny van Heumen]
> Because of different concepts of 'tags' I would like to come to a
> general understanding.
Right, so, obviously subversion's tree copy primitive handles "all of
the above", but some people find it cumbersome to use compared with the
tagging facilities of competing systems.
I think there's a case to be made for the svn client supporting an
explicit tag infrastructure for a simplified subset of use cases; I
disagree with the view that, as the problem has already been solved in
the most general way possible, anything else is redundant.
In particular, I think case 3:
> 3. An alias for a revision number for a specific location.
> a) Single revision
> b) Specific location
is simple enough yet useful enough to be worth supporting separately.
For the UI: any arbitrary 'tag_name' in -r or -c refers to a specific
revision number, and this association is scoped to a directory
(possibly root).
For the implementation: a 'svn:tags' dir property would be a list of
'tag-name:12345', whitespace-separated. Efficiently searching parent
directories for a tag name is straightforward and can reasonably be
done client-side. (Not a revprop: those are harder to scope to a
directory, would require revprop search, and aren't versioned.)
Property inheritance would obviate the need for searching parent
directories, but that's a small point, IMO.
Explicit support for complicated cases - mixed-revision tags, tags that
contain file modifications, and tags for a subset of a directory -
doesn't seem all that useful; i.e., it strikes me that producing a
reasonable UI for those things would be too much complexity for too
little gain. There is always 'svn copy', after all.
I guess my point is: don't look at all 5 of your use cases and say
"now, can any competing tagging system do _all_ of that?" Instead,
since subversion already has tree copies, look at what subset of cases,
if any, make sense to support in an easier-to-use UI.
Received on Mon Jul 10 10:37:23 2006