On Sat, 4 Jul 2020 at 09:59, Ben Franksen <ben.frank...@online.de> wrote: > Am 04.07.20 um 00:10 schrieb James Cook: > >>> I'd say this is a feature, not a bug. If you mark the conflict between A > >>> and B as resolved, *without* recording a new patch, then this means you > >>> are satisfied with the resolution that reverts both changes. There is no > >>> reason why pulling C should conflict now. If, on the other hand, you are > >>> not satisfied with this resolution, you may want record a "proper" > >>> resolution, usually a mixture of A and B. This will then typically > >>> conflict with C. > > > > That's a great point. I'm much less worried now. > > You should be, though. I think what I wrote above is nonsense. > > This works only if inverses really cancel each other which means > applying the inverse is the same as obliterate. That means your repo > will not be able to remember that you once had a conflict between A and > B. I guess this is not what you want. > > But if inverses don't cancel then they aren't proper inverses in the > sense that you arrive at exactly the same context you started with. In > particular, you /cannot/ go back to the point you were before a > conflicted merge. > > Having proper inverses, or more generally a patch graph with cycles, is > more akin to time travel (not as in fantasy stories, but the physical > version i.e. time-like closed paths) than to a conventional journey that > visits the same destination but at a different time. > > In Darcs all patches in a repo have a positive name. You can obliterate > patches and start fresh (i.e. travel back in time) but that is unrelated > to conflicted merge which keeps all of the history.
I'm not sure I understand your concern right. Let me try to step through what I'd like to happen. Suppose the starting context is s and patches A and B conflict and have ending contexts a and b. In repository R1, the user tries to merge A and B, sees conflict markers, and records a conflict resolution. The conflict resolution consists of A^, B^, and a new patch C which replaces A and B. The repository now looks like this (after re-ordering a bit): s A a A^ s B b B^ s C c Now, suppose the user tries to pull from another repository R2 that has just patch A. Here, it is very important that R1 "remember" that the A\/B conflict was already resolved. Otherwise, it may treat C \/ A as a new conflict. But can't we just observe that the name "A" is already present in R1, and therefore there's no need to pull in A? Wouldn't that ensure that we never again try to resolve a conflict involving A? I don't know how darcs figures out what patches need to be pulled, especially if R1 is lazy. I suspect the current implementation might need to be extended so that a repository stores a set of all names of patches that have been cancelled out, i.e. the names of all patches A such that both A and A^ are present. But this is speculative because I don't know how that algorithm works. > If you want to have proper inverses (for conflict resolution) and still > remember all of the history, you must abandon the idea that a repo is a > sequence of patches (or rather: an equivalence class of such sequences, > module permutations). So your idea of phantom patches (a patch together > with its tombstone) amounts to saying that a repo is not a sequence of > patches, but a tree (with multiple dead branches), and to merge a patch > means to merge it with all branches of the tree (you'll have to work out > what that means precisely). I had been thinking about representing a repo as a tree. I think there is a certain equivalence between trees and patch sequence addresses: given a tree, you can turn it into a patch sequence address by doing a depth first search (record positive patches as you go deeper into the tree, and negative patches when you return back upward). I suspect the other direction can be done too, after you extend (Qi) in a patch sequence address to be a cycle and then do some commuting, but I'm not sure. An advantage of the patch sequence address representation over the tree representation is that I find it easier to think about how commuting can modify a cycle. With the tree representation you'd want to push conflicts as far down the tree as possible. This should be related to the minimality condition for patch sequence addresses, but I haven't wrapped my head around it. James _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
