Re: Updated Issue 209 - support drop/modified conflict

Stephen Leake <[email protected]> writes:

> I've pushed rev 6c4dfef59abaf41783e202dc79fada774d2332a6 on
> nvm.issue-209; it has two new tests:
>
> resolve_conflicts_dropped_modified_2 showing this use case:
> --     A
> --    / \
> --   M1  D
> --   | \ |
> --   M2  P
> --    \ /
> --     Q
> --
> -- The file is modified and merged into the dropped branch twice.
>
>
> and resolve_conflicts_dropped_modified_upstream_vs_local showing that
> use case.
>
> All tests pass on mingw, except one that also fails in nvm.
>
> I think the dropped_modified code is complete, except for addressing the
> repeated conflicts in the upstream_vs_local case. 

I've pushed branch nvm.issue-209.file_attribute, implementing the
attribute mtn:resolve_conflict to address the upstream_vs_local case.

Getting the conflict resolution from the attribute turned out to be
quite simple, but there are two remaining user interface issues.

First is how to show the attr-specified resolution in the conflict
display from 'show conflicts' (see the FIXME in
resolve_conflicts_dropped_modified_upstream_vs_local).

Second is whether to require --resolve_conflicts on all merge commands
in order to use the attribute. Requiring --resolve_conflicts keeps all
the current conflict messages from the merge commands when no resolution
is given.

That's not as transparent as I'd like, but deleting the requirement
for --resolve_conflicts requires more significant changes to the
conflict resolution code, to get the current messages when no resolution
is supplied (see the failing test update_with_pending_modification). So
I wanted some feedback before I start that work.

-- 
-- Stephe