Re: [Gnu-arch-users] Status of global and tree aliases

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    [version variables, tree variable, user variables, etc....]

We're talking past each other in mostly unrecognized agreement,
afaict.

There's various "places" (let's call them environments) where
definitions can be stashed.   For example: in a given revision,
applying to all instances of that revision;  in a given project tree,
applying just to that tree.   These nest and variables can be
shadowed:  my tree variable can override your revision variable, etc.

Whenever I ask for the value of a variable I have to specify from
which "place" I'm asking.   "Give me the value of X as seen from this
project tree" vs. "Give me the value of X as (would be) seen from a 
pristine copy of revision Y."

One key thing I'm hoping to hold on to is that, within each of those
"places", all of the variables from all of the enclosing scopes are
combined into a flat namespace.   (Sure, maybe you can ask for a value
"not from here, but from my parent environment" --- but within each
environment, all the names are in one namespace.)

What's completely apparent from this thread is that deciding _how_ 
the variables are combined into a flattened namespace has yet to be
answered with precision.   It's fairly easy to see the systematic 
approach of:

        bindings-per-revision
        bindings-per-tree
        bindings-per-tree-per-revision
        bindings-per-tree-per-version
        bindings-per-tree-per-branch
        bindings-per-tree-per-category
        bindings-per-tree-per-archive
        bindings-per-user
        bindings-per-user-per-revision
        [....]

but that starts to look awefully hairy and, anyway, do
"bindings-per-tree-per-revision" shadow or are they shadowed by
"bindings-per-tree"?   That sort of question.

What if some user wants a scope that is sufficiently strange to
not build-in to arch:

        bindings-per-tree-per-revision-per-day-of-the-week

-t