[darcs-devel] Re: Example Conflicts

David Roundy droundy at darcs.net
Fri Aug 3 11:35:44 PDT 2007


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


More information about the darcs-devel mailing list