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

[Stephen Leake]

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 1 suffers from not being stored in the database; people will
have to specify that option in ~/.monotone/monotonerc, or
<workspace>/_MTN/monotonerc

I prefer solution 2), because it is easier to implement than 3 or 4.
Note that 2) and 4) can be extended to store attributes for other files
that have on-going conflicts; "this file is present in upstream in
local, but we are ignoring upstream changes".

This extension also could be used with 3), but that would mean we have
two new mechanisms for specifing on-going conflict resolutions; more
work.

I'm not clear what impact 4) has on the rest of the merge code; it
sounds problematic.


Actually, even if we are heading for solution 3 or 4, I think we
should implement 2) first. The only difference is where the info is
stored; providing and using the info is the same, so we can work out
those issues.


-- 
-- Stephe