> > I've been reading about patch theory . I *thought* what's supposed > > to happen is this: > > > > * The effect of B' is the same as the effect of A. (i.e. create the file) > > * The effect of A' is the same as the effect of B. (i.e. add "some text") > > * Therefore, B'A' does the same thing as AB. > > * B' and A' include some information about the conflict, in addition > > to their effects described above. (They are "conflictor" patches.) > > * If I commute B' and A' again, I get back AB, since <-> is a > > symmetric relation. > > I understand. However, there is no patch theory I am aware of that is > able to make this work, except those where *any* two patches commute, so > there are no dependencies and patches never conflict.
Thank you. I've learned a lot from your reply. I have an idea for a patch theory that would satisfy these properties, and may have other advantages and might even be backward-compatible with darcs. I am not confident that it works, but I would love to have some feedback, if someone finds the time to read it. Is this list a good place to post something like that? > As I said in the beginning, there is no force-commute command in darcs > because that would be unsound. By definition, if B depends on A this > means A;B does /not/ commute. In the theory, one starts with primitive > patches for which there is no total merge operation, only a partial > clean-merge that may fail. If you have two independently recorded > patches A and B in the same context (we write this as A\/B), then > clean-merge succeeds iff A^;B commutes (where ^ means inversion). If > clean-merge(A\/B) does not succeed, then A\/B are said to be in conflict. Does darcs satisfy the property that if I merge two arbitrary repositories R and S to produce a new repository M, then separate out the patches again (i.e. pull just R's patches or just S's patches from M to a fresh repo) then I get back R and S? I hope the question makes sense. I can write a concrete sequence of commands if it doesn't. I had assumed this property was true because I thought force-commuting satisfied the magical properties in my previous email. I hope it is still true despite me being wrong about force-commuting. > When we add conflictors, we extend the set/type of primitive patches to > a larger set, such that now any two patches can be merged. However, we > must require that this extension preserves commutation behavior. In > particular, if A;B does not commute, then their embeddings in the larger > set of patches must commute neither. Ah, I had a different picture in mind. I thought that after adding in conflictors, then technically you end up with a universe of patches where everything commutes, but the patches end up looking ugly and unintuitive if you commute things that aren't "supposed" to. I thought a "force-commute" was simply a commute that wouldn't have been possible before adding conflictors to your universe of patches. This is what I hope my patch theory accomplishes. James _______________________________________________ darcs-users mailing list email@example.com https://lists.osuosl.org/mailman/listinfo/darcs-users