Issue 209: support drop/modified conflict - A distributed version control system

Reported by Stephen Leake, May 14, 2012

Steps to reproduce the problem:
-------------------------------

1. create two heads, one with file_a modified, one with file_a 
dropped
2. merge

Expected result:
----------------
merge reports a drop/modified conflict

Actual results:
---------------
warning about modifications being lost due to drop

Output of `mtn version --full`:
-------------------------------
1.0

Comment 1 by Stephen Leake, Jun 3, 2012

fixed in branch nvm.issue-209; dropped/modified conflicts are fully 
supported.

Status: Started

Comment 2 by Stephen Leake, Jun 19, 2012

Changing dropped/modified from warning to conflict complicates an 
important use case; upstream modified, local dropped. For example, 
upstream uses a particular build file that local does not need, so 
local wants to drop it and ignore all future changes.

One way to support that use case, and similar ones, is to provide a 
'mtn:resolve_conflict' attribute, to specify the 'drop' resolution 
for this case. Work on this is being done in branch 
nvm.issue-209.file_attribute.

That attribute requires an extra branch in some cases; for example, 
where upstream is in mtn, but does not want to add the attributes, 
the local maintainer needs another branch that is a copy of upstream 
but adds the attributes. To resolve that issue, we could try to 
store attributes for deleted nodes in a new revision level 
structure. However, it is difficult to uniquely identify the file 
involved in a way that can be synced, in the face of renames 
upstream.

Comment 3 by Stephen Leake, Jun 21, 2012

mtn:resolve_conflicts is finished in branch 
nvm.issue-209.file_attribute, rev 
fc8be5f8894e0e0160f475b0cf463180649926db.

Comment 4 by Richard Hopkins, Jul 6, 2012

Branch net.venge.monotone now fails on these func tests:

* resolve_conflicts_dropped_modified_2
* resolve_conflicts_dropped_modified_upstream_vs_local

This is on SLED 11 SP2, does it fail for anyone else?

Comment 5 by Stephen Leake, Jul 7, 2012

works for me on:
Windows XP SP3 MingW & Cygwin
Windows 7 MingW & Cygwin (32 bit)
Debian testing

what is the failure?

Comment 6 by Richard Hopkins, Jul 8, 2012

I've just had a further look into it, and the issue seems to be an 
ambiguity issue in the Lua syntax. I've now pushed a fix for it on 
my system.

Can you please try (0e31f30e483148a81491feadd8ad37f831559a67) in the 
net.venge.monotone branch to see if it still passes for you? It 
should do I think.

Comment 7 by Stephen Leake, Jul 8, 2012

yes, that works. The ambiguity must be fixed in Lua 5.2.

Status: Fixed