Re: baz format archives in tla

Ludovic Courtès wrote:
> Besides, my understanding was that the ultimate goal was to remove the
> obligation to use a `c--b--v' name space, and that this archive format
> change was one step in this direction.  Is this correct?
>   
If you ask me, the question is a strong, resounding: "sorta".

Liberalizing the syntax of the name-space? sure.

Refactoring Arch a bit so that lower-level components are less dependent on
the name-space structure?  Yeah, good idea (c.f. `revc').

Eliminating the concept from play?   Tossing aside stuff that supports 
that or
a substantially similar structured name-space?  Uh... no.

Everyone knows that revisions of a program form a kind of tree-shaped
graph.   Every revision is either "the first" or has a parent.   Every 
revision
has children -- those revisions for which it is the parent.

Two things people tend not to appreciate:

    1. There are really two such graphs: one intrinsic and the other 
extrinsic/intentional.
    2. We have to assume that in the general case we have incomplete 
knowledge of
         both graphs and that even when we can obtain complete knowledge 
about
        some parts, obtaining that knowledge can be expensive with 
knowledge about
        the intrinsic graph costing a lot more than knowledge about the 
extrinsic graph.

The "intrinsic graph" is the literal, mechanical history.   Someone 
checked out
revision A, made changes, committed revision B -- so A is the parent of B.
The intrinsic graph is the primary stuff of "blame" functionality.  It's 
for answering
questions like "how did we get here?".    (Of course, someone can create an
intrinsic link from A to B without literally checking out A first but 
that's beside
the point  We're still pinning all the blame for changes from A to B on 
the guy
who commits B.)

The "extrinsic graph" is a map, for humans.   It asserts a logical 
ancestry among
revisions.   The extrinsic graph is composed of human-made assertions that
"the next thing after A is B" or "A is related (by branching) to B".   The
extrinsic graph is how we track the work-product of projects and work-flows.
When we don't care *how* a project or production pipeline produced a
certain result but only care what their stated results are -- we look at 
the
extrinsic graph.

An extreme example, only slightly silly, might be a project to pick "the 
best
GUI MUA for GNU/Linux".   One day, the latest version from that project
might be Evolution.   Another day, the latest version might be Thunderbird.
For a given revision in the project we can ask two separate questions:
(1) How was this revision created?  (The intrinsic history of Thunderbird.)
(2) How as this revision chosen? (The extrinsic history of the "best MUA"
lines of development.)

Intrinsic history is, by definition, an arbitrary tree structured graph 
(absent
time machines).

Extrinsic history has the intention of being accessible to people: of 
being subject
to cataloging and retrieval based on that cataloging.   It is natural to 
impose
structure on the extrinsic graph in order to make it navigable.   In the 
current
world of buzzwords, the extrinsic history wants a nice, broadly applicable
ontology -- for which c-b-v-r was simply my best guess.

Hope that helps,
-t