Re: [Gnu-arch-users] the state of the union

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > >   In the past, efforts to unify the changeset mechanisms of the
    > >   various projects failed.  The primary sticking point seems to have
    > >   been disagreement about the necessity and desirability of inventory
    > >   tags.

    > Ironically, one of the "major" points on my semi-formal list of things
    > I'd like to see in the next changeset format, is to orient changesets
    > around logical file identity ("inventory tags") rather than
    > filenames. 

I'm unclear what you mean by "orient" here.

Changesets have a pretty clear abstract structure.   The individual
file diffs happen to be stored in the tar bundles by filename, but the
file id -> patch mapping is utterly trivial to compute from that plus 
the index files.   How in the world could changesets be more
"oriented around logical file identity?"   


    > The metaphor just makes much more sense; it's the only
    > intelligent way to describe changesets as functions, 

I don't know about only but I agree that changesets (under the dopatch
point of view) are functions (mapping input trees to output trees
under the rules of possibly-inexact patching).

I expect arch to evolve in this area, btw.  Domain-specific
replacements for mkpatch/dopatch (not necessarily per-file --- even
per-tree) open up a wealth of possibilities.


    > and would eliminate most of the strange edge cases we see with
    > inexact patching. More on that when we get to the point where we
    > can start designing the next format (at this rate it'll probably
    > be tla 2.0).

    > I believe that this approach will give an extremely simple description
    > of how to apply a changeset, which behaves in the expected manner in
    > all cases (generating a changeset won't appreciably change).

I'd like to hear more specifics about what "this approach" is.  So far
it sounds like a noop permutation of what's already there.

    > 
    > >   Indeed, cherrypicking has proven very useful in Arch.  And=20
    > >   the reason cherrypicking works in arch is because of our changeset
    > >   format.  And the reason our changeset format works is because of
    > >   inventory tags.

    > Don't underestimate that point. It's also the primary difference
    > between arch and svn - and in fact, monotone is pretty much
    > functionally equivalent to svn in every significant respect.

I think that monotone's weirdness around manifests is pretty
un-svn-like.   I strongly second your larger point that, of all
things, inventory ids are really the killer meme that makes arch
possible.   Everything else is layered on that.


    > Here's how I like to phrase it to make the point blindingly obvious:

    > Everybody knows that changesets and tree-versions are interchangeably
    > convertable. Given one, you can generate the other.

    > This is only true in the presence of complete history.

!  Yes.  As you probably know, you are compressing the whole failed
"common changeset" dialog to the obfuscated wedge issue that broke it
up.  The only self-consistent position against inventory ids is one
that denies the utility of distributed revision control (because in
centralized control, complete history is always available).


    > The fundamental conversions are:

    > A complete history of tree-versions converts to a complete sequence of
    > changesets.

    > A tree snapshot and a changeset converts to a pair of tree-versions.

    > When you have a history *fragment*, you can still generate
    > tree-versions from changesets. You can't do a single damn thing with a
    > history fragment expressed as tree-versions, except to fetch one of
    > them.

    > The ability to fragment history in this manner is what we mean when we
    > talk about "distributed development". And no, monotone doesn't do
    > it. It just hauls complete history around to all the clients.

Nicely said.   Definately different then how I would have expressed
the same facts and so hopefully useful.  I'll have to remember that
way of putting it.

Along these same lines: a changeset corresponds to a commit and that
is an (approximate) expression of a logical transformation rather than
just a literal set of text diffs.   You describe changesets as
"functions": those functions are, in some sense, what arch-using
programmers are in the business of writing.

    > In the simplest possible terms:

    > We can do something intelligent with the contents of a *single*
    > revision (that is, one changeset), including merge it. The only thing
    > you can do with a single revision in the other systems is to fetch it.


    > > * CA Response: Do Not Be Afraid of the XL

    > >   If Jblack's attitude towards XL is at all typical I've done a
    > >   hopelessly bad job of explaining my intentions.

    > Personally I'm reserving judgement. I can guess at what you're
    > thinking but don't see any point in doing so.

    > Furth itself I'm already happy about because I've figured out how to
    > wedge any arbitrary language into it - it's like the exec() barrier,
    > only better. It's overcomplicated for this problem but I don't
    > care. So it's not possible for you to screw that part up.

That's a good sign.   (I.e., design aspects that achieve that level of 
plausible inevitability and obviousness that nobody owns them.   They
become a universal technique rather than an arbitrary aesthetic
choice.)

I agree about the characterization of the furth inner interpreter as
an exec()-like barrier.

Add to that the combined ideas of a generic collection of lisp-like
Values (i.e., uncomplicated sum and product types over a few basic
domains, so that data can be universally exchanged without excessive
or exclusionary type-system hair) and a register machine abstraction
as the basis of the right approach to FFI design and you're there --
xl is the one with second-least-amount of hair for Values, Furth is
next, and Pika is fully general.

If you know what I mean.

-t