> > Oops, I didn't pay enough attention to your concrete example. > > > > Did you mean b = hunk f 1 [1a,2,3] [1b,2b,3b]? (I'm guessing hunk f n > > [u,v,w] [x,y,z] means lines n..n+2 of file f start out as [u,v,w] and > > end up as [x,y,z]; is that right?) > > Yes to both, sorry I messed up the example. For reference, here is the > fixed example in full: > > a=hunk f 1 [1] [1a] > b=hunk f 1 [1a,2,3] [1b,2b,3b] > c=hunk f 3 [3] [3c] > > > Then yes, I guess the order b;b^;c;a is not possible. > > > > I really want this to work, though, > > May I ask why? I mean, really, this is what commutation of patches is > all about: to determine if we /can/ re-arrange the internals of patches > in such a way that they make sense in a different context and in such a > way that the patch laws hold.
My dream is to be able to do away with conflictor patches, or any kind of "extended patches", and instead just use a primitive patch theory + inverses to back out of conflicts. Conflictors, or my own "extended patches", seem complicated and it would be interesting if we can just completely get rid of them. I suspect this can be done with a bit more flexibility in how patch sequences are rearranged. As a concrete example, let's use your patches a, b, c above. (I'm sticking with patch names for this example, so e.g. I won't change a to a' if the patch gets rewritten.) Consider: 1. Alice's and Bob's repositories both start out with just patch a. 2. Alice, in her repository, creates patch b. Alice now has a;b. 3. Meanwhile, Bob, in his repository, creates patch c. Bob now has a;c. 4. Now Alice pulls from Bob, and there is a conflict. I propose to handle the conflict by setting Alice's repository to a;b;b^;c;c^, and put uncommitted conflict markers in the working directory. The conflict could just as well be represented as a;c;c^;b;b^, but a;b;b^;c;c^ can't be commuted to a;c;c^;b;b^ because, e.g., c^;b don't commute. Now that I've written this out, I'm not sure it's actually necessary to be able to go between a;b;b^;c;c^ and a;c;c^;b;b^. It seems strange to not allow it though. Another thought: I'm not sure why I ended up talking about inserting/removing b;b^ as being a legal rearrangement. Maybe what I really need is a "cycle swap" operation that lets me change b;b^;c;c^ to c;c^;b;b^, or in general C;D to D;C for any cycles C and D. > > so now I wonder what happens if we > > just accept the situation: even though c can be rearranged to b;b^;c, > > The point is that you can /not/ do that. Yes, the /effect/ of b;b^;c is > the same as that of c, that is, you can apply both to the same tree and > get the same result. But with respect to commutation they are not > equivalent. > > > and a;c can be rearranged to c;a > > Remember that in the general commutation may result in a different pair > c';a'. (In my example above a=a' and c=c', but this is a special case.) > > > it turns out we can't combine the > > two to rearrange a;c to b;b^;c;a. > > This means "rearrangement" is not permutative. Permutivity is essential > for proving that merging is order-independent. This is *the* key feature > that distinguishes Darcs from e.g. git. How are you defining permutivity? My understanding is based on Jacobson's inverse semigroups paper. I think permutivity means that if there are two different sequences of commute operations that result in the same overall permutation of patches, then it doesn't matter which sequence of operations you apply: you'll end up with the same new patch sequence either way. I guess you have a stronger definition in mind, where the available operations don't change depending on context. Despite your example, I think two things could be guaranteed: * The available /commute/ operations don't depend on the context. I.e. if a;b can be commuted to some b';a', then any other a'';b'' with the same names can still be commuted to some b''';a'''. (Since I'm not changing the commute relation (I'm using "rearrange" for my new relation) there's simply no reason this would be violated.) * I think my weaker understanding of permutivity can be fully satisfied. In fact, I think there is no conflict between my notion of "rearrangement" and the definition of "patch universe" from my latex writeup*, so any property that follows from that definition could still be satisfied, including, for example, that any two patches with the same starting context and the same name are equal. *https://www.falsifian.org/a/xxOw/misc.pdf / https://hub.darcs.net/falsifian/misc-pub/browse/patch_theory/misc.tex > > I guess it's kind of ugly that changing the context can change what > > rearrangements are possible: > > So far, patch theory has been designed precisely to avoid that, which is > why in Darcs we allow re-arrangement of a sequence only via commutation. > > > in this case, the rearrangement c -> > > b;b^;c may be possible or not depending on whether a patch named "a" > > has been applied. This is cause to be suspicious, but is there an > > obvious reason it's unworkable? > > I can't answer this question in any exact or precise way. My gut feeling > is that it's going to be an ugly mess, but I haven't tried it so I may > be wrong. I should perhaps also point out that there are some operations > in Darcs for which the context is important; for instance, conflict > markup in general requires access to the complete context. Maybe I should work through some examples to understand (a) whether the "cycle swap" operation I described earlier is enough and (b) assuming you really do need to be count inserting/removing b;b^ as a valid "rearrangement", get a concrete sense of how the bad properties of this operation would actually manifest and cause confusion. James _______________________________________________ darcs-users mailing list darcs-users@osuosl.org https://lists.osuosl.org/mailman/listinfo/darcs-users
