John Calcote wrote:
> Okay, I've done the research, and I'm back to talk about this issue
> intelligently now.
[...]
> Hope this is useful...
Unfortunately not, because you have fallen into the same trap as so many other
correspondents, and that is to approach the subject with the assumption that it
is conceptually simple, having an obvious Right Answer. The "solution" you
mention here is that a "tag" should be an alias name for a revision number.
You don't even acknowledge in this mail that there are other possible
definitions, such as a tag marking only a subset of the files and directories
in the repository, which is something that CVS tags can do. You appear to
assume that anyone in their right mind will agree that your three-word
definition is the Right Answer and all the unspecified details such as whether
tags are versioned need not be mentioned yet and will work themselves out at
the implementation stage.
I know I'm being harsh on you, but this is the way your message comes across
after having seen many others like it. Bear with me a minute.
I could be more helpful to you by pointing out exactly why certain other
definitions of "tags" would be be preferable in certain ways, and how some
high-level designs fit better with the existing architecture and features of
Subversion than others do, but I'm sorry to say I've done that to some extent
in past discussions (but far from a complete analysis) and haven't got the
energy to re-start it right now.
The most productive stage I can recall was a few months back when a few people
started discussing here some concrete examples of the operations that would be
made easier by some new tagging subsystem, with ideas for the sort of
command-line syntax that might use the tags, and getting an idea of what
features of this subsystem would be most important and so on. One or two
proposals that looked quite promising came out of that discussion, and could do
with being followed up.
Since you obviously care enough to want to help, I encourage you either to have
a go at reviving that discussion of use cases and proposals that satisfy them,
or to write up an analysis of the requirements and architectural aspects of
such a feature, taking all the possible requirements into account and
evaluating their importance and feasibility. The reason why I think that would
be useful is because all the previous discussion is scattered sparsely through
mailing list threads full of irrelevant and repetitious messages, and the
developers need a coherent presentation of the issue in order to be able to
judge it fairly and make progress towards a decision.
There is one other course of action that you could take, that is generally
suited to this type of project, and that is to "send a patch", i.e. design the
feature the way you want it, send your description and implementation to us
here, and see if it is accepted. If your design is well enough thought out and
described, the committers will accept it. I would advise that, in an area like
this where the Right Answer is far from obvious, your design proposal would
probably have to include as much analysis of use cases and alternative designs
as my previous paragraph talked about.
Thank you for your interest, and I look forward to your help with the
development of a more user-friendly tagging feature.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 18 22:34:54 2006