[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Aaron Bentley
Subject: Re: [Gnu-arch-users] Star-merge Fatally Wounded
Date: Fri, 10 Sep 2004 16:47:21 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040309)

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:

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

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

% tla commit -s "merged latest A"

% 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

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 Bentley
Director of Technology
Panometrics, Inc.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]