monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] resolving name conflicts; file suturing vs drop


From: Stephen Leake
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Wed, 07 May 2008 22:02:03 -0400
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.1 (windows-nt)

Thomas Moschny <address@hidden> writes:

> Hi Markus,
>
> Markus Schiltknecht wrote:
>> Can you please be more specific? Which three versions of the same file
>> are you referring to? I only see two [...]
>
> Ok, here's the graph again. But be warned, we need a lot of characters ;)
>
>    A: 1,foo,v   B: 2,foo,w
>     /\          /\
>    /  \        /  \
>   |    \______/____\
>   |          /     C: 1&2,foo,x
>   |         /        \
>   |        /          \
>   |       D: 2,bar,y   \
>   |______/              |
>   E: 1,foo,v            |
>    \ 2,bar,y            |
>     \___________________|
>                      F: ???
>
> It looks more complicated, but it isn't. I just added sort of a manifest to 
> each revision, with the following format: "REV: node_id,path,contents".
>
> A and B create foo independently, with different contents. D renames the one 
> from B to bar and changes its content. E is a simple merge, no magic. It 
> contains both files, foo and bar with different contents. Now, in C suturing 
> takes place, denoted by the node_id '1&2' (whatever that means). In C also a 
> content merge took place.
>
> Now, consider F, merging E and C. How does its manifest look like?

It depends on the user's intent; there is no way for monotone to know
what the right thing to do is here.

One example of user's intent is here is the "thermostat" use case. C
is an early attempt to use one file to provide both the Honeywell and
Westinghouse models. But later Abe and Beth realize they need two
separate files, so they switch to E. Then the correct solution for F
is to drop 1&2 entirely, and keep 1, 2.

On the other hand, this could be the "checkout.sh" use case. Then E is
simply mistaken, and in F 1, 2 should each be dropped, but 1&2 kept.

That's why it must be an ncc. 

So we need syntax for 'merge --resolve_conflicts' to express either of
these resolutions.

There are probably other use cases with other resolutions.

-- 
-- Stephe




reply via email to

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