[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: 3-way merge considered harmful
From: |
Florian Weimer |
Subject: |
Re: [Monotone-devel] Re: 3-way merge considered harmful |
Date: |
Tue, 03 May 2005 01:31:48 +0200 |
* Nathaniel Smith:
> On Sun, May 01, 2005 at 06:51:54PM +0200, Florian Weimer wrote:
>> * Nathaniel Smith:
>>
>> > Fortunately, it seems like codeville-merge is a viable replacement
>> > here (it can be applied to both content merges and tree rearrangement
>> > merges), and with some recent improvements that Bram and some other
>> > people (including me) have been playing with, it may (I'm not sure
>> > yet) be strictly more powerful than 3-way merge.
>>
>> Is there some formal model of codeville-merge which one could check?
>
> We're working on figuring out whether it has some formal properties,
Well, it certainly has. I was just asking for a high-level spec.
> actually, like "equivalent to 3-way merge in the cases where 3-way
> merge is the right thing to do", "clean merges are order invariant",
> etc.
Well, without a formal spec, it's hard to tell. 8-)
> Yes, it's possible for two people to make redundant changes. This is
> one reason why it's impossible define a merge algorithm that works for
> all the various I's one might like. Given that, then, the
> responsibility of a merge algorithm is to fail in ways that make
> sense, so the user can have some conceptual model of what the system
> is doing and how to correct for its failings.
And that's where test cases come in. The invariant I (well, I should
have mad that a J, sorry) could be expressed as a test case, which
would address the problem neatly and might have other benefits, too.
However, it seems to be rather desirable to fix this bug.