Re: [Gnu-arch-users] version aliases

[David Allouche]

On Mon, Apr 05, 2004 at 05:50:45PM -0400, Miles Bader wrote:
> On Mon, Apr 05, 2004 at 09:04:40AM -0700, Tom Lord wrote:
> > Not really.   Aliases would need a distinctive syntax -- perhaps a
> > prefix character.
> > 
> >     tla get :latest-emacs
>
> [Not that a single-character prefix is all that annoying, I'm just curious
> why it would be _necessary_.]

Let's try to put up a complete, sane, proposal for aliases...

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

Beware, this is an intensive exercise in kibitzing. But I have the
feeling someone needs to gather all the ideas which have been floating
around in a coherent proposal. It's not perfect, but I hope that is
going to be a useful starting point for future discussion.


The branch-version cartesian plane
==================================

That may seem somewhat unrelated, but actually it does relate to alias
in subtle but important ways. Officially, the branch--version ordering
is unimportant and arbitrary, "it's a cartesian plan" said Tom.

That promise can be fullfilled in the CLI, just make the CLI treat
indifferently names of the form category--branch--version or
category--version--branch. The syntactic constraints on branch and
version names allows this without ambiguity.

To maintain a perceived consistence, a version name should be associated
an intrinsic branch/version ordering, used when listing versions or
branches. Since property is immutable, that information can be provided
by the presence or absence of files in the archive without any of the
usual metadata issues.

For example there could be a =meta-info/version-branch/ directory
containing empty files "category--branch--version" pointing to versions
whose branch--version order must be reversed when producing listings.

Maybe a safer solution (w.r.t. to voodoo locking issues) would be
creating a "=version-branch" file within the directory of the version,
but that's not an essential difference.


Out of tree aliases
===================

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.

     No actual need for aliases here.

  -- 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. Archives might provide a "recommended" alias,
     but that would have to be versioned metadata because the canonical
     "ddaa" archive changes when I cycle archives. Updating the local
     aliases after archive changes needs more thought than I want to put
     in it right now.

     Archive aliases can always be recognized from the context, they are
     only useful in fully qualified names. The part _before_ "/" is
     either an archive name (with the usual restrictions) or an archive
     alias. This distinction can even be made completely unambiguous by
     forbiding archive aliases from containing the character "@".

     When there can be an ambiguity, eg. with abrowse and archive-mirror
     when the parameter matches an archive alias or a branch alias, the
     ambiguity can be eliminated by appending a "/". E.g. "jblack/"
     refers to the jblack's archive, not whatever package-version I may
     have associated with the "jblack" alias with another aliasing
     mechanism.

     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.

  -- Easy use of archive commands: abrowse, revisions, tag

     I think that can be adequately adressed with the aliasing scheme I
     just described.


In-tree aliases
===============

Alias are more needed for commands which operate within a tree, that is
mostly the various merge-related commands: "missing", "star-merge",
"replay", "logs", "cat-log".

The number of branches which can be meaningfully used for merge-related
commands within a tree is limited, but those are very frequently used.
In addition, those are always fully qualified: there is no meaningful
use of referring to an "implicit last version", which may silently
change.

The tla-partner solution is unambiguous, but it does not add
significant expressiveness over the equally unambiguous "prefixed alias"
solution and is more lengthy to type.

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.

I can envision two main uses for in-tree aliases:

  1. parallel branches (collaborators, microbranches)

     Such branches would be named after the owner's nickname or the
     feature name. For example "tom", "jblack", "win32", "aba".

  3. branches roles

     Branches which have a particular relation to the current tree in
     the merging topology. For example "master", "fixes", "stable",
     "devo".

     There can also be several branches taking the same role. The
     obvious example is "partner" branches as supported by "aba merge",
     that is all branches which we regularly star-merge within the tree.

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.

There is a desire to minimize the amount of metadata-related revisions
within development branches. After all, a branch is mainly about
software development, and only incidentally about version-control...

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
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.


Storage of archive-wide and in-tree aliases
===========================================

Archive-wide aliases can be stored in a special metada version, like
"archive-metadata--archive-wide-aliases--0". All the information would
be stored in the patch-logs. A possible syntax would be:

   <alias> <non-arch part of package, version or revision name>
   ...

Similarly, in-tree aliases can be versioned in
"archive-metadata--in-tree-aliases--0".  Sadly, that would break with
archives which are commitable by multiple users with hand-managed
permissions restricting write access, but that's a bit abusing arch
anyway.  One open issue is whether in-tree aliases should be versioned
synchronously (in a way which is functionnally equivalent to versioning
within the tree) or asynchronously.

If asynchronous versioning is choosen, all the alias data can be stored
in the log files of the metadata version. A possible syntax would be:

    * <non-arch part of version name>
    <alias> <fully-qualified version name>
    ...

One way to handle synchronous versiong simply, with increasing cost as
we are working with a more outdated tree, is to use:

    * <non-arch part of revision name>
    <alias> <fully-qualified revision name>

If the tree revision is older than the revision given in the log file
for the tree-version, then we check for the previous revision of
archive-metadata--in-tree-aliases-0.


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

With the additional restriction that aliases cannot contain "@" or "--".

That's the point where using a mandatory prefix for aliases seems to
become necessary so tla stays upward compatible with existing tools.
So "anything-legal" is always equivalent to "!anything-legal".

If upward compatibility is the only concern, that can be a user-local
configuration.

If the mandatory-alias-prefix feature is disabled, and none of the
escaping syntaxes is used, the name resolution scheme is only ambiguous
for the non-archive part of names.

  1. head is the part before "--"
     tail is the part after "--"
     if there no "--", tail is null

  2. if we are within an arch tree
        try to match head with an in-tree alias
        if no match is found, recurse into for parent trees
        if a match is found, go to N

  3. if the name had an archive part
        try to match head with an archive-wide alias
        if a match is found, go to N

  4. if there is a default archive
        to match head with an archive-wide alias in the default archive
        if a match is found, go to N

  5. assume the name is a canonical name

  N. assume match--tail is a canonical name
     (that's where the cartesian plane thing becomes important)


Epilogue
========

Congratulation for going that far. You have earned all my consideration
:) I'm tired of writing this thing. Let's post it and see what happens.

Comments more than welcome.

-- 
                                                            -- ddaa