>
> [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.
I have suggested this simpler tagging mechanism to the list (which started
the Tags thread). But as I found out, and many before me I think, the list
will not accept a simpler tag mechanism, because it is a subset of the
current mechanism.
Note that the superset is used for tagging Subversion releases. And so to
convince the list that the subset is good enough, implies convincing the
list that the Subversion release process ought to change. :-) There are
obviously many on the list which is using and satisfied with the superset.
Therefore, we must first try to find a solution which supports all interests.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 10 11:41:44 2006