Updated Issue 209 - support drop/modified conflict (monotone)

Hello,

The following issue has been updated:

209 - support drop/modified conflict
Project: monotone
Status: Fixed
Reported by: Stephen Leake
URL: https://code.monotone.ca/p/monotone/issues/209/
Labels:
 Type:Incorrect Behavior
 Priority:Medium

Comments (last first):

# By Stephen Leake, Jul  8, 2012:

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

 Status: Fixed

# 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.

# 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?

# 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?

# By Stephen Leake, Jun 21, 2012:

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

# 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.

# By Stephen Leake, Jun  3, 2012:

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

 Status: Started

# 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



--
Issue: https://code.monotone.ca/p/monotone/issues/209/