Re: [Gnu-arch-users] Re: version aliases

[David Allouche]

On Thu, Apr 08, 2004 at 05:32:00PM -0400, Stefan Monnier wrote:
> >      Once the archive is specified, archive-wide aliases can be used to
> >      specify branches and versions. In jblack/ archive, there can be an
> >      archive-wide alias "tlacontrib" pointing to "tlacontrib--devo".
> 
> How useful would that be?

That would be useful in allowing people to have the impression they use
arbitrary version names, like "frob-1.0pre2". That is a vocally
requested feature, and I believe it is bound to get more and more
vocally requested.

It also provides for more integrated alternative to version-naming than
symbolic branches and simple configs.


> > A given tree can define several aliases. To prevent silent changes in
> > alias resolution within a tree when the archive is changed, in-tree
> > aliases take precedence over archive-wide aliases. When trees are
> > nested, the aliases in the inner tree take precedence.
> 
> In my experience, aliases for nested trees have no relationship to one
> another so I don't think it's worth it to bother with any special
> nesting consideration.

I have no direct experience in nested trees and configs. Those
provisions were added:

  -- for use with configs, where you get logically-related nested trees.

  -- for the sake of completeness, you need to define _some_ behaviour
     nested trees situation. I though that one would give more value.
     But maybe another one would be better

> > In-tree aliases should be versioned independently from the tree itself,
> > and stored as a precious data within {arch}. As a bonus, that mixes well
> 
> It's not even necessarily useful to version them.  So, to keep things
> simple I wouldn't version it at all (and wouldn't keep it in any archive:
> it's a user-only thing).

Okay. Let us not version them.

As an extra feature, you could store your in-tree aliases in a
separate archive-metadata branch, so you can easily save, restore and
share your work environment.

The point of the previous paragraph is saying that "do not
version-control alias" is inappropriate, because that is a natural and
useful thing to do.

But that can be made fully optional, and not part of the "core alias
feature", whatever that is...

-- 
                                                            -- ddaa