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

[Stephen Leake]

"Marcin W. Dąbrowski" <address@hidden> writes:

> I was lurking into this conversation, and while being only a user,
> and not a coder, and I don't get the internals, etc - I was
> thinking about how monotone could interact with the user when ncc
> will occur, and how it could be resolved.

Thanks for your input.

> <snip setting up two heads>
>
> $ mtn merge
> mtn: 2 heads on branch 'main'
> mtn: [left]  01e80706407c1cfa6b1b5c7a88c7ceae493d1c32
> mtn: [right] 8d79b71def0a26652bd1da2c66ac58d301238081
> mtn: conflict: duplicate name 'bar' for the directory ''
> mtn: added as a new file on the left
> mtn: added as a new file on the right
> mtn: error: merge failed due to unresolved conflicts
>
> $ mtn merge_into_workspace t:right

I agree that merge_into_workspace is a good idea; as you say, there
are typically other changes that must be made for a merge to be fully
correct. 

But my understanding is that there is even more work to do to get that
"really right" than I'm doing now for 'merge --resolve_conflicts', so
I'm not looking at it now. I could be wrong.

> $ mtn merge_into_workspace t:left --interactive

Since there is only one conflict here, you could just specify its
resolution on the command line.

If there are more conflicts, this makes more sense.

However, one of my motivations with 'merge --resolve_conflicts' is to
allow the user to spread out the work of resolving each conflict; they
don't have to do everything in one interactive session. But if you
know you have the time, this is a reasonable approach.

> mtn: diffing as content conflict, runnig $VISUAL to resolve
> -- here, user edits the file, and after leaving editor...
> mtn: suturing as 'bar' using edited content
>
> mtn% l
> mtn: misuse: use 'l new_file_name'
>
> mtn% l bar-left

Here you have error-recovery inside the interactive session. I suspect
that would be difficult to implement, but maybe not. It certainly
should be a requirement for this style of interaction; having to
repeat the whole thing because you made one typing mistake would be
intolerable! 

I suspect there would be two levels of errors - user recoverable and
fatal. There is some support for that in the code now; the N and E
macros. However, they throw the same exception, so handling them
differently is difficult. (Sorry, can't help talking about
implementation :).

-- 
-- Stephe