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...]
I wish that you would acknowledge that there is not yet an established specific
meaning of the term "label" in the Subversion community. Half of this
discussion so far has been about whether people want to label global revision
numbers or collections of arbitrary versions of arbitrary files or what. It's
no good asserting that "labels are useful" without saying what the labels are
labelling.
For instance, you may be accustomed to some particular version control system
in which the term "label" has some specific meaning which by now is so
intuitive to you that you forget that to me it just means "a word that refers
to a thing".
> 1. I don't really buy the "you can do it with tags, so who needs labels"
> argument. Frankly, following this reductionist argument, you can do
> everything SVN does with a well-designed directory layout/scheme, a DIFF
> command, and a book detailing all the necessary conventions to follow.
> So why does everyone use SCC systems? Because the *computer* should do
> the book-keeping and grunt work, not the dev, since (a) it's what they
> are good at and (b) it's what devs are bad at. However, the current tag
> model is a convention enforced and manged by the dev/admin and not the
> tool. Huh?
OK, I completely agree with what you here, that the tool should do whatever
book-keeping grunt-work is useful. Can you/we please try to define what this
required behaviour is that you refer to as "it" in "you can do it with tags"?
If I seemed to be saying that the current implementation of tags is good enough
for what you or most people want, I apologise. But in order to design a
feature that will make you happy, that we are tentatively calling "labels", we
need to specify exactly what behaviour is required from this feature. We don't
seem to be getting very far with this specification.
A good way of moving forward would be for somebody to write a first draft of a
specification for the _requirements_ (not implementation method) of the
feature, and then we can comment on it and revise it until most people agree
that it is good and feasible. The form of this proposal would be something like:
[[[
PROPOSAL FOR LABELLING INTERESTING VERSIONS OF A PROJECT
Subversion's concept of "tags" is too flexible to provide the desired level
of support to a repository administrator in the following common situations:
[...] where the following drawbacks are apparent: [...] This proposal is for a
scheme which [adds to / replaces / modifies] Subversion's concept of "tags" to
solve most of those problems.
The basis of this scheme is that users should be able to label certain
restricted groups of repository data. The label itself will be a [versioned /
unversioned] resource: in other words its lifetime shall be [...]. When there
is more than one project in a repository, the labels shall [...]. Labels can
apply to branches as well as to the trunk, in the following way: [...]
A label refers to [...]. It is created by [...] and [can / cannot] be
destroyed, renamed, or moved to refer to different data, in these ways: [...]
[...]
The term "label" will now have the specific meaning defined above when used
in the context of Subversion.
]]]
> 2. Following the "simple scenarios should have simple solutions" model,
> how do I simply track a linear development process so that I can easily
> refer back to an earlier rev for a quick diff? Without labels, I have
> three choices (a) manually track dates/ rev numbers in some external
> dataset (e.g. a spreadsheet), (b) over-load the message field with yet
> another semi-formal data item or (c) use tags.
>
> Now, (a) would seem to indicate a lack of something in the toolchain.
> (b) is horrible since the message field is already badly overloaded (bug
> tracking, branch merge tracking etc.). So we're left with (c), but this
> is *not* a _simple_ solution to the simple problem -- far from it.
You may be right, but it is far from obvious that (c) is not a simple solution.
Did you see the examples of how to create a tag and diff against a tag
earlier in this thread? One of the most obvious problems was that the whole
URL to the repository had to be specified on the command line, but that was
shown to be worked around quite simply and neatly in the simple cases by
defining an environment variable containing the URL of the repository's tags.
I'm not saying that's an ideal solution, just that if that is one of the main
problems then it would indicate that we probably don't need to re-design the
whole concept of tags. We may be able to make the situation 90% better via a
couple of relatively minor enhancements, and that would be a good thing for
everybody even if that still leaves the remaining 10% of usability under
discussion for a longer-term feature enhancement.
Please explain how specific aspect of the existing usage are not simple enough,
or not good enough, so that we can understand why a new design is needed. Give
examples of every-day use cases, and we'll see where the existing usage is not
good enough and we'll assess the best way to improve the user experience. Of
course the developers are biased towards keeping things as they are, but I
don't believe they (we) are strongly biased; they/we are quite willing to
accept that a change is needed if shown some convincing real examples.
> 3. Tags, as second-class objects, are not understood by the toolchain.
Right. That does feel wrong to me, but I haven't yet seen a clear
demonstration that it is actually wrong or bad or unhelpful. For instance, I
haven't yet seen how the difference between the two potential syntaxes:
svn diff -rTAG1:TAG2 foo.c
and
svn diff --old=$TAG1 --new=$TAG2 foo.c
is any more than "syntactic sugar", i.e. something that could be "fixed" by a
simple change to the command-line interpreter. (On the other hand, I do feel
that there is a fundamental difference between the concepts implied by those
two syntaxes, in that the former implies that tags are (approximately)
unversioned aliases for revision numbers, while the latter doesn't.)
> What is the SVN command to compare two revisions of a file if I don't
> remember the rev # of the earlier file? I have to wander around in the
> tags directory, then manually construct a suitable svn command. Urgh!
Huh? You are not describing your concern very well. In what way do you think
you wouldn't have to "wander around" in the list of tags (or "labels") to find
the one you want if they were a first-class object? And in what sense do you
think you wouldn't have to "manually construct a suitable svn command"?
> IMHO there are already too many places where the svn "best practice" is
> "scan the log messages for magic comments, note the rev #, type it into
> a subsequent command" -- yet again, we are back into the devs doing
> book-keeping for the computer!
OK, I agree with this concern - but what is your proposal for improving the
situation? (Sorry to keep asking - I am really not trying to annoy you.)
> 4. Pragmatically, I have already seen too many shops using a "roll your
> own" label scheme to believe that labels are unnecessary. Some shops use
> external files and a nightmare of hacked scripts to inject revision
> numbers into svn commands. Others hack them into properties and then
> (again) hack together scripts to automate as much as possible. All of
> these shops are working around what they see as a weakness in svn --
> what they are *not* using, however, is tags.
OK. Could you or anyone present one or more of these cases here, to show what
is required?
> So, why argue for labels?
(Well, I still don't know what these labels are that you are arguing for.)
> My feeling is that an SVN repo is in fact a
> two dimensional store -- one dimension being the directory tree, the
> other being the revision number. A node in this space is located by the
> combination of (URL,REV#).
Good - that's exactly how the docs and the designers see it.
> Access to the URL co-ordinate is relatively
> easy because (a) users remember mnemonic names quite well and (b) both
> the OS and SVN provide many browse/search assists for this space. Access
> to the REV# co-ordinate is *not* as easy since (a) users do NOT remember
> numbers easily and (b) SVN provides few tools (and the OS none) to help
> locate rev numbers.
OK.
> Tags try to overcome this by essentially translating the REV#
> co-ordinate _into_ an URL co-ordinate. Labels try to overcome this by
> providing direct mnemonic aliases for the REV# co-ordinates. We already
> have the tags solution, so why do we need labels? Because once a REV# is
> translated to an URL via a tag, it *loses* information in the form of
> its type -- the toolchain no longer understands that the tag is a REV#
> and hence cannot usefully enforce or use that information. So there is
> *no* direct way to specify the REV# _implied_ by a tag in an SVN command
> -- hence all the awkward syntax and cumbersome use of URLs in many
> otherwise simple SVN scenarios.
OK, thank you. So you want your "label" to be a reference to a revision
number. That's fine. That's the type of label which C-Mike Pilato outlined
right at the binning of this thread (but got no response) and for which Brane
has a concrete low-level implementation proposal.
Great. I can see that this type will be useful, without much in the way of
examples. We still need to work out the details, like how they work when there
is more than one project in the repository, what their scope is tree-wise, what
their lifetime is, whether they are unversioned or versioned, etc. So we still
need to discuss some use cases.
>
> Put another way, an ordinary, plain old developer needs a simple way to
> say "diff the current rev of foo.c against a known reference" that (a)
> doesn't involve memorizing rev# and (b) doesn't require mastering branches.
Yay! OK, let's go ahead with implementing this type of label, i.e. references
to revision numbers.
HOWEVER, bear in mind that this did not seem to be the type of label that
everybody wanted. Some other people want some enhancement to the tags concept.
So, let the design discussions proceed in two separate threads: "Labelling
revision numbers" (being what you are talking about) and "Enhancements to tagging".
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 31 15:49:19 2005