Re: [DESIGN] Aliases?
Frank Gruman <[email protected]> Mon, 27 Feb 2006 15:21:57 -0500
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <[email protected]> |
--------------010009010301070407090203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------010009010301070407090203
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gale, David wrote:
<blockquote
cite="mid68B5F4BC6852D244BDDAAE69E31B15F90812F03F@intrepid.hypertherm.com"
type="cite">
<pre wrap="">Greg Hudson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Mon, 2006-02-27 at 08:42 -0500, Gale, David wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Tags are inherently different from branches, and ought to be treated
as such.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
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.<br>
<blockquote
cite="mid68B5F4BC6852D244BDDAAE69E31B15F90812F03F@intrepid.hypertherm.com"
type="cite">
<pre wrap="">
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).
</pre>
</blockquote>
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).<br>
<blockquote
cite="mid68B5F4BC6852D244BDDAAE69E31B15F90812F03F@intrepid.hypertherm.com"
type="cite">
<pre wrap=""></pre>
<pre wrap="">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?
</pre>
</blockquote>
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?<br>
<blockquote
cite="mid68B5F4BC6852D244BDDAAE69E31B15F90812F03F@intrepid.hypertherm.com"
type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
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?<br>
<br>
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?<br>
<br>
Regards,<br>
Frank<br>
</body>
</html>
--------------010009010301070407090203--