Re: How to extend a patch theory to fully commute

> > How do we present this at the user level?
> > 
> > The unresolved conflict is probably presented quite similar to how we do
> > it in Darcs now: we tell them that there is a conflict between A and B
> > and present the alternatives a1 and b1 as the "content" of the conflict,
> > e.g. using conflict markup.
> > 
> > So far so good. But what about conflict resolution? Suppose the user
> > decides that a1 is what they want after all. How do we represent the
> > chosen sequence, consisting of
> > 
> >   A=(a1;a2);B=(b2)
> > 
> > with a "crippled" B in a sensible way?
> > 
> > This is just a UI question, but it may be important. For instance, if a
> > different user later pushes B to another repo, they may be surprised to
> > see that what they push contains more prims than they could see i.e. it
> > will be the original B=(b1;b2)!
> 
> Although I haven't fully worked it out, the answer I'm leaning toward
> is that the deactivation of b1 behaves like a patch (b1 inverse, if you
> want to think of it that way). So if your repo has B=(b2), that really
> means it has b1,b2,b1^; b1^ probably appears as part of the conflict
> resolution patch. When you push your changes, b1^ gets pushed too. There
> is no way for b1 to ever become active again, except obliteration of b1^.
> 
> I like this point of view because it gives a simple monotone rule about
> what happens to each prim when you push: each prim can be in state 0
> (not present), 1 (present) or 2 (was present but now deleted), and
> merging puts each prim in the max of the two original states (plus
> conflict resolution, which is also monotone). This is what I was
> thinking in an earlier email when I said I want "inverses on all the
> not-chosen branches instead of a flag on the chosen branch" of the
> tree.

Oops, this doesn't really answer the question you raised. The user would
still push both b1 and b2 if they decide to push just B. I need to slow
down a bit...

-- 
James