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

[Aaron Bentley]

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:

Brian:
% tla get B
* getting B-1
% cd B-1
% tla star-merge A
* star merging A-1

Albert:
% tla get A
* getting A-1
% cd A-1
% tla star-merge B
* star merging B-1

Brian:
% tla commit -s "merged latest A"

Albert:
% tla commit -s "merged latest B"

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."

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

> I don't believe that, what with mirrors and all, the star-merge
> command can reliably detect this situation.

Out-of-date mirrors are one potential cause of this problem, but there 
are other scenarios that do not require anyone to be using out-of-date 
information, so I think they're a red herring.

Fundamentally, Arch doesn't have a concept of time, it has a concept of 
sequence.  patch-5 comes after patch-6, no matter what timestamps appear 
in the log files.

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.

> 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.

> 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.

> The trick for users is to avoid sawing
> nails, hammering boards, or star-merging when star-merge doesn't
> apply.

Since this isn't a user error, I don't think that applies.

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

1. It's impossible for users to avoid this scenario using Arch alone.
2. It's hard for users to determine the cause of the problem.  It took 
me several hours.  I understand it took longer for Canonical.
3. star-merge has all the information it needs to detect this problem.
4. star-merge is violating its charter by ignoring this information.

Aaron
--
Aaron Bentley
Director of Technology
Panometrics, Inc.