On 2006-03-18 at 14:34:32 Julian Foad <julianfoad@btopenworld.c
-----
John Calcote (jcalcote@novell.com)
Sr. Software Engineeer
Novell, Inc.
om> wrote:
> John Calcote wrote:
> > Okay, I've done the research, and I'm back to talk about this issue
> > intelligently now.
> [...]
>
> 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.
I don't know Julian, it seems conceptually simple to me, according to
the CVS manual (I'm looking at
http://ximbiot.com/cvs/manual/cvs-1.12.13, which is the manual
referenced by the gnu.org website for the CVS project), tags seem to be
just symbolic names for revision numbers. Section 4.4 is entitled, "Tags
* Symbolic Revisions", which seems to convey the very simple three-word
definition that I used in my original note, which you strongly state is
not the case.
This section also mentions that you can use the "cvs tag -v filename"
command to see which tags are associated with a file. In the CVS
paradigm, where each modified file's revision is updated with each
commit, this makes complete sense. But the essence of the section is
that tags are simply names for sets of revision numbers. Since revisions
in Subversion belong to the project and not to individual files, it is
clear that a file would not have a set of tags associated with it.
Rather, a (corresponding) tag system for SVN would have tags associated
with projects, not files. This is a natural parallel to the decision
made by SVN designers to revision the project instead of individual
files and in fact, is probably a better design for CVS-like tags anyway
for the same reasons that the SVN designers chose to revision projects
instead of files.
> 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
I'm sorry if I wasn't clear on this point in my original message. I'm
not really interested in possible new interpretations of the concept of
tagging. Granted there is probably value in doing a use-case study as
you suggest, but my original point was that existing CVS users expect
tags to act as symbolic names for specific revisions of file sets. Tags
in CVS act (conceptually) as lists of files with associated revisions.
When a user associates a tag with a work area, she's really just
book-marking her work area with a symbolic name. Now, a problem can
occur here in that the user may have specifically set a subset of the
files in that work area to specific revisions not related to the
original work area (or the other files around it, for that matter). A
CVS tag set on this work area would have no bearing on reality in this
case, as requesting an update from that tag would retrieve a mish-mash
of files with no relationship to one another other than the whim of the
user at the time the tag was set. Luckily, SVN versions projects, not
files, so this sort of thing can't really happen. It's interesting to
note that here again - the original reasons for versioning projects
instead of files serves SVN's corresponding implementation of tags as
symbolic revisions in the same manner - the same benefits are reaped.
Interestingly, Section 4.8 ("Tagging and Adding and Removing Files") of
the CVS manual indicates that tags are only associated with the files in
a work area or project at the time the tag is assigned, which means that
new files added later are not associated with the tag, and files already
deleted are not associated with the tag. It also has the interesting
side effect of tagging only files in the directory that the user did not
delete from her work area. This text in the manual means that the
original intent of tags was to tag a cross-section of the repository -
all files in the project at the time the tag was added. Subsets occur
naturally as a direct result of adding and deleting files earlier or
later in history of the project relative to the tag, and unnaturally as
a result of work-area corruption (unintentional or otherwise). Now, that
said, you CAN remove a tag from subset of files, but listen to the
language of Section 4.7 ("Deleting, Moving, and Renaming Tags").
...
"Normally one does not modify tags. They exist in order to record the
history of the repository and so deleting them or changing their meaning
would, generally, not be what you want. However, there might be cases in
which one uses a tag temporarily or accidentally puts one in the wrong
place. Therefore, one might delete, move, or rename a tag."
...
I realize that many people probably mis-use this feature according to
the original designers' intent. Nonetheless, I see nothing wrong with
implementing subversion tags such that they are versioned and
modifiable, making this functionality a feature, rather than an
accident. In fact, using my TAG file hack, tags are versioned by virtue
of the file existing in the repository (ironically).
> ...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 didn't intend for my message to provide a pseudo-code patch to the
subversion code base. In fact, I didn't provide a complete user
experience in my examples. This surely needs to be done, but it's likely
not that hard.
> 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 don't mind you being harsh - I only mind being ignored, because then
no intelligent exchange of ideas can happen. :)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 19 16:58:49 2006