Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)

[Stephen Leake]

Stephen Leake <address@hidden> writes:

> address@hidden writes:
>
>> fixed in branch nvm.issue-209; dropped/modified conflicts are fully
>> supported.
>
> I think this needs some review before I merge it to main.
>
> In particular, the resolution process allows keeping the modified file.
> This is implemented as a drop and add, which is what the user would do.
> But it is done during a merge, so merge can now create new nodes.
>
> I don't think there is anything wrong with that, but I'd like
> confirmation.
>
>
> All the conflict related tests pass; I'm running all other tests now on
> MinGW.

These tests are failing:

  2 (imp)_merge((patch_foo_a),_(delete_foo_))    FAIL (line 18)

    now shows both orphaned file and dropped/modified conflicts
    merged with resolve_conflicts_dropped_modified

344 merge((drop_a),_(rename_a_b,_patch_b))       FAIL (line 22)

    drop/modified, renamed
    merged with resolve_conflicts_dropped_modified

345 merge((patch_a),_(drop_a))                   FAIL (line 21)

    drop/modified
    merged with resolve_conflicts_dropped_modified

346 merge((patch_a),_(drop_a,_add_a))            FAIL (line 29)

    drop, add/modified
    merged with resolve_conflicts_dropped_modified

399 netsync_key_hooks                            FAIL (line 70)
    not related; fails same way in main

586 update_with_pending_modification             unexpected success
    update has dropped/modified; now reports conflict
    improve test

Fixing test 2 requires a code change; the current code reports both an
orphaned node and a dropped/modified conflict, which don't have the
right resolutions. So I'll add an 'orphaned' flag to the modified
conflict, and require rename in addition to keep or user resolution in
that case.

Tests 344 and 345 are already covered in
tests/resolve_conflict_dropped_modified, so I'll just delete those. 

Test 346 is a special case, and also requires a code change. The file
was dropped and then re-added on one side, modified on the other. So 
the resolution can't be 'keep'; it has to be 'user' with merged content,
and the content is stored in the already-added node.

I'm working on fixing these cases.

-- 
-- Stephe