Re: Updated Issue 209 - support drop/modified conflict

Stephen Leake <[email protected]> writes:

> [email protected] writes:
>
>> I'm worried that the cure will be worse than the disease. Also in
>> terms of backwards compatibility will we need to migrate existing
>> databases and change existing merges. Is it compatible to go in our
>> 1.x line as it changes/replaces die-die-die or should it go in a 2.x
>> line ?
>
> Promoting dropped/modified from warning to conflict does not change
> or replace die-die-die; it just makes explicit the workaround
> for the case where the delete was a mistake, and forces explicit
> confirmation for the case where the modify should be ignored.
>
> Unfortunately, the confirmation is required every time the conflict
> happens, which can be often in the upstream vs local branch case.
>
> There are several proposed solutions to the latter problem (roughly in
> order of implementation risk):
>
> 1) add a --no-dropped-modified-conflict option, that restores the mtn 1.0
>    behavior
>
> 2) In a third 'annotated' branch, add attributes, on the files that will
>    be deleted, that give the conflict resolution for those files. 
>
> 3) Add a new rev data structure, storing the deleted node ids and
>    associated conflict resolutions.
>
> 4) Keep node ids for deleted files, so the attributes can be stored with
>    them in the local branch.
>
> Solutions 1) and 2) do not change the manifest format, so they are backward
> compatible with 1.0 (no flag day).
>
> Solutions 3) and 4) do change the manifest format, but only for revs
> that have such annotations; it also does not require a flag day, and is
> appropriate for 1.0. This requires a mechanism for deciding what
> manifest format a given rev needs; that should not be hard.

Solution 4 does change die-die-die.

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. 

-- 
-- Stephe