OK, and my apologies if I came over a little aggressive in my post --
was starting to feel I was fighting uphill :( Here's the best I can do
to describe my thought processes (a re-hash of another post)...
In an SVN repo, any item has a unique co-ord comprising an (URL,REV#)
pair (let's ignore renames etc for now). Now, URLs are more-or-less
mnemonic names (good for humans), and both the OS and SVN provide many
tools to browse/list/locate an URL in a large tree. The problem as I see
it is that the REV# part of the co-ord pair is the "poor man" in this
equation. The user must either remember an integer or a date (and the
date can be ambiguous in some cases). Users are *not* good at this, so
it is good if a way can be found to enhance the REV# part with more
mnemonic values or provide other automatic means to assist in the use of
REV# values.
Tags are one way to do this. At root, a tag is a translation from the
REV# "dimension" of the repo to the URL dimension, and hence translates
the "hard" REV# into an "easy" (to recall/search) URL. BUT the mechanism
in SVN used to provide tags (actually just a cunning re-use of
branching) in a technical sense loses information -- specifically the
*formal* knowledge that the tag is indeed an alias for a REV#. This
information loss has two consequences: (a) users are not aware that the
tag is, indeed, a tag (without naming conventions, which are fragile)
and (b) the toolchain cannot *automatically* translate back from a tag
URL to a REV#.
What are the results of this?
1. Tags need extra vigilance by admins, either manually or with
semi-hacked scripts, to enforce the "tag-ness" of tag branches. Users
need to be educated out-of-band (there is no toolchain help) about what
tags are and how they must be used. Since the toolchain has no knowledge
of tag semantics, it cannot help (directly) enforce any of these
conventions.
2. Translation of a tag URL back to a REV# is a manual process,
involving locating the tag, discovering the REV#, and then manually
transcribing that REV# into appropriate SVN commands. This is
error-prone, cumbersome, and not conducive to automation/scripting.
Therefore, what I am lobbying for is a mnemonic way to describe REV#
values that does not lose semantic information, iow some form of
mnemonic tag that the toolchain *does* understand as representing a REV#
and can therefore (a) enforce semantically and (b) consume directly. One
implementation might be some form of alphanumeric value that can be
associated with a REV# and accepted directly by the toolchain as an
argument to the --revision switch, but other implementations are of
course possible.
A non-goal, to my mind, is to replace the current tag mechanism totally.
My expectation would be that "labels" would be a lightweight system that
was adequate for linear development and intermediate (non-milestone)
revisions, but tags would almost certainly continue as the primary way
to mark milestones and/or track more complex non-linear deve processes.
Now, I'm *very* aware that even a simple label system has many issues
that need to be resolved (scope, namespace etc), and I'm more that happy
to assist in this analysis on the way to a design that meets real user
requirements and is cost-effective to implement (and is backward
compatible, of course).
--Tim
Julian Foad wrote:
> Tim Hill wrote:
>
>> Sorry, I have to disagree with these arguments, Julian.
>
>
> I may well be wrong and I'm glad to have your input. However, I
> wasn't really making any arguments in that post.
>
> I think you have somewhat misunderstood my position. In this thread I
> am trying to get people to explain what is wrong and what would
> exactly would be better. I'm not claiming that I know the answers at
> all. I am seeing vague requests for improvement, but not yet
> proposals with enough detail.
>
>
>> I agree with David that labels are a useful, and even necessary
>> addition to SVN.
>
>
> [p.s. After writing the many following paragraphs I reached the end of
> your mail where you say what kind of labels you want. Having written
> so much, I don't want to delete it, but I wouldn't have written much
> of this if I'd read your message to the end first. So apologies for
> the frustrated tone of this...]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 31 21:52:14 2005