[Monotone-devel] 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started 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 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started Reported by: Stephen Leake URL: https://code.monotone.ca/p/monotone/issues/209/ Labels: Type:Incorrect Behavior Priority:Medium Comments (last first): # 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started Reported by: Stephen Leake URL: https://code.monotone.ca/p/monotone/issues/209/ Labels: Type:Incorrect Behavior Priority:Medium Comments (last first): # 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes:
On 06/19/2012 01:56 PM, Stephen Leake wrote:
Ok, that makes sense. I did wonder whether to include something like
history will be lost; see user guide in the conflict resolution
message.
That already covers the major point, I think. Maybe a bit more specific
(monotone certainly shouldn't ever lose the entire history):
History for file ${FOO} will be lost; see the users manual, section ${BAR}
(Nit-pick: it's usually called a manual, not a guide, is it?)
Ok. Currently nvm.issue-209 has:
check(mtn(explicit_merge, --resolve-conflicts, left_1, right_1,
testbranch), 0, nil, true)
check(samelines
(stderr,
{mtn: [left] 506d8ed51b06c0080e8bb307155a88637045b532,
mtn: [right] a2889488ed1801a904d0219ec9939dfc2e9be033,
mtn: keeping 'file_2',
mtn: [merged] 3df3126220588440def7b08f488ca35eaa94f1b6}))
I'll change that to:
check(mtn(explicit_merge, --resolve-conflicts, left_1, right_1,
testbranch), 0, nil, true)
check(samelines
(stderr,
{mtn: [left] 506d8ed51b06c0080e8bb307155a88637045b532,
mtn: [right] a2889488ed1801a904d0219ec9939dfc2e9be033,
mtn: keeping 'file_2',
mtn: history for 'file_2' will be lost; see user manual Merge Conflicts
section,
mtn: [merged] 3df3126220588440def7b08f488ca35eaa94f1b6}))
--
-- Stephe
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started 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, 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
On 06/19/2012 01:56 PM, Stephen Leake wrote:
Ok, that makes sense. I did wonder whether to include something like
history will be lost; see user guide in the conflict resolution
message.
That already covers the major point, I think. Maybe a bit more specific
(monotone certainly shouldn't ever lose the entire history):
History for file ${FOO} will be lost; see the users manual, section ${BAR}
(Nit-pick: it's usually called a manual, not a guide, is it?)
Regards
Markus Wanner
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started 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, 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
On 06/19/2012 08:47 AM, c...@monotone.ca wrote: Comments (last first): # By Stephen Leake, Jun 19, 2012: 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. Cool, thanks. Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: Stephen, On 06/13/2012 03:20 PM, Stephen Leake wrote: The user deleted a file by mistake. mtn has no clean mechanism for undoing that, but it does have a reasonable workaround. I think you are saying that using that workaround 'obscures die-die-die behavior'. Ok, that's true. Why is that a problem? It is consistent with mtn in general, and it is what the user wants. More importantly, it is not new; it has been in mtn all along. The 'keep' resolution in nvm.issue-209 is just the workaround formalized and made easy. That's exactly what I'm opposing to: it's still a work-around. It has its gotchas. And while it's certainly true that it's been with mtn so far, I don't consider that an argument for making the work-around less visible to the user; working behind the scenes - only to trap him later on. That being said, a warning in case the user chooses the keep-work-around might already suffice to mitigate my point. That should at least help making the user aware that the keep resolution isn't really a (re)solution, but just what it has always been: a work-around, now made easier to apply. Ok, that makes sense. I did wonder whether to include something like history will be lost; see user guide in the conflict resolution message. Can you suggest an appropriate warning? -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: Hi, On 06/09/2012 03:19 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Sorry, that was too brief. I'll give an example: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). Another good test case. But I think my current solution addresses it; the conflict data in _MTN/conflicts has the file_id of the file in M2 and M3, so the user (or a front-end) can retrieve them, diff them, and use the 'user' resolution to provide the content for Q. Conflict data in _MTN/conflicts? Hm.. I didn't ever see or use that. That's what 'mtn conflict' uses by default. How do you resolve conflicts? So, you are effectively saying, monotone doesn't need to properly keep track, but the user can resolve it. Sorry, I just don't consider that to be a solution. We've agreed that suture is the ideal solution in this case. But no one is volunteering to implement suture (I'm the only one that has actually tried). So we are looking for a compromise. I'm saying monotone reports a conflict, and provides all the information the user needs to properly resolve it. That is an improvement on what it does in mtn 1.0, which is to report the problem in a warning, but provide no help in resolving it in the case where the delete was a mistake. See below for more on this. A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | R |-- R additionally renames the file on the left \ / Q -- Q merges. How? In this case, the current conflict code will identify M3 as the node to merge with R, which is the right thing to do. The reverse case is different: Huh? How can it do that? The two files have different node ids, different names (and different modifications applied to them). You may be right; implement the test case in nvm.issue-209 and see what happens. Oh, you mean M2 conflicts *again* with the delete? But a user already decided he wants to keep the file (and apply M1). That should merge cleanly with yet another modification. As we have been saying, the user currently has no way to tell mtn that decision should be remembered, and applied the next time the same conflict occurs. In the other thread, we are discussion a mechanism to solve exactly that issue. and the user is not presented with all the information they need (they should merge M2 with R). This is bad, and sutures is the right fix. It's not just that the user is not presented with *all* the information. He gets misleading information - instead of the clear warning that monotone-1.0 provides. See below for mtn 1.0 and nvm.issue-209 test cases that address exactly this issue; please explain in detail why nvm.issue-209 is 'misleading'. But none of this is new; all of these cases exist in mtn 1.0, with all of the same solutions, workarounds, and problems. I'm just making a couple of the more common cases easier to deal with. And, unfortunately, your favorite use case harder to deal with. So we need to address that. I disagree here. It's not just my favorite use case that gets harder. It's the die-die-die behavior (and thus the keep resolution to the drop/modified conflict) that gets obscured. I'm not in favor of such a thing. I don't understand what you mean by 'die-die-die behavior gets obscured'. The user deleted a file by mistake. mtn has no clean mechanism for undoing that, but it does have a reasonable workaround. I think you are saying that using that workaround 'obscures die-die-die behavior'. Ok, that's true. Why is that a problem? It is consistent with mtn in general, and it is what the user wants. More importantly, it is not new; it has been in mtn all along. The 'keep' resolution in nvm.issue-209 is just the workaround formalized and made easy. Attached is a mtn 1.0 test script that shows this use case: -- A --/ \ -- M1 D -- | \ | -- M2 P --\ / -- Q Compare this to nvm.issue-209/test/func/resolve_conflicts_dropped_modified_2/__driver__.lua The semantics are the same; only the user interface is different. You've agreed this is a valid use case; what
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hendrik, On 06/11/2012 10:01 PM, Hendrik Boom wrote: On Fri, Jun 08, 2012 at 02:53:30PM +0200, Markus Wanner wrote: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). What I've not managed to understand through this whole discussion is why at P the file has to be given a new node id. Resurrecting a file under the same node id pretty much leads to the idea of tracking liveliness per file. It gets a tad harder than just reusing the same node id because conflicts in the liveliness property of a node id can arise. Consider the following case: A -- has 'foo' | B -- drops 'foo' / \ C D -- both resurrect 'foo' | | | E -- drop 'foo', again \ / F -- is 'foo' dead or alive? For the merge in F, neither the ancestor B nor the right side E have the file 'foo'. However, it is in C. So under current (monotone-1.0) merge logic, monotone would think C added the file and keep it in F. However, I'd expect this to conflict, because the right side clearly wanted the file dead, while the left side wants it alive. Note that I'm personally not in favor of this approach, but rather prefer implementing file resurrection via (asymmetric) copies accompanied by sutures (which might well be harder to implement, yes). Issues I know of with the liveliness tracking approach are: amount of node ids grows infinitely (and any kind of of deferred cleanup re-introduces the die-die-die issues). And second, I'm not sure how content conflicts for dropped files can be handled. After all, the file's contents must still be tracked in case the file goes live, again. However, the user certainly doesn't want to merge a dead file's contents. (OTOH content conflicts on dead files can only ever arise if you propagate from two different branches, because you obviously cannot modify a dead file directly). Why can't it have the one it had at M1? That's what it would have happened if it had been added at M1 instead of being deleted at D. Right, but if it had been added only at M1, the ancestor A (in the top example) would not have the node id, either. That's how monotone differentiates between added and dropped files. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hi, On 06/09/2012 03:19 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: Sorry, that was too brief. I'll give an example: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). Another good test case. But I think my current solution addresses it; the conflict data in _MTN/conflicts has the file_id of the file in M2 and M3, so the user (or a front-end) can retrieve them, diff them, and use the 'user' resolution to provide the content for Q. Conflict data in _MTN/conflicts? Hm.. I didn't ever see or use that. So, you are effectively saying, monotone doesn't need to properly keep track, but the user can resolve it. Sorry, I just don't consider that to be a solution. Let's adding a simple rename: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | R |-- R additionally renames the file on the left \ / Q -- Q merges. How? In this case, the current conflict code will identify M3 as the node to merge with R, which is the right thing to do. The reverse case is different: Huh? How can it do that? The two files have different node ids, different names (and different modifications applied to them). Say A has the original file foo, node id 2. Merge P keeps that file foo, by adding it under node id 3. Following a modification on each side. After the rename in R, node id 2 is now known under the file name bar. So the merger that needs to create Q sees a file bar with node id 2 on the left and a file foo with id 3 on the right. How do these conflict? (And what current conflict code are you referring to? The issue-209 branch?) A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | | R-- R additionally renames the file on the right \ / Q -- Q merges. How? Now there's no way to associate R with M2 Yeah, the two files in R and M2 have no association. Neither file names nor the node ids match. If you ask me, that's pretty much the same case as in the example above. so the drop/modified conflict is repeated, What drop conflicts with what modification? P resolved the one conflict that I see. After that, monotone considers the file that P (re)created to be a different one than what D deleted. Oh, you mean M2 conflicts *again* with the delete? But a user already decided he wants to keep the file (and apply M1). That should merge cleanly with yet another modification. and the user is not presented with all the information they need (they should merge M2 with R). This is bad, and sutures is the right fix. It's not just that the user is not presented with *all* the information. He gets misleading information - instead of the clear warning that monotone-1.0 provides. But none of this is new; all of these cases exist in mtn 1.0, with all of the same solutions, workarounds, and problems. I'm just making a couple of the more common cases easier to deal with. And, unfortunately, your favorite use case harder to deal with. So we need to address that. I disagree here. It's not just my favorite use case that gets harder. It's the die-die-die behavior (and thus the keep resolution to the drop/modified conflict) that gets obscured. I'm not in favor of such a thing. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
On Fri, Jun 08, 2012 at 02:53:30PM +0200, Markus Wanner wrote: Sorry, that was too brief. I'll give an example: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). What I've not managed to understand through this whole discussion is why at P the file has to be given a new node id. Why can't it have the one it had at M1? That's what it would have happened if it had been added at M1 instead of being deleted at D. -- hendrik ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: No, the user asked for the deletion once, and for the modification once, in parallel. (In reality, that could be done by two different users on a team.) That's a conflict. I can understand this viewpoint, now. Ok, good. Sure. The same can be said for intentional deletes: Sometimes the drop is intended, and it needs to persist; the easiest way to achieve that is die-die-die merge. Neither of these two options is a reason to always prefer one over the other. Exactly; that's why it needs to be a conflict, so the user makes a concious choice to affirm either the drop or the modify. Agreed. But if he needs to do so, he shouldn't have to repeat his decision over and over, again. That's what I'm opposing to. Yes, that makes sense. Which is why I proposed a couple of ways to do that; add an attribute or a workspace option. I don't think you responded to that proposal. Ever thought of what happens with modifications on both node-ids after a 'keep' resolution, but before merging? I don't understand what you mean by 'after a resolution but before merge'; the conflict resolution happens during a merge; there is no opportunity for the user to modify nodes (other than providing the file content for the conflicted file). Sorry, that was too brief. I'll give an example: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). Another good test case. But I think my current solution addresses it; the conflict data in _MTN/conflicts has the file_id of the file in M2 and M3, so the user (or a front-end) can retrieve them, diff them, and use the 'user' resolution to provide the content for Q. Doesn't this problem equal to suturing? That would be a better solution. Let's adding a simple rename: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | R |-- R additionally renames the file on the left \ / Q -- Q merges. How? In this case, the current conflict code will identify M3 as the node to merge with R, which is the right thing to do. The reverse case is different: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | | R-- R additionally renames the file on the right \ / Q -- Q merges. How? Now there's no way to associate R with M2, so the drop/modified conflict is repeated, and the user is not presented with all the information they need (they should merge M2 with R). This is bad, and sutures is the right fix. But none of this is new; all of these cases exist in mtn 1.0, with all of the same solutions, workarounds, and problems. I'm just making a couple of the more common cases easier to deal with. And, unfortunately, your favorite use case harder to deal with. So we need to address that. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Stephen Leake stephen_le...@stephe-leake.org writes: Agreed. But if he needs to do so, he shouldn't have to repeat his decision over and over, again. That's what I'm opposing to. Yes, that makes sense. Which is why I proposed a couple of ways to do that; add an attribute or a workspace option. I don't think you responded to that proposal. Now that I've read that email more carefully, I see you did respond. Sorry. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hi, just briefly here, please see my other recent mail as well. On 06/07/2012 11:22 PM, Stephen Leake wrote: Markus Wanner mar...@bluegap.ch writes: AFAIU your proposed approach makes the 'drop' choice non-permanent. In that aspect, the user cannot choose the current behavior anymore, no. I don't see how I'm changing anything. The drop is only non-permanent if the user decides it was a mistake. In mtn 1.0, you can re-add the file; the consequences of that are exactly the same as choosing a non-drop resolution of the drop/modified conflict; that is my definition of the resolution. The change is that the user would have to confirm that the deletion was not just a mistake for every conflicting modification propagated. Where as at the moment, she only gets a warning every time. The point is that with the conflict process, the user is presented with an explicit choice. With mtn 1.0, the warning message is all you get; Exactly. (You effectively don't even want that, but you certainly don't want a full-blown conflict each time). No, the user asked for the deletion once, and for the modification once, in parallel. (In reality, that could be done by two different users on a team.) That's a conflict. I can understand this viewpoint, now. Sure. The same can be said for intentional deletes: Sometimes the drop is intended, and it needs to persist; the easiest way to achieve that is die-die-die merge. Neither of these two options is a reason to always prefer one over the other. Exactly; that's why it needs to be a conflict, so the user makes a concious choice to affirm either the drop or the modify. Agreed. But if he needs to do so, he shouldn't have to repeat his decision over and over, again. That's what I'm opposing to. (Aside from implementation issues with your approach). The current approach (die-die-die together with the warning) being easier to handle (and work around, if necessary) *is* a reason for that option, though. It is certainly easier to handle if you want to confirm the drop; just ignore the message. I don't see how it is easier to 'work around', which means confirm the modify. I'll have to write this up explicitly. The conflict process makes both choices equally easy. No. Die-die-die currently favors a delete decision. Your approach would favor the keep decision. In somewhat different ways, though. Ever thought of what happens with modifications on both node-ids after a 'keep' resolution, but before merging? I don't understand what you mean by 'after a resolution but before merge'; the conflict resolution happens during a merge; there is no opportunity for the user to modify nodes (other than providing the file content for the conflicted file). Sorry, that was too brief. I'll give an example: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). \ / Q -- Q merges. How? The issue you are facing in Q is that monotone thinks the two node ids are distinct files. Even if you manage to teach it to suture because the two files conflict by their path, figuring out what ancestor to use is non-trivial. And certainly involves remembering the relation of the file added in P to the one deleted in D (or modified in M1, same thing, same node id). Doesn't this problem equal to suturing? Let's adding a simple rename: A / \ M1 D | \ | | P-- P is the keep resolution, effectively resurrecting | |-- the file and giving it a new node id. | | M2 |-- M2 and M3 are both modifications on the same file (but | M3 -- now known under different node ids). | | R |-- R additionally renames the file on the left \ / Q -- Q merges. How? By relying on name conflicts, you are implicitly saying this merge in Q would be a clean merge. Effectively leading to a duplication of that very file, just because somebody erroneously deleted it before. That certainly doesn't match my (user?) expectation. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: On 06/06/2012 02:33 AM, Stephen Leake wrote: Yes, but it's the same node that the drop-modify 'keep' resolution would add. Yeah, I'm assuming Q to be the result of the drop-modify 'keep' resolution as well. In the P/Q merge, the same conflict occurs; the original foo node in Q is dropped. But the resolution would attempt to create the new foo node in Q, so instead it reuses it. Ah, right, each modification conflicts with the delete over and over again. I didn't think of that part. So the file isn't even properly resurrected, but every modification on the parent branch leads to a new drop/modify conflict, for which the user needs to re-iterate his decision. Awkward. Yes, suture would be better (which is something we agree on :). Since the current behavior is not what I want, I think it should be a conflict, so the user can choose the current behavior (the 'drop' resolution to the conflict), or something else (the 'keep' or 'user' resolution to the conflict). AFAIU your proposed approach makes the 'drop' choice non-permanent. In that aspect, the user cannot choose the current behavior anymore, no. I don't see how I'm changing anything. The drop is only non-permanent if the user decides it was a mistake. In mtn 1.0, you can re-add the file; the consequences of that are exactly the same as choosing a non-drop resolution of the drop/modified conflict; that is my definition of the resolution. The point is that with the conflict process, the user is presented with an explicit choice. With mtn 1.0, the warning message is all you get; going back and adding the file with the proper contents is more awkward than with the conflict. Working around the drop/modify conflict by manually re-adding the file is a once-per-erroneous delete operation. How can the user work around the cannot-drop-persistently issue that your approach would introduce? I'll have to write up the same scenario in mtn 1.0 and with the drop/modified conflict to illustrate this. Admittedly, with the current approach, you'll also see the drop/modified warning once-per-modification on an intentionally deleted file. But it's just a warning, no user action is required, the file remains deleted, as the user asked for. No, the user asked for the deletion once, and for the modification once, in parallel. (In reality, that could be done by two different users on a team.) That's a conflict. Overall, this doesn't look like a win to me. We need some input from others. We could consider a user option --no-dropped-modified to retain the mtn 1.0 behavior. Then we get to argue over the default value for that :). The reason I don't like the current behavior is that sometimes the drop was a mistake, and it needs to be corrected; the easiest way to bring that to the user's attention is via a merge conflict. Sure. The same can be said for intentional deletes: Sometimes the drop is intended, and it needs to persist; the easiest way to achieve that is die-die-die merge. Neither of these two options is a reason to always prefer one over the other. Exactly; that's why it needs to be a conflict, so the user makes a concious choice to affirm either the drop or the modify. The current approach (die-die-die together with the warning) being easier to handle (and work around, if necessary) *is* a reason for that option, though. It is certainly easier to handle if you want to confirm the drop; just ignore the message. I don't see how it is easier to 'work around', which means confirm the modify. I'll have to write this up explicitly. The conflict process makes both choices equally easy. Yes, by the file name, which is why it looks like a duplicate name conflict. It will be a problem if the file is renamed between P and the merge. Yeah, the 'keep' resolution might not be able to *add* the file again under the same name, because such a file already exists. It's not a duplicate name conflict because of the merge, but one that arises by resolving the drop/modify conflict that way. I've just started working on this case. I think I need to add the new node with the same name to the conflict itself, so the user can diff all three files (the dropped file, the modified file, and the new file) while resolving the conflict. So it really does look like a 'dropped/modified, duplicate name' conflict. It might be useful to give it yet another name; I'll see how the code works out. Ever thought of what happens with modifications on both node-ids after a 'keep' resolution, but before merging? I don't understand what you mean by 'after a resolution but before merge'; the conflict resolution happens during a merge; there is no opportunity for the user to modify nodes (other than providing the file content for the conflicted file). -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hi, On 06/06/2012 02:33 AM, Stephen Leake wrote: Yes, but it's the same node that the drop-modify 'keep' resolution would add. Yeah, I'm assuming Q to be the result of the drop-modify 'keep' resolution as well. In the P/Q merge, the same conflict occurs; the original foo node in Q is dropped. But the resolution would attempt to create the new foo node in Q, so instead it reuses it. Ah, right, each modification conflicts with the delete over and over again. I didn't think of that part. So the file isn't even properly resurrected, but every modification on the parent branch leads to a new drop/modify conflict, for which the user needs to re-iterate his decision. Awkward. Since the current behavior is not what I want, I think it should be a conflict, so the user can choose the current behavior (the 'drop' resolution to the conflict), or something else (the 'keep' or 'user' resolution to the conflict). AFAIU your proposed approach makes the 'drop' choice non-permanent. In that aspect, the user cannot choose the current behavior anymore, no. Working around the drop/modify conflict by manually re-adding the file is a once-per-erroneous delete operation. How can the user work around the cannot-drop-persistently issue that your approach would introduce? Admittedly, with the current approach, you'll also see the drop/modified warning once-per-modification on an intentionally deleted file. But it's just a warning, no user action is required, the file remains deleted, as the user asked for. Overall, this doesn't look like a win to me. The reason I don't like the current behavior is that sometimes the drop was a mistake, and it needs to be corrected; the easiest way to bring that to the user's attention is via a merge conflict. Sure. The same can be said for intentional deletes: Sometimes the drop is intended, and it needs to persist; the easiest way to achieve that is die-die-die merge. Neither of these two options is a reason to always prefer one over the other. The current approach (die-die-die together with the warning) being easier to handle (and work around, if necessary) *is* a reason for that option, though. Yes, by the file name, which is why it looks like a duplicate name conflict. It will be a problem if the file is renamed between P and the merge. Yeah, the 'keep' resolution might not be able to *add* the file again under the same name, because such a file already exists. It's not a duplicate name conflict because of the merge, but one that arises by resolving the drop/modify conflict that way. Ever thought of what happens with modifications on both node-ids after a 'keep' resolution, but before merging? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hi, On 06/05/2012 02:02 AM, Stephen Leake wrote: I moved the discussion of the 'dropped/modified' conflict to right after the missing root conflict (which is where 'die-die-die' is introduced in the manual), and it now mentions 'die-die-die'. Sounds good, thanks. As such, it doesn't help in the rare case of a missing root conflict, for example. More importantly, it's troublesome in cases involving multiple edits conflicting with one delete. With parallel modifications: A- file 'foo' exists / | \ M1 M2 D - M1, M2: independent modifications to 'foo' \ /\ / - D: deletion of 'foo' P Q - P, Q: merges, adding 'foo' under a new node-id P is just a normal merge, while Q re-adds foo. Now it is a duplicate name conflict, with the resolution of keep one (with merged contents), delete the other. Uh.. wait. I didn't proceed with merging P and Q. Those are separate revisions which aren't necessarily merged directly. Consider a rename or other modifications to the files involved before merging... The point is that we now have two node-ids on the horizon, for something the users considers to be the same file, but without mtn knowing. That's a problem per se, IMO. The immediate merge with the user explicitly dropping one file is what he then can do to work around the short-comings of this approach, yes. In that case, you've brought two conflicts to the users attention, instead of none, as monotone currently would. Anything involving renames after P or Q before merging won't even show the inconsistency to the user. In case of M1 and M2 being sequential edits, the user would have to undelete the same file several times, consider this: A / \ M1 D | \ | M2 P \ / Q If the user chooses to keep the file in both, P and Q, he'd end up with two 'foo' files. merge to P is the only undelete; merge to Q has a duplicate name conflict. Yeah, same issue: modify/delete conflict resolved by keeping (AKA asymmetrically copying) the file turns into a name conflict. Right; I started trying to do that in the 'file sutures stuff'. Way too hard, for very little gain :). Well, here we obviously disagree. But I haven't tried implementing sutures (or resurrection). Where do I find your work on sutures? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Stephen, On 06/05/2012 03:47 PM, Stephen Leake wrote: Actually, it's not a duplicate name conflict, it's a special case of drop/modified; the same as the existing test that's currently failing in nvm.issue-209: Sure? In that case, I don't understand your approach. A drop/modified conflict between two different node-ids should be impossible. And I'd expect Q to introduce a new node id, given your description. Right. It's similar to another use case I have, with a vendor branch and a local branch. If the user adds a feature (in a new file) on the local branch, which the vendor then adopts, that's a duplicate name conflict. But resolving it once the wrong way leads to confusion: V L | | V1 L1 new local feature, vendor bug fixes | \ | | L2 V2 | vendor adopts local feature | \ | | L3 duplicate name conflict; local drops vendor file (oops) V3 | vendor bug fixes | \ | | L4 duplicate name conflict again; this time, drop local file V4 | \ | L5 no conflicts I was thinking this would lead to a dropped/modified conflict, but I guess it won't. But the confusion about nodes and names is similar. I don't see the similarity, because it's not about a drop/modify conflict. Moreover, in L4, you currently won't get no conflict, and correctly so. The user has expressed that he wanted to delete the vendor's variant of the file and instead use its own. That may well be exactly what she wanted in the first place. The immediate merge with the user explicitly dropping one file is what he then can do to work around the short-comings of this approach, yes. In that case, you've brought two conflicts to the users attention, instead of none, as monotone currently would. I'm inferring that you agree that's a good thing. I fear I'm not, sorry. I think it's obfuscating things, instead of a clearer failure mode (die-die-die, which is equally wrong, but at least simple and clear). That's true. I agree that general support for suture would help here; I just think it's not worth the effort of doing that, since this should not happen in a well-managed project, or at least be very rare. IMO die-die-die works better for well-managed projects. The policy is simple: never delete something you might want to revert someday. In case of M1 and M2 being sequential edits, the user would have to undelete the same file several times, consider this: A / \ M1 D | \ | M2 P \ / Q If the user chooses to keep the file in both, P and Q, he'd end up with two 'foo' files. merge to P is the only undelete; merge to Q has a duplicate name conflict. Yeah, same issue: modify/delete conflict resolved by keeping (AKA asymmetrically copying) the file turns into a name conflict. As above, this is not a duplicate name conflict, but a special case of drop/modififed. I will implement this test case to make sure I'm not still missing something. AFAIUI turning this into a drop/modified conflict would require the newly introduced node-id in P to somehow be related to the old node-id of the file in A (and later M1, M2). Arguably, from a users perspective, it shouldn't be a drop/modify conflict, either. She already expressed her wish to keep the file in P. Why should she do that again for Q? I wrote those two files to get clear what was needed to implement split and suture; I think they should be the starting point of any new effort. Although trying to read it again now is giving me a headache; it could be improved :). As usual with such things, it makes more sense when you are actively working on it. Thanks for these pointers, I'll take a look. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: Stephen, On 06/05/2012 03:47 PM, Stephen Leake wrote: A- file 'foo' exists / | \ M1 M2 D - M1, M2: independent modifications to 'foo' \ /\ / - D: deletion of 'foo' P Q - P, Q: merges, adding 'foo' under a new node-id Actually, it's not a duplicate name conflict, it's a special case of drop/modified; the same as the existing test that's currently failing in nvm.issue-209: Sure? In that case, I don't understand your approach. A drop/modified conflict between two different node-ids should be impossible. And I'd expect Q to introduce a new node id, given your description. Yes, but it's the same node that the drop-modify 'keep' resolution would add. In the M2/D merge, the conflict is between the modified foo node in M2 and the dropped foo node in D; the resolution created Q. In the P/Q merge, the same conflict occurs; the original foo node in Q is dropped. But the resolution would attempt to create the new foo node in Q, so instead it reuses it. Right. It's similar to another use case I have, with a vendor branch and a local branch. If the user adds a feature (in a new file) on the local branch, which the vendor then adopts, that's a duplicate name conflict. But resolving it once the wrong way leads to confusion: V L | | V1 L1 new local feature, vendor bug fixes | \ | | L2 V2 | vendor adopts local feature | \ | | L3 duplicate name conflict; local drops vendor file (oops) V3 | vendor bug fixes | \ | | L4 duplicate name conflict again; this time, drop local file V4 | \ | L5 no conflicts I was thinking this would lead to a dropped/modified conflict, but I guess it won't. But the confusion about nodes and names is similar. I don't see the similarity, because it's not about a drop/modify conflict. Moreover, in L4, you currently won't get no conflict, and correctly so. The user has expressed that he wanted to delete the vendor's variant of the file and instead use its own. That may well be exactly what she wanted in the first place. I'll write up this test case as well; I now think it will be the same as the above. This stuff is tricky! The immediate merge with the user explicitly dropping one file is what he then can do to work around the short-comings of this approach, yes. In that case, you've brought two conflicts to the users attention, instead of none, as monotone currently would. I'm inferring that you agree that's a good thing. I fear I'm not, sorry. I think it's obfuscating things, instead of a clearer failure mode (die-die-die, which is equally wrong, but at least simple and clear). Since the current behavior is not what I want, I think it should be a conflict, so the user can choose the current behavior (the 'drop' resolution to the conflict), or something else (the 'keep' or 'user' resolution to the conflict). The reason I don't like the current behavior is that sometimes the drop was a mistake, and it needs to be corrected; the easiest way to bring that to the user's attention is via a merge conflict. I'm assuming I'm not the only user with this issue. That's true. I agree that general support for suture would help here; I just think it's not worth the effort of doing that, since this should not happen in a well-managed project, or at least be very rare. IMO die-die-die works better for well-managed projects. The policy is simple: never delete something you might want to revert someday. Well, yes. But I'd call that perfectly managed :). And it requires perfect foresight. People are not perfect, so we need some recovery. In case of M1 and M2 being sequential edits, the user would have to undelete the same file several times, consider this: A / \ M1 D | \ | M2 P \ / Q If the user chooses to keep the file in both, P and Q, he'd end up with two 'foo' files. merge to P is the only undelete; merge to Q has a duplicate name conflict. Yeah, same issue: modify/delete conflict resolved by keeping (AKA asymmetrically copying) the file turns into a name conflict. As above, this is not a duplicate name conflict, but a special case of drop/modififed. I will implement this test case to make sure I'm not still missing something. AFAIUI turning this into a drop/modified conflict would require the newly introduced node-id in P to somehow be related to the old node-id of the file in A (and later M1, M2). Yes, by the file name, which is why it looks like a duplicate name conflict. It will be a problem if the file is renamed between P and the merge. Arguably, from a users perspective, it shouldn't be a drop/modify conflict, either. She already expressed her wish to keep the file in P. Why should she do that again for Q? I agree she should not have to, but it doesn't work that way because monotone doesn't have sutures; it forgets about the previous conflict resolution. This is the core of the
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hi, On 06/03/2012 05:57 PM, Stephen Leake wrote: fixed in branch nvm.issue-209; dropped/modified conflicts are fully supported. I think this needs some review before I merge it to main. I'm surprised issue 209 doesn't mention die-die-die merge. I consider this a work-around to that problem. As such, it doesn't help in the rare case of a missing root conflict, for example. More importantly, it's troublesome in cases involving multiple edits conflicting with one delete. With parallel modifications: A- file 'foo' exists / | \ M1 M2 D - M1, M2: independent modifications to 'foo' \ /\ / - D: deletion of 'foo' P Q - P, Q: merges, adding 'foo' under a new node-id In case of M1 and M2 being sequential edits, the user would have to undelete the same file several times, consider this: A / \ M1 D | \ | M2 P \ / Q If the user chooses to keep the file in both, P and Q, he'd end up with two 'foo' files. In particular, the resolution process allows keeping the modified file. This is implemented as a drop and add, which is what the user would do. But it is done during a merge, so merge can now create new nodes. That's why I'd argue that fully supported is an exaggeration, as the resurrected file is disconnected from its previous versions, as you pointed out yourself. Ways of re-connecting it have been discussed before, but yeah, it's been awhile since the last die-die-die discussion... Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Markus Wanner mar...@bluegap.ch writes: Hi, On 06/03/2012 05:57 PM, Stephen Leake wrote: fixed in branch nvm.issue-209; dropped/modified conflicts are fully supported. I think this needs some review before I merge it to main. I'm surprised issue 209 doesn't mention die-die-die merge. I consider this a work-around to that problem. Yes, it is. But I was more focussed on the immediate use case. I kept seeing the warning about changes will be lost fly by, and thinking that should be handled by the conflict resolution process. So now it is. I moved the discussion of the 'dropped/modified' conflict to right after the missing root conflict (which is where 'die-die-die' is introduced in the manual), and it now mentions 'die-die-die'. As such, it doesn't help in the rare case of a missing root conflict, for example. More importantly, it's troublesome in cases involving multiple edits conflicting with one delete. With parallel modifications: A- file 'foo' exists / | \ M1 M2 D - M1, M2: independent modifications to 'foo' \ /\ / - D: deletion of 'foo' P Q - P, Q: merges, adding 'foo' under a new node-id P is just a normal merge, while Q re-adds foo. Now it is a duplicate name conflict, with the resolution of keep one (with merged contents), delete the other. In case of M1 and M2 being sequential edits, the user would have to undelete the same file several times, consider this: A / \ M1 D | \ | M2 P \ / Q If the user chooses to keep the file in both, P and Q, he'd end up with two 'foo' files. merge to P is the only undelete; merge to Q has a duplicate name conflict. Nothing replaces good management and solid naming conventions in the first place :). But I don't see any show stoppers here, just complicated situations. It might be worth writing up these cases in tests to prove that, but then it's hard to tell when to stop. I think the second one would be sufficient in the tests. In particular, the resolution process allows keeping the modified file. This is implemented as a drop and add, which is what the user would do. But it is done during a merge, so merge can now create new nodes. That's why I'd argue that fully supported is an exaggeration, as the resurrected file is disconnected from its previous versions, as you pointed out yourself. Ok. Perhaps you could review what it says in monotone.texi, and possibly reword. Ways of re-connecting it have been discussed before, but yeah, it's been awhile since the last die-die-die discussion... Right; I started trying to do that in the 'file sutures stuff'. Way too hard, for very little gain :). Thanks for your input. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Hello, The following issue has been updated: 209 - support drop/modified conflict Project: monotone Status: Started 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, 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/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
c...@monotone.ca writes: fixed in branch nvm.issue-209; dropped/modified conflicts are fully supported. I think this needs some review before I merge it to main. In particular, the resolution process allows keeping the modified file. This is implemented as a drop and add, which is what the user would do. But it is done during a merge, so merge can now create new nodes. I don't think there is anything wrong with that, but I'd like confirmation. All the conflict related tests pass; I'm running all other tests now on MinGW. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict (monotone)
Stephen Leake stephen_le...@stephe-leake.org writes: c...@monotone.ca writes: fixed in branch nvm.issue-209; dropped/modified conflicts are fully supported. I think this needs some review before I merge it to main. In particular, the resolution process allows keeping the modified file. This is implemented as a drop and add, which is what the user would do. But it is done during a merge, so merge can now create new nodes. I don't think there is anything wrong with that, but I'd like confirmation. All the conflict related tests pass; I'm running all other tests now on MinGW. These tests are failing: 2 (imp)_merge((patch_foo_a),_(delete_foo_))FAIL (line 18) now shows both orphaned file and dropped/modified conflicts merged with resolve_conflicts_dropped_modified 344 merge((drop_a),_(rename_a_b,_patch_b)) FAIL (line 22) drop/modified, renamed merged with resolve_conflicts_dropped_modified 345 merge((patch_a),_(drop_a)) FAIL (line 21) drop/modified merged with resolve_conflicts_dropped_modified 346 merge((patch_a),_(drop_a,_add_a))FAIL (line 29) drop, add/modified merged with resolve_conflicts_dropped_modified 399 netsync_key_hooksFAIL (line 70) not related; fails same way in main 586 update_with_pending_modification unexpected success update has dropped/modified; now reports conflict improve test Fixing test 2 requires a code change; the current code reports both an orphaned node and a dropped/modified conflict, which don't have the right resolutions. So I'll add an 'orphaned' flag to the modified conflict, and require rename in addition to keep or user resolution in that case. Tests 344 and 345 are already covered in tests/resolve_conflict_dropped_modified, so I'll just delete those. Test 346 is a special case, and also requires a code change. The file was dropped and then re-added on one side, modified on the other. So the resolution can't be 'keep'; it has to be 'user' with merged content, and the content is stored in the already-added node. I'm working on fixing these cases. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
