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 mechanism would you propose for it, since you don't like this one? -- -- Stephe
__driver__.lua
Description: Binary data
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
