Gale, David wrote:
> 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.
>
So - to continue the circular discussion that is going on here, you just
got done validating the use of the current 'tags' functionality. Why
would you want to try to kludge the system by creating a second method
that may make sense to some (but not all) users, andconfuse new users by
doing what so many other pieces of software do - give too many options
to make it easy to understand.
> 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 guys must really be good software developers. My shop, we write
code, test it (trunks and branches), think we have it good, and release
it. Boom - Tag-version 1. Then someone finds a bug. So we have to go
back, copy version 1 to a branch (because trunk contains many other
things that we don't want to mess with), make changes, test, and create
tag-version 1.1. Good software should NEVER repeat a tag for a release
sent to the public. It makes it nearly impossible to keep up with what
version of the code any one of your customers are on. If you only have
one or two customers then great. You're lucky. But we have thousands.
So any release of the software gets the natural tag which is easy to see
in the repository, easy to revert back to (update), and easy to manage
(permissions to who has access).
> 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?
>
Increasing options is not necessarily a bad thing, but is it REALLY a
good thing? I'd like my software to pour my coffee in the morning, but
it doesn't. Should this be something that needs to be installed in my
coffee maker? Is it REALLY necessary?
> 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.
>
>
>
The one thing that makes the current tags nice is that when you copy a
structure of the tree, it defaults to copying the substructure to the
tag as well. So you can check out the repository to your working copy
at whatever tree structure necessary to maintain your dependency. This
is actually a better fit than your tags scenario as you are talking
about allowing someone to ambiguously define which files / folders to
add to a label. Where is the dependency enforcement there?
Overall, I think I see more people get wrapped around the axle on the
directory metaphor given to the /trunk, /branches, /tags hierarchy than
any other issue on this system. Perhaps a change in semantics is
necessary. Forget that it is a tree structure. Just think of all items
as being flat inside the repository. Perhaps that will help?
Regards,
Frank
Received on Mon Feb 27 22:00:43 2006