Greg Hudson wrote:
> On Mon, 2006-02-27 at 08:42 -0500, Gale, David wrote:
>> Tags are inherently different from branches, and ought to be treated
>> as such.
>
> Nah, a tag is just a branch which oughtn't change. All the operations
> which you might want to do on a tag, such as compare it to something
> else, you might want to do for a branch as well.
Now, why would you say that? What is the defining characteristic of
branches, if not that they're a copy of a project allowing for
development of one feature without adversely impacting development of
other features? The defining characteristic of tags, on the other hand,
is that they are records of how the repository looked at a specific
moment in time.
And, while it's true that everything you'd want to do on a tag (a fairly
limited set of operations by definition) you can do on a branch, the
inverse is not true--there are many operations you can do to a branch
that don't make sense to do on a tag (such as creating another tag, or
making changes to files). The set of operations one would want to do on
a tag can be done on a specific revision number (svn diff -r <number>
..., to address your example of comparing tags to something else).
> You've pretty much hit on the main reason why I am opposed to revision
> alias proposals: they treat tags differently from branches. As a
> result, our UI would have one way of doing things for tags and another
> way for branches, which would be a regression from the current
> situation and a regression from CVS.
Hey, nothing in my proposal would mandate that everyone use revision
aliases instead of copying things to a tags directory. If you want to
worry about whether or not someone is doing development work on a tag
branch, you're free to. How is increasing options a regression?
> (Other reasons: mutability of revision aliases requires adding a
> second, redundant history mechanism. Revision aliases inherently tag
> the whole repository when it should be possible to apply a tag to
> only a part. Revision aliases are different from the current method
> of tagging a repository, and would introduce a transition issue for
> existing repositories.)
Personally, I'm not of the opinion that revision aliases ought to be
version controlled; if there's no good way of tracking changes to them,
that's fine by me. Yes, revision aliases provide a way to snapshot the
entire repository, even though you're right that it may only be sensical
to care about the state of a portion of the repository; that's why most
of my examples have included a project name as part of the alias. Of
course, it's also possible (as Dr. Grazulis has indicated) that you may
want to know what the status of a second branch was when the first was
tagged, or someone may (using the current system) tag part of a project
without realizing there's an interdependency to another directory, for
instance, at which point the tag is useless; revision aliases wouldn't
have that limitation. And revision aliases would not introduce a
transition issue, as (again) there's no requirement that anyone use them
in place of the current kludge of using branches as tags.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 27 20:40:40 2006