Re: How to extend a patch theory to fully commute

> > I'd say this is a feature, not a bug. If you mark the conflict between A
> > and B as resolved, *without* recording a new patch, then this means you
> > are satisfied with the resolution that reverts both changes. There is no
> > reason why pulling C should conflict now. If, on the other hand, you are
> > not satisfied with this resolution, you may want record a "proper"
> > resolution, usually a mixture of A and B. This will then typically
> > conflict with C.

That's a great point. I'm much less worried now.

> > That said, there is a problem here. To arrive at the default resolution
> > (revert the conflicting prim patches) you add inverse patches to the
> > repo. But what does "adding a patch to a repo" mean, precisely, if
> > inverses are involved? Is a repo still a sequence of patches? Is A;A^;A
> > the same as A? That would be bad because resolving a conflict would then
> > be the same as obliterating the conflicting patches. So inverse pairs
> > cannot simply be cancelled.
>
> An afterthought: what if you do not simply add the inverse for the
> resolution, but instead record a new patch with the same effect as the
> inverse? In other words, you add the inverse, but give it a new
> (positive) name, so that it cannot cancel. Just an idea.

I'll think about that idea.

Here's another approach I'd been thinking about, which I'd held back
because I thought the thing we just talked about was a bug that needed
fixing : )

(a) When you pull patches from some repo R1 to R2, you never pull
patches that are already present in both. (I assume Darcs already
ensures this, but I don't know how it does that given that
repositories can be lazy.)

(b) However, we'll allow a repository to contain both a patch and its
inverse. A and A^ are completely independent patches as far as rule
(a) is concerned.

(c) Another way of looking at rules (a) and (b): a patch A can be
added to the repository, and later its "tombstone" A^ can be added
which just means A was deleted. Once a tombstone is added to a
repository, it is there forever and the original patch A can never be
added back. I'm being a bit vague here about how that's actually
implemented; I should figure out the details.

(d) The "patch" that resolves the A\/B conflict is actually two
patches, A^ and B^ (or more if the conflict is more involved). It may
be desirable to store some metadata somewhere indicating that A^ and
B^ were added together as part of a merge conflict, but as far as the
theory is concerned, adding A^ and adding B^ were completely separate
events. Given rules (a) and (b), there's no trouble with adding A^ and
B^.

James