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

[Stephen Leake]

Matthew Nicholson <address@hidden> writes:

> William Uther wrote:

>> This is a tricky problem.  e.g.
>>    a   b
>>     \ / \
>>      c   d
>>      |\ /|
>>      | e |
>>      |   |
>>      f   |
>>       \ /
>>        g
>> Lower case letters are revisions, not files.
>> a and b each create a file 'foo'.  I'll refer to them as fooa and
>> foob.
>> c sutures the two foos together - making fooc.
>> d edits foob.

making food

>> e merges the changes made in d to foob into fooc.

making fooe

>> f splits fooc into ??

foof1 and foof2 (see below)

>> g merges d and f.  What happens to the changes to foob in rev d?
>> Are they dropped?  Are they merged into both child nodes of fooc?
>> Only one child node, and if so, which?
>> No imagine another child revision of a that makes changes to fooa.
>> It then gets merged with rev g.  What happens now?
>
> So this sort of thing makes me want git's throw "history to the wind
> and worry about content" approach, but we can approximate that with
> fancy UI.  Basically you have another non-content conflict when g
> merges d and f.  

Consider the user-level meaning of what's going on here. In terms of
the canonical use cases I presented earlier, this could be either use
case. 

For the "checkout.sh" use case, Abe and Beth have both written
checkout.sh in a and b. Then Abe sutures them together in c, while
Beth improves her version in d. Then Beth merges her changes with the
sutured version in e. So far everything is fine.

Then in f someone mistakenly decides that suturing was wrong, and
wants to split "checkout.sh" into "checkout-abe.sh" and
"checkout-beth.sh". That's simply a mistake, and should be disapproved.

On the other hand, this does make sense for the "thermostat" use case.

If a has Abe's Westinghouse model in "thermostat.c", and b has Beth's
Honeywell model in "thermostat.c", then 'c' is a mistaken suture, 'e'
is perpetuating the mistake, and 'f' is fixing the mistake. Then
merging food into foof2 would be merging Beth's current Honeywell
thermostat model into 'thermostat-honeywell.c'.

That actually makes sense; it might be a while before Beth and Abe
realize they need separate files. So initially they thought suturing
was the right way to go, but then later changed their minds. In a
well-run project, they would split 'e', but splitting 'c' is not
totally unreasonable.

> In f you have split files, we will call them food and fooe, 

Hmm. That's confusing names; I hear it as "the version of foo in d"
and "the version of foo in e", which is _not_ what you meant. Let's
call them foof1 and foof2.

> in d you have foob. I don't know how monotone's merger works, but I
> imagine, when it is time to merge f and d, the merger looks at fooe
> and food and realized they have a common ancestor in foob. The
> conflict happens because we don't know if we should merge foob with
> food and/or fooe or if we don't merge at all and just have a non
> content conflict (to be possibly resolved by suturing foob with fooe
> and/or food.

Merging happens two revisions at a time. So when attempting to create
g, e is not considered. So the file merger is looking at foof1 and
foof2 on one side, and food on the other. It could merge food into
both foof1 and foof2, but it would be better to declare a conflict.
The conflict is detected by noticing the split operation in the path
to the common ancestor. 'merge --resolve_conflicts' could resolve the
conflict by merging into foof1 and/or foof2 at the user's choice.

Merging g and e would be similar, as would merging e and f.

-- 
-- Stephe