[darcs-devel] Re: [darcs-conflicts] alternate (simplified) conflicts proposal.

[David Roundy]

On Fri, Jul 14, 2006 at 07:39:13AM -0400, David Roundy wrote:
> Ah, you mean the resolution is in conflict? I'm starting to think that
> perhaps resolutions should never be in conflict.  Well, there's one
> case where they are in conflict.  If they resolve a change that's
> depended upon by a live change, then the resolution is in conflict
> with that live change.  But I'm starting to think that apart from that
> issue, they should never conflict.  They already require special merge
> and unpulling rules (since they eat up other changes), and I think
> that one can extend those so that a resolution can be merged with any
> change (or sequence of changes) that has its same context, which will
> be the case for any change that doesn't depend on its contents.

I've made an attempt at formulating this idea more clearly:

Behavior of resolution patches
==============================

A resolution of the sequence of changes ABC... generally commutes like
the sequence ABC...C^B^A^, with the exception that two successive
resolution patches always commute.

When merging, a resolution patch will never conflict with any patch
that has the same context, but will be held in the repository before
that patch.  This is unlike ``ordinary'' merging, in that this sort of
merge may not be reversible by commuting.

...

Unmerging
=========

Since there will now be merges that are not reversible by commutation,
I believe we will need to introduce some sort of unmerging or
obliterating higher-level operation.  I believe the semantics of this
can be expressed by splitting the repository into a set of conflictnig
branches prior to the change that needs removal, and then removing the
offending change and checking to see if there is a conflict.

Explanation: When we remove the change r(A) (``resolution of patch
A'') from a repository, the change A, which was previously surpressed
by r(A), will need to reappear.  The semantics of which patches need
to reappear I think are best expressed by asking oneself what the
result is of merging all the patches in the repository except the one
we wish to remove.  The point is that, unlike the previous
formulations of darcs, we cannot achieve this simply by commuting the
patch we want to remove to the ``end'' of the repository and then
removing it, since the patch A only exists hidden *within* r(A).

Thoughts?
-- 
David Roundy