Re: [Monotone-devel] merge conflicts

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 12.12.09 08:56, schrieb Stephen Leake:
>> On Fri, Dec 11, 2009 at 6:20 AM, Thomas Keller <address@hidden> wrote:
>> 
>>>> $ mtn automate show_conflicts -b your.branch LEFT RIGHT
>>>>
>>>> Unfortunately the show_conflicts command isn't very useful to use before
>>>> you merge, because it might report f.e. content conflicts which the
>>>> internal monotone line merger might be perfectly able to resolve on its 
>>>> own.
>> 
>> This suggests an enhancement option: '--no-resolved-internal', to
>> exclude such conflicts from the show_conflicts output.
>> 
>> That would require calling the internal merger to see if it succeeds,
>> when listing the conflicts. That's not hard.
>
> Hi Stephe!
>
> If you're up for that job, then great, just go ahead! 

Well, I was mostly pointing out that someone who wants it could do it :).

> But are you really sure this should be an additional option and not
> the default...?

It is not always the case that the results of the internal merge are
correct, so I often want to review them. Consider a file containing:

line 1
line 2
line 3


now two people edit it, for the same reason, but with slightly
different results:

Abe:

line 1
added stuff
line 2
line 3


Beth:

line 1
line 2
added stuff
line 3


The internal merger will produce:

line 1
added stuff
line 2
added stuff
line 3

As it happens "added stuff" has the same effect whether it occurs
before or after "line 2"; Abe and Beth just have different style.
But it is wrong to include it twice.

This happens with make targets, C include statements, Ada context
clauses, etc.

It doesn't happen often, but it happens enough that my internal rules
for promoting from a work branch to main require manual review of the
"resolved-internal" conflicts.

My Emacs front-end makes it easy to review and override or accept
these conflict resolutions. 'mtn conflicts' also considers them
already resolved.

I suppose I could pass "--show-resolved-internal", rather than making
it the default. But that isn't an option until someone implements
"--no-resolved-internal" :).


Getting back to the original point, I'm not clear that 'mtn automate
show_conflicts --no-resolved-internal' is really better than 'mtn
merge'. The point is to detect whether the merge will succeed. Both
commands do the same amount of work before producing a "no" answer;
'mtn merge' keeps going if the answer is "yes". The work must be
repeated by 'mtn merge' if you do 'mtn automate show_conflicts' first.

'mtn automate' is better/faster if you already have an automate
session running. But in that case you are probably prepared to process
automate output, so you can just count the unresolved conflicts (which
is what my Emacs front end does).

Ah! 'mtn conflicts show_first' will report zero conflicts if all of
the conflicts are resolved, and conflicts that can be resolved by the
internal merger are marked 'resolved-internal' by 'mtn conflicts
store'. So this sequence:

mtn conflicts store
mtn conflicts show_first

will produce the desired result. 'show_first' outputs either:

mtn: content files/foo
mtn: possible resolutions:
mtn: resolve_first interactive "file_name"
mtn: resolve_first user "file_name"

or:

mtn: all conflicts resolved

It might be better if 'mtn conflicts show_first' returned a "failed"
status to the OS if a conflict was shown, and a "success" status if
not. Does mtn have a simple mechanism for that?

-- 
-- Stephe