Re: [Monotone-devel] Updated Issue 209 - support drop/modified conflict
Hi, On 06/09/2012 04:47 PM, Stephen Leake wrote: So we need some way to tell monotone what our permanent decision is. Agreed. But it's easier to use directories and build directives to achieve that result, so I'm back to thinking this is not a valid use case. Here, you need to elaborate. How can directories and build directives be a replacement for a thing as simple as a file deletion. See the current monotone system for win32 and unix; much simpler than dealing with multiple projects. Uh.. you were the one who proposed to split into multiple projects in that use case. Anyway, we seem to agree that there *is* a use case for wanting to permanently delete a file, disregarding concurrent modifications to it on other branches of the revision tree. So you need a 'pure' upstream branch, an 'annotated' upstream branch (with the delete attributes), and a 'local' branch. Then the update process would be: So, taking branches out of the equation (merging doesn't care about branch certs), that effectively means adding a helper revision to store the merge preferences. I dislike it being on the upstream side, which adds quite a bit of complexity compared to being able to store it in the line of revisions that performed the delete. But well... An attribute would eliminate the mtn 1.0 warning, so it would be a better solution to your use case. It would suppress the warning, which is helpful. However, I doubt somewhat that's worth a separate annotated branch. Too much work for the user to maintain that. Too much that can go wrong. Note that file suture is no help in this case. Agreed. Proper file resurrection could be, though. I don't see that. By proper file resurrection I mean approaches like tracking file liveliness, which could refer to the original node id for undeleting the file. With such a thing in place, you don't need to suture anything, because it's just one node id. No matter how many renames and liveness changes. At least when thinking of deleted files as moved to some unreachable place, contents intact. There once was such a proposal for tracking (and properly merging) a files liveliness. That makes sense. CVS has an internal Attic directory for deleted files. Well, it only makes sense for the analogy of unlinking, throwing away user model, as opposed to truncating or destroying before dropping. That's because modifications don't conflict with drops in that case (at least not without changing that part of the merge code, compared to monotone-1.0). I read through your suture documentation and noticed you trapped into the same fallacy of trying to identify files by their file names. That was not the intent. I'm sure it uses file names when trying to resolve conflicts. Huh? Using file names when trying to resolve conflicts is what I'm saying is the wrong thing to do. Only node ids have a chance of reliably referencing what the user considers to be the same file across revisions (in the face of possible renames). IMO sutures must not depend on file names. Instead, it should well be possible to suture two files with different paths. That was one use case covered in the sutures doc. Okay, good. I don't see how that patch would be useful. Let's put this in a use case: A / \ M1 D-- D change list includes patch to zero length, and delete | \ | M2 P-- how is that information used here? \ / Q -- or here? If the node is just gone in D and P, how do we notice the patch? Oh, right, that doesn't work. Sorry, my brain fart. Thanks for putting that straight. Right. So a general 'conflict resolution' attribute might be appropriate. Agreed. Complicating things, I don't think it's a file specific decision. Maybe there exist use cases where you want to ignore modifications from the parent project, but at least want to see a warning, or even better a real conflict, if somebody else from your project tried to modify the file before seeing your deletion. I don't follow this. It's still per file. Although, for the win32/unix example, it could be per directory. We were assuming a single upstream branch. However, there can well be multiple different branches propagated from. I was trying to say that it might not suffice to store: for file foo, prefer dropping, in case the drop conflicts against any modification. Instead, I was thinking about something like: for file foo, prefer dropping, in case the drop conflicts with a modification from branch upstream This would allow modifications from other branches (including the target branch itself, for example) to still raise a drop/modify conflict. (Of course, the meaning might need to get turned around in case we store such a thing in an annotated upstream branch instead of the branch that drops the file.) My gut feeling is that such decisions should be stored per branch. I.e. assuming branches parent and child, a file foo existing in
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
