[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (mon
From: |
code |
Subject: |
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone) |
Date: |
Sun, 08 Jul 2012 09:32:11 +0200 |
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/