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
On Fri, Jun 08, 2012 at 02:24:48PM +0200, Markus Wanner wrote: ... ... My prefered solution for that case would be to split the project into five (or more) projects; win32 support, unix support, common project; release project 1 contains common, unix, and win32; release project two contains common and unix. Now assume the parent project is not under your control. Your preferred solution is to split the project into different branches and you want to do that in your fork. In the win32 branch, you certainly don't ever want the unix files. And vice versa. You delete them. And you are cento percento sicuro you don't ever want to see them again. The parent project continues as it did before. You want to propagate their changes to your fork. Every modification from the parent project will currently invoke the warning about the modification not being visible in your sub-project, because of the files you deleted. Here we're discussing seriously the case I wondered about ages ago, where you want to split a project into several projects, but later decide to bring them back together. You have the problen of decidint=g which files to merge, and which files have more-or-less become different files, both of which need to be kept. ... ... In principle, I like the attribute approach better. However, there's the technical difficulty of being unable to store attributes on deleted files. (Also note that during the liveliness tracking and merging discussion, Nathaniel brought up the example of OpenEmbedded, who happens to create and delete lots of files in their process. So that if monotone never really deletes a file, but keeps it in its manifest with an invisible attribute or some such, the overhead from deleted files would soon surpass the amount of data for live files). What'd the overhead for deleted files now? With the problematical merges we're discuccing, we have to have some mechanism in place to discover that a deletion has been performed in the distant past on one of the nerging branches. Presumably that implementation mechanism would suffice -- the file doesn't need to be mentioned in the manifest for us to implement this model. ... ... It just occurs to me that this resembles the case of copying files. For a user, it's just copying a file. However, afterward, there are two options on how to merge modifications to copied files, which I've seen referred to as symmetrical and asymmetrical copy: either the merge only adjusts the original file (asym), leaving the copy as is. Or it could duplicate that modification as well and apply the modification to both files as part of the merge. There exist valid use cases for both variants. My point for this discussion is: I think that's another case where the user has a better chance of understanding the effects of his decision when asked at the time of the merge (instead of at commit time). It sounds like the same kind of problem. Merging should just work if both sides have the copying in their ancestry. Otherwise, there are decisions to be made, which might even involve line-by-line casuistry. 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. It can even be a line-by-line decision. You deleted this line on branch A, but modified it on branch B. It's a conflict. What do you want? Is this really any different from the case with files? ... ... Comments? This whole discussion relates to the user-interface for merges. When I'm faced with a merge, I'd sometimes like to be able to say, Hey, wait a minute, this takes serious thought. Could you please put all this stuff in my workspace without doing the merge, so I can pull out my whole development toolkit ans work out what has to be done? I'd sometimes even like the possibility of doing the merge a bit at a time, each time reporting progress to monotone until it's finally done. -- 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
--- On Thu, 7/6/12, Markus Wanner mar...@bluegap.ch wrote: However, another perfectly valid use case is wanting to permanently delete a file in a child branch, which might continue to get modified in the parent branch. You'd not want that to conflict every time you propagate, do you? (The warning is annoying enough, already). Agree here too, the trouble is knowing which method you want and when monotone should apply it. In my own projects I also agree with your earlier sentiment about die-die-die the policy is simple, don't delete anything... so I make use of the Attic directory workaround. However, I'm concerned about how to expose these two kinds of deletes to the user. I don't expect the average user to be able to understand the difference. Certainly not at the point in time of the delete. Maybe at the point in time of a merge (which currently emits the warning). A big reason I use monotone is it offers a simple interface and keeps track of things for me (I'm stupid, clumsy and forgetful): it shows me exactly what went in, and uses only that exact info to calculate further info. ie. merging, renames, file/directory conflicts, etc Maybe, the user even wants different revisions to merge differently for the same deleted file. So it's not a property of the delete, but... of what else? Good point, or even 2 users with conflicting merge ideas: 1 says drop, 1 says keep. I'm worried that the cure will be worse than the disease. Also in terms of backwards compatibility will we need to migrate existing databases and change existing merges. Is it compatible to go in our 1.x line as it changes/replaces die-die-die or should it go in a 2.x line ? ___ 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
Hi, On 06/08/2012 05:26 PM, Hendrik Boom wrote: What'd the overhead for deleted files now? Nil. Niente. Nada. Zip. Zero. With the problematical merges we're discuccing, we have to have some mechanism in place to discover that a deletion has been performed in the distant past on one of the nerging branches. Yeah. That mechanism is called die-die-die: if a file exists in the ancestor, but not on both legs, it must have been deleted on at least one leg. And must therefore not be included in the merge (i.e. remain deleted). Presumably that implementation mechanism would suffice -- the file doesn't need to be mentioned in the manifest for us to implement this model. Well, we get the fact that at least one side has deleted the file. However, that doesn't tell us (monotone) what to do in case of a (conflicting?) modification on the other side. Does the user still want to have the file deleted? Or does he change his mind and suddenly think the change is worth resurrecting the entire file? Monotone currently simply emits a warning, telling the user it's not quite sure if keeping the file deleted is what the user wanted. It sounds like the same kind of problem. Merging should just work if both sides have the copying in their ancestry. In that case, the user clearly applies a modification to only one of the two files of the copy. There's nothing unusual there. No doubt that change is *not* intended for the copy. The question arises in case one side does *not* have the copy in its ancestry: A-- file 'foo' enters the stage / \ B C -- B copies or duplicates 'foo' to 'bar', \ / -- C (not knowing 'bar') modifies 'foo' D-- D merges. Do you expect 'bar' in D to contain the modification applied in C or not? (Hint: there exist valid use cases for both possible answers). Otherwise, there are decisions to be made, which might even involve line-by-line casuistry. Asking the user to take this decision for every line that conflicts seems unreasonably verbose to me. It's hiding the real question behind: whether or not the copy in B was intended to be symmetrical or asymmetrical. It can even be a line-by-line decision. You deleted this line on branch A, but modified it on branch B. It's a conflict. What do you want? Is this really any different from the case with files? Well, if you really want the file to vanish, you'd not only have to re-iterate that decision once per conflicting modification, but for every conflicting line of every modification! That doesn't sound like an improvement to me. As pointed out before, deleting a file doesn't necessarily equal to deleting its contents. Just as renaming doesn't equal deleting and adding the file elsewhere (and thus obviously doesn't conflict with modifications, like deleting currently doesn't emit a full conflict, but just a warning). When I'm faced with a merge, I'd sometimes like to be able to say, Hey, wait a minute, this takes serious thought. Could you please put all this stuff in my workspace without doing the merge, so I can pull out my whole development toolkit ans work out what has to be done? I full heartedly agree here. I'd sometimes even like the possibility of doing the merge a bit at a time, each time reporting progress to monotone until it's finally done. *nod* (However, representing partly merged revisions sounds tricky enough. And I certainly don't want to start reasoning about merging partial merges. Let alone conflicting partial merge decisions...) Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel
