Re: [Gnu-arch-users] version aliases

[Aaron Bentley]

David Allouche wrote:
> To start with, let's assume we can do _without_ the prefix, we'll see if
> it blows.

A single-character prefix requires the user to know what may be
expanded.  Without a prefix, the program must infer from context what
should and should not be expanded.  This is a problem I'm currently
having with pyaba, because pyaba doesn't use a prefix character, but it
runs aba scripts.  It doesn't know enough about the scripts to determine 
where it's legal to perform alias expansion.

So I can use "pyaba changes acur" to compare my tree to the latest
revision in the archive, but if I want to use aliases with non-native
commands, I must run "aba" instead.

> What are the perceived needs for aliases, out of tree?
>
>   -- Easy "get" for the general public. That involves global namespace
>      issues, so aliases are probably not the right solution for this.
>      Instead the concept of "published" revision, associated to an URL,
>      fits the bill.
>      
>      I am not sure that's what "grab" does, but it would make sense have
>      a command which gets a remote file, and use its data to register an
>      archive and get a given revisions.

Indeed, that's what grab does.  There's some decent documentation on the
wiki:
http://wiki.gnuarch.org/moin.cgi/Tla_20Reference_2fgrab

Pyaba now treats all revision/version locations as aliases for the 
revision/version name.  Writing a "get" that uses the revision location 
is next on my list.

>   -- Easy "get" in a personalized environment. For example, when working
>      with microbranches, it would be useful to be able to easily get a
>      given microbranch, and remove the sandbox once the work session on
>      the branch is finished.
>
>      This feature needs a "archive alias" context. I could
>      alias my personal archives to be able to ommit the email part. So
>      "address@hidden" becomes "2003b",
>      "address@hidden" becomes "tmic", and
>      "address@hidden" becomes "jblack".
>
>      Archive aliases are global user customizations and must be stored
>      in ~/.arch-params.

I find it very convenient to also store global version aliases.  They 
allow one to alias "address@hidden/tla--devo--1.3" to "devo". 
That's very convenient to use, and doesn't require any server roundtrips.

>      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".
>      So, "get jblack/tlacontrib" would actually be understood as "get
>      address@hidden/tlacontrib--devo". Then, the usual
>      last-version-revision defaults kicks in and we get the last
>      revisions of "address@hidden/tlacontrib--devo--1.3".
>
>      One important thing with archive-wide aliases: they need only be
>      expanded at the start of package name.

Wow, that's quite an end-run around Tom's naming scheme.  That's about 
halfway to arbitrary package names.

> In-tree aliases
> ===============
> One feature I find desirable is being able to tell what's missing from
> the "aba" branch within my tree. I need a local tree for "aba" for this,
> but since I have no control over that branch or archive, I cannot put my
> aliases in there. However, I can put a {arch}/++aliases symlink there
> which points to the alias definition in my personal branch.

Actually, I think the missing-from command is a better solution for that 
problem, since it only requires you to have a library revision for the 
non-owned version.

But global version aliases work fine for that case too, right?

> In-tree aliases should be versioned independently from the tree itself,
> and stored as a precious data within {arch}. 

Gak!  You're kidding me, right?

Sigh, if you really want this, I think The Right Way is a nested tree.
Then you have {arch}/{arch}/=aliases.  Don't say that Arch should be
storing precious data-- that's Just Wrong.

But you should give serious thought to whether version-controlled
aliases in foreign trees are worth the effort.

If they are, would per-version aliases fit the bill just as well?
(per-version aliases would only be stored globally, but only considered 
when the current tree-version matched their version)

I prefer global aliases to local ones, so the only reason I see for 
in-tree aliases is for people working on the same project to use the 
same alias conventions.  So I figure precious aliases are mainly useful 
as an override.

> As a bonus, that mixes well
> with the "symlink" in foreign tree solution, with the added restriction
> that the in-tree dictionary is only updated silently if it is not a
> symlink.
>
> Poor FAT people can use shortcuts to masquerade for symlinks.

Somehow, I don't think we're ever going to see FAT support in tla.  It's 
too far away from POSIX.

> Namespace logic
> ===============
>
> So far, we have four namespaces: archive aliases, archive-wide aliases,
> in-tree aliases, and canonical arch names. We need some escaping
> mechanism to be able to garantee predictible behaviour.
>
> One possible escaping scheme could be:
>
>     archive-alias/
>     /archive-wide-alias
>     :in-tree-alias
>     !canonical-name

I'm using ':' for another purpose in my automatic aliases, as a 
separator, so I'd prefer avoiding that character.

I'm not totally sold on the need for escaping aliases.  I'd expect users 
to adjust their aliases so they don't overlap, or else use non-alias names.

It seems to me that the order should be
1. precious in-tree or source in-tree (not both)
2. source in-tree (only if there's no precious in-tree)
3. global archive and version aliases
4. archive-wide aliases

That always gives the user the option of overriding aliases they didn't 
choose.

Aaron