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

[Stephen Leake]

In revision FIXME:
n.v.m.automate_show_conflict, I've rewritten ss-existence-merge.text.
It's now more logical, and describes issues with sutured nodes whose
parents are also sutured.

A first test with such a case is passing; see
tests/resolve_duplicate_name_conflict_multiple_parents

All other tests except one are also passing. I updated five of them:

  2 (imp)_merge((patch_foo_a),_(delete_foo_))
267 merge((drop_a),_(rename_a_b,_patch_b))
268 merge((patch_a),_(drop_a))
269 merge((patch_a),_(drop_a,_add_a))
469 update_with_pending_modification

These all demonstrated die-die-die, now they show conflicts.

This is now failing:

371 resolve_duplicate_name_conflict               FAIL (line 109)

This is because I changed the way suture ancestor node ids are
handled, and it broke something somewhere. I need to rethink how
suture ancestor information is stored; the current code and docs are
not consistent.

There is one potential issue. In the marking map, the birth record now
stores the node id and birth revision for _all_ sutured parents of a
sutured node. Thus if a work flow requires suturing new files into one
file, this record will grow without bound. Such a work flow seems
unlikely, but I'm sure someone will think of doing it :).

For example, if nodes 1 and 2 are sutured into 3, then 3 and 4 are
sutured into 5, the birth record for 5 has 1, 2, 3 and 4 in it,
permanently.

This allows checking for conflicts between sutured nodes; for example,
if a parallel branch has not yet been sutured and one of the parent
nodes is modified or deleted, and the branch is merged back in.

Since this is in the marking map, not the main database, I don't think
it's a serious problem.

There is still much work to be done on this branch; more top level
tests for sutures, implementing split to allow undoing sutures. It
is making progress.

On the other hand, I'd like to get a better conflict resolution
process into the main branch soon, so I can start teaching it to my
team at work. So I'll create another branch n.v.m.resolve_conflicts,
to implement the non-suture conflict resolutions that are currently in
n.v.m.automate_show_conflict.

--
-- Stephe