Stefan Fuhrmann wrote:
> Hi @dev!
>
> IMHO, there is some confusion of what tags are.
> I believe the term is used for two different concepts:
It think it's not so much the confusion about what tags really are. Or
maybe better said: how tags are implemented in subversion.
It is more about how the concept called 'tags' is used in most RCS and
how it must be used in Subversion. I think this because these kind of
discussions also take place with 'branches' as subject. And a branch in
for example CVS and Subversion are more similar than a tag.
Because we actually use the 'configuration', as you called it, there's
an extra "dimension" in the form of a location. And because most people
don't keep that in mind, they get surprised when they actually want to
create a tag (and also a branch).
>
> 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 but will probably not cover "tag"
> use-cases.
>
> My proposal:
>
> SVN grows a "svn tagset node -r rev" 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 svn:tag information to
> be in the same order of magnitude as the number 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 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 you attach the tags "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.
If I understand you correctly, your proposal is somewhat the same as
some of the other proposals already suggested. The problem is that it
adds functionality without the need for it.
The thing called a 'tag' or at least what it is used for, is already
possible. The only thing is that people have to realize they have to
prepare their repository for it, in the form of at least 3 folders
(trunk, tags, branches) in a basic tags+branches-enabled repository design.
This is somewhat more complex if you're new to the concept, but it gives
you more control which should be a good thing.
(If I am wrong, please correct me, but this is what I had understood
from the several replies from different developers.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 20:19:57 2006