monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stephen Leake
Subject: Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict
Date: Tue, 19 Jun 2012 07:53:51 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt)

Stephen Leake <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]