Re: [Gnu-arch-users] Star-merge Fatally Wounded

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > > The [***] step is the "user error" because, at that time, A-1 is not
    > > the latest revision.

    > Here is an alternate scenario that does not involve user error:

That still involves a user error in the sense that Brian and Albert
(your example folks) haven't coordinated their activities enough to do
what they're doing unless they are prepared for this outcome.

I.e., they *have* committed a user error --- the error isn't any
specific tla command invocation so much as an overall failure of
process design.

You and I are now just putting differnt adjectives on the same basic
facts.   You say:

    > It is impossible for users to detect and prevent this scenario
    > using Arch.  They can only do it by communicating out-of-band:
    > "Albert, don't star-merge me yet; I'm merging you.", "Okay,
    > Brian."

and I say: right!  exactly.  their failure to have that conversation
(or take steps to avoid needing it, or be prepared to recover from its
absense) --- that's the user error.

    > For Arch to solve this problem, Brian would need a way to
    > prevent Albert from star-merging from his branch.

Perhaps higher-level process tools, added to or layered on arch, will
provide that.


    > Star-merge computes the last merge in terms of the sequence of FROM. 
    > That's an arbitrary decision, but it's fine 99% of the time, because as 
    > long as you don't have parallel merges, computing it in terms of the 
    > sequence of REFERENCE would produce the same answer.

    > But when you do have parallel merges, the sequences of A and B disagree 
    > about which is the most recent merge.  A calculation of ANCESTOR' using 
    > the sequence of REFERENCE will not produce the same answer as a 
    > calulation of ANCESTOR using the sequence of FROM.  It's a bit like 
    > relativity.  Regardless of timestamps, neither merge is the latest merge.

I keep coming back to the idea that with mirrors (for example) and
distributed file systems (for example) etc.....   arch simply can not 
reliably solve this problem.   It's a physical fact of the universe
that the arch process has imperfect information.   User's *must* fill
in what's missing.

This is different *only*in*degree* from saying:

   No, arch won't write your program for you.  It's just a 
   revision control system.


    >  > Here's the user error:  Which existed first?  A-2 or B-2?

    >  > Without loss of generality, let's assume that A-2 existed first.

    > In terms of Arch, neither one existed first.

That is not, strictly speaking, true.

In terms of ancestry ordering the revisions are unordered --- but that
is a different statement.

    > > Consequently, what you (Abentley) propose is to take the very regular
    > > behavior of a command, add an arbitrary exception, and that exception
    > > doesn't really solve the problem.

    > The way I see it, *not* performing the same calculation for FROM and 
    > REFERENCE is just an optimization, based on the fact that the result 
    > will be the same in the common case.  However, in the uncommon case, 
    > this optimization does not produce a correct result.  So I think we need 
    > to perform both calculations, so that we can produce a correct result. 
    > This is what I've proposed.
    > 
    > > I'd rather have the regular command
    > > without the hairy yet imperfect exceptions.  
    > 
    > Star-merge's charter is to
    > 1. find a common ancestor
    > 2. Use that information to perform a merge in a working tree
    > 
    > When there is no common ancestor, it is erroneous for star-merge to 
proceed.

It most certainly is not.

With a slight enhancement to what "merging" means --- star-merge's
behavior in ddaa's scenario records useful information.

Arch is, among other things, just a logical calculus for distributed
transactions (modelled over filesystem trees).   This is a big thing
that I think is widely underappreciated (because we've only barely
begun to exploit it).


    > To sum up, this is why I think star-merge should halt in this
    > scenario:

If you insist (because it is *just* the right thing for *your*
infrastructure) --- please just instead layer on a new merge command
and leave poor little (elegant) star-merge alone.

Really... it's useful.  It records "Oh, we had to do a txn here but
then later discovered two nodes weren't in sync".   That's useful.

-t