Frank Gruman wrote:
> Gale, David wrote:
> 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.
How so? I showed how tags are different from branches. Yes, as I have
pointed out, you can declare "anything copied to this directory is
sacred; thou shalt not touch!", and use SVN's nifty branching
functionality for tags, but specific revision numbers will *always*
refer to the same point in time (short of a dump/filter/load cycle)--no
declaration from on high necessary to ensure their immutability.
> 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.
Because using file structure to track time is something I'm trying to
get away from. I've worked on teams where the "version control" was to
copy existing files to a time-specific name before making any
changes--hardly an ideal situtation. Unfortunately, SVN's "tags" seem
to be a throwback to that era--you want to save a copy of the code at a
given point? Sure, just copy it over here and decent name!
> 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
Why do you say that?
> 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).
Ok, so, under my system, you hit release 1 and tag it; you find a bug,
and issue a "svn copy -r REL_1 <repos>/trunk <repos>/branches/1.1-fix"
command. Amazingly enough, SVN's branching functionality supports this.
As for not repeating tags, there you hit upon one of SVN's weaknesses.
Since tags are just branches, they can be created, destroyed, moved,
replaced, entirely at whim--only institutional policy (and maybe a hook
script) prevents this chaos. Revision aliases wouldn't get rid of this
problem, I'll admit--but by requiring at least a '--force' argument to
move an existing alias, people would at least have to think before doing
something dangerous like that. (And I could imagine an argument in the
configuration file preventing even --force from working, for the truly
paranoid.) As I proposed it, revision aliases would also be easy to see
in the repository (svn alias -list), and it's trivial to update to a
specific revision (svn up -r ALIAS). Any other features you want?
> 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?
Sure seems like most people's reactions has been "They want something
similar to what CVS does! Heresy! Burn the witch!" (That is, of
course, aside from the people who've been adamantly in favor of the
idea.) As to your coffee, well, if we were talking about software that
currently pours only Earl Grey, then maybe. Subversion is for tracking
changes over time (not tea); my thought is to give it another way to
reference moments in time. Surely that's close enough to merit at least
some consideration?
> 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?
So, you like losing the information of "What was the state of everything
else in the repository when this tag was created"? (Yes, it's still
there, but it requires at least two steps to find.) And I'm suggesting
applying labels to the entire repository at a specific revision; I'm
aware that Dr. Grazulis has proposed directory-specific aliases, but I
think that's needless confusion, and simply an attempt to wrap the
desired functionality into what subversion currently offers. So a
label, to me, does not have specific files/folders added to it. I would
say, though, that your label names ought to be clear enough to indicate
what portion of the repository is cared about--if it only applies to
branch2 of project one, call it something like "PROJ1_BR2_V4.1".
Naturally, the clarity necessary is entirely dependent on the purpose
for the alias, and thus shouldn't be dictated by the SVN dev team. Or
me.
> 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?
Not really, because that's not a problem for me (at least partly because
my office uses different names and policies which don't lend themselves
to t/t/b.) My concern is with the other dimension--time. Revision
numbers measure time; why can't we assign names to them?
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 27 22:38:04 2006