Re: [Gnu-arch-users] distinguished branch name, "clone"

[Tom Lord]

    > From: Miles Bader <address@hidden>

This is a harder area than it might seem at first.   And here Walters
probably thought he was just making a little convenience hack :-)

    > Personally what I've taken to doing is creating little one-line shell
    > scripts in my project trees that capture common actions, e.g., in my tla 
dir
    > I might have an executable file called `+merge' that contains:

    >   tla star-merge address@hidden/tla-...

    > When I want to do a merge from Tom, I just type `+merge' (and similarly 
for
    > various branches of my own archive).  The `+' at the start of the name
    > prevents it from being treated as a source file.


I think that that's closer to the right idea.

For reasons you cited (it makes a _maybe_ common case into a special
and privileged case) I'm not too fond of FOO impliictly meaning
FOO--mainline.

This relates to a key part of the original idea of the every-mythical
`overarch':

There's lots of patterns (I claim) of how you might set up branches
and each project can decide which pattern to best support on a
project-by-project basis.  The idea of making "mainline" significant
is one example of such a pattern -- but there are reasonable
alternatives.

Once a project makes those choices about arch usage, there's a bunch
of "boilerplate" for what users and prospective contributors to the
project should do.

The upshot of that is that while there's a high level action a user
might want to take -- across multiple projects, like "submit a change
to this project" or "give me a tree for making a quick change to
submit to this project" or "give me a branch for working on a big
change to submit to this project" -- those high level actions
translate into actual arch commands, and commands in ancillary tools,
on a project-by-project basis.   "give me a tree for making a quick
change" might mean one thing in the context of XOuvert and something
rather different in the context of tla.

So the open questions in my mind are:

        a) is there _really_ a set of "high level operations"
           that makes sense across many projects?  (I think there
           is, though it's probably an open-ended set.  "clone" 
           might be an example.)

        b) if there are such high level operations, do they
           really translate into arch commands in different
           ways depending on the project?  (Almost certainly -- 
           the choice of what the branch name of HEAD revisions being
           a trivial example.)

        c) regarding those "different translations" of high level
           operations into arch commands, if we regard the 
           translation as "parameterized", what parameters come
           from the project maintainers and which from the user?
           What are the "types" of those parameters?  (This is 
           where it starts to get hard.)

        d) assuming we come up with the set of high level operations
           and the parameterized translation into arch commands and
           a way to figure out who supplies what parameters:

           what should overarch be?  vaguely, it should let a
           maintainer publish her parameters and a user specify
           his, and combining those, use the high level commands.
           (I don't personally feel quite ready to even think about
           answering this one.)


I'm not sure that `overarch' can _really_ be created.  Ideally it can 
and the end result is a very simple to learn and use "universal
interface" to many arch-using projects.   But the failure modes of the
design are that it just comes out hard to understand, overengineered, 
obscure, and pointlessly hard to use.

The spirit of the "implicit mainline" idea is to answer the above open
questions with:

        (a) yes

        (b) perhaps, but it's easier just to pick one pattern that
            most people will want to use and optimize that

        (c) no parameters from the project maintainers -- the arch
            maintainers will set those to constants.

        (d) so, overarch should just be some new defaults and commands
            added to arch

I can't say that that's obviously wrong.   Oftentimes, simplifying the 
problem you thought you wanted to solve leads to great things.   But 
my suspician is that it's premature in this case.

There's a different (but related) slice through the mainline idea,
too:  You've seen me make analogies between the arch namespace and
library cataloging systems (like Dewey Decimal or Library of Congress
classifications) repeatedly.

Extending that analogy: the arch namespace really just provides a
_syntax_ for a cataloging system.  It doesn't provide much of a
semantics.

The library systems provide both a syntax and semantics:

        QA76.73.L23S73

is a syntacticly valid Library of Congress classification, but you'd
need the multi-volume guide to the meaning of LC classifications to
figure out what kind of book would get that ID.

One idea is to make "the official arch guide to namespace usage" --
analogous to that multi-volume guide from the library of congress.
That's the path that the "implicit mainline" hack heads down.

Another idea is a bit more like, sigh, XML:  provide a mechanism by
which anyone can publish their own namespace-usage guide for their own
little corner of the universe, and anyone else can use all of these
separate guides as if they were one big one.   That's the overarch
approach and, although it's a much harder idea to fully develop, it is
at least closer to the peer-to-peer, we're-all-equals, design of arch
so far.

-t