On Fri, Aug 03, 2007 at 11:08:07AM +0100, Simon Marlow wrote: > David Roundy wrote: > >On Wed, Aug 01, 2007 at 01:58:29AM +0100, Ian Lynagh wrote: > > >>And the "cancel A" patch doesn't have any sort of reference to B in it? > > > >Right. > > I seem to remember there was a problem with this approach. Perhaps not a > technical problem, but a conceptual one. > > Something like this: > > Suppose patches A and B conflict, and David and Ian both have repositories > containing A and B. > > Ian resolves in favour of A, records cancel(B). > David resolves in favour of B, records cancel(A). > > Ian pulls from David, and now has both cancel(A) and cancel(B). At this > point we expect a conflict, because both David and Ian have resolved the > original conflict in different ways; but cancel(A) and cancel(B) commute. > Don't they?
That is correct, and it's an infelicity of the proposed system. I believe it's unlikely to be a major problem, because in practice most resolutions (I think) will not only cancel one patch, but also make some other changes to incorporate both "ideas," and this patch will depend on one of the two patchs A or B. The problem arises when the two patches really both did the same thing, so cancelling either of them is by itself an adequate resolution. This infelicity can be avoided by adding an activation patch in the process of resolving. This patch type (which has been implemented in an earlier bit of Jason's work) is an identity patch that depends on a particular patch. So if Ian resolves in favour of A, records cancel(B) activate(A). David resolves in favour of B, records cancel(A) activate(B). then we'd get the whole conflict reappearing when our two resolutions are merged, which is what you (and I) want. We have the option (as a resolution UI choice separate from the choice of "conflict" semantics) of adding this behavior by default at a later date, so we've not painted ourselves into a corner here (so far as I can tell). An activation patch is a "normal" patch, in the sense that it's an ordinary primitive patch with no special semantics. You might consider its commutation behavior special, but of course every patch has commutation behavior unique to that patch type, so there's nothing "unique" about this... -- David Roundy Department of Physics Oregon State University _______________________________________________ darcs-devel mailing list darcs-devel@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-devel
