[re-post after 48 hours. original post seems to be lost]
---------- Forwarded Message ----------
Hi @dev!
IMHO, there is some confusion of what tags are.
I believe the term is used for two different concepts:
Configuration := Set of (node, rev) pairs. Usually,
{nodes} are disjoint and cover some basic set
(i.e. the whole source project).
Tag := Additional information attached to a single
node, rev or (node, rev) pair.
Either concept may be used to emulate the other to
some extend. CVS has only tags and uses them to
describe configurations. SVN has true configurations
(calling them "tags" for historical reasons) and support
for tags on revisions (calling them "revision properties").
I am not sure what tags on nodes may be useful for
and whether that can't be done with node properties
or (node, rev) tags. However, there are valid use-cases
for the latter form of tags, e.g. document status after
review and approval.
The current discussion is focussing on making
configuration handling easier. While this makes
perfectly sense it will probably not cover "tag"
use-cases.
My proposal:
SVN grows a "svn tagset node -r rev" sub-command.
The information will be stored in the new "svn:tags"
revision property. The format is:
* one line per node
* lines start with the escaped node name
* escaped tags follow separated by spaces
Rationale: One may expect the size of the svn:tag data
to be in the same order of magnitude as the number of
paths changed in that revision. Hence, there should be
no issues with size or computational complexity.
Tags are not inherited. They are just an extension to
your log comment with a more convenient and easier
to automate interface. Operations should follow the
prop* command style:
* svn tagset node -r rev "tagtext"
* svn tagdel node -r rev "tagtext"
* svn taglist [node] -r rev
* svn tagget node -r rev
Note that no searching, inheritance etc. is required.
This is because nodes cannot be "part of" a tag (they
may be part of a particular _configuration_, though).
As the tags are attached "after-the-fact", it is up to the
user (and he / she is able) to place them on the revision
that will be used to look them up later.
Just my €0,02.
-- Stefan.
-------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 14:53:56 2006