Re: Re: FW: [DESIGN] Aliases?

Ok - I thought I was going to stay out of this and I will again, but...

On 2/27/06, Gale, David <[email protected]> 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.

Here is, I think, where the disconnect lives.  I don't think people are
talking about the same things here (tag vs tag).

As you state it here, you feel that a tag is a way to label a specific
state in the repository.  That is, not of a project or subtree but a
specific repository state.

I think most of the others on this list look at tags as a way to tag a
specific code/data set in the repository.  That is, this specific code
here that was just built and will be shipped is now tagged as Rel_1.0.2

The difference is subtle but rather extreem when you start to look at
the details.  The latter view is "somewhat" like CVS in that you have
some collection of code and you "cvs -f" that part of the tree (which may
be the whole tree or just the src part or just the src/mytool part, etc)
The former is always cross-repository detail and really represents a
view of the repository back at a specific revision (as in -r12345 but
via a name)

The problem here is that -r12345 (or an alias) may not be able to
actually represent the code/tag that is needed.  Subversion supports,
for good reason, mixed revision tags/copies/branches.  This is critical as
you may have a mixed set since you have not updated part of the tree
on your machine (for whatever reason).  This is something that CVS does
so well - what you tag is what you have checked out on your local machine
and not just HEAD.  This is what many version control systems do so
badly and end up having "all-hands-off" rules during release build/tag
processing.

What you are proposing is just to provide symbolic names to revision
numbers.  (Or at least, the real meat of what you are proposing)
As such, it seems to miss a number of key elements that are non-trivial
to fix and buys only complexity in that there would be now two ways to
reference information in the repository.

BTW - I agree about tags - the should and must be immutable.  But that
is actually possible with some hook scripts - and the rules can be rather
complex and customized for everyone.

--
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:[email protected]
My place on the web                      http://www.sinz.org/Michael.Sinz