Re: [Monotone-devel] resolving name conflicts; implementation issues

[Stephen Leake]

On nvm.automate_show_conflicts, I've checked in a partial
implementation of resolving duplicate name conflicts via renaming
(647ae8f26c120d3a0175227173fef119424ec832).

In this thread, I'll address monotone semantics. In another thread,
I'll ask some questions about coding style and C++ semantics.

The UI code is pretty much not there; I defined the
resolve_conflict_opts option set, but there is no code to parse the
resolution string or file. The code assumes we are doing precisely the
test case in tests/resolve_duplicate_name_conflict/. Obviously, this
needs more work.

All of the merge commands call merge.cc resolve_merge_conflicts, so
eventually it will be easy to have them all support
--resolve_merge_conflicts.

The actual conflict resolution happens in roster_merge.cc
roster_merge_result::resolve_duplicate_name_conflicts. For a duplicate
name conflict, the new roster has both node ids present but detached;
they have no associated file name. So I simply call attach_node with
the new file name for each. I'm not sure that's enough; the code in
'merge' that generated this roster knew it was not going to be
comitted, so maybe the roster is incomplete in other ways as well.

What tests should be added to
tests/resolve_duplicate_name_conflict/__driver__.lua to check that the
renames really did get implemented properly? I can think of the
following:

- update to the merged revision, check the file contents

- run log, check that the rename shows up

- modify each file, commit, check history again.


The next step is to add the "suture" resolution. I'll call it
"resolve_suture" instead of "resolve_content_ws". I suspect most
people have a vague idea of what "suture" means in English, but will
be motivated to check the manual to see what mtn means by it.

"resolve_suture" will require a file name for the new content;  I
don't want to require a workspace for this.

For the first implementation, I'll simply drop both old node ids, and
add a new one. This is clearly not enough, but does seem to be the
consensus as a minimum requirement for "suture". Then we'll have a
concrete example for further discussions on how to store the extra
information required for history, future merging, etc.

I'll add the resolution parsing functions as well.

-- 
-- Stephe