On 2006-03-18 at 14:34:32 Julian Foad julianfoad@btopenworld.com 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 17:00:19 2006