[Top][All Lists]
[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: |
Sat, 09 Jun 2012 13:41:15 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Stephen Leake <address@hidden> writes:
> address@hidden 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
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, (continued)
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Ethan Blanton, 2012/06/12
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/13
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Ethan Blanton, 2012/06/13
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/14
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Hendrik Boom, 2012/06/14
- Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, Stephen Leake, 2012/06/15
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict, richhguard-monotone, 2012/06/08