[darcs-devel] darcs misses conflict after tagging and optimizing

[David Roundy]

On Thu, Apr 21, 2005 at 09:27:03AM +0200, Tomasz Zielonka wrote:
> On Thu, Apr 21, 2005 at 12:50:47AM +0200, Tommy Pettersson wrote:
> > My reasoning is that any state (context), even if conflicting, is a
> > valid state of a repo, and a tag is a recording of any state.
> 
> Let's see what David says. I feel he will have a precise answer for
> this. I think that this issue is important enough that he won't mind
> interrupting his work on conflictors. We should resolve this before
> 1.0.3.

Indeed.  My feeling is that the bug is in PatchCommute.resolve_conflicts.
I think that tagging a conflicted situation should itself resolve the
conflict since the conflicting patches can no longer be commuted to the
"end of the sequence", which is what defines a conflict resolution.

I also think that Tommy's right that we should warn users who tag a
conflicted state, and give them a chance to cancel.

The problem is (as I see it) the call to flatten_to_primitives which is in
resolve_conflicts, which converts the tag into an empty patch.  Perhaps we
need to *first* eliminate from consideration all patches that cannot be
commuted to the "end of the sequence", and only then reduce to primitives
what's left.  But this heuristic won't work either, since you could have
a merge of two sequences, AB and ab, where A and a conflict, but B and b
don't, and A failst to commute with B and a fails to commute with b.  Then
neither A nor a could commute to the "end of the sequence", but there would
indeed be a conflict.

:(

My feeling is that this is an answer to the problem that can happen when
you have difficulty convincing darcs that a conflict has been resolved.
You could just tag the result, and that would tell darcs that the
conflict's been dealt with.  Or you could record a patch which depends on
both the conflicting patches.

A crude hack would be to make patchset_conflict_resolutions do a
"slightly_optimize_patchset", or something like that, which would make the
problem go away, but not by solving the real issue.  The trouble is that
resolve_conflicts was originally written to handle conflicts in pull or
push, where you know which are the "new" patches.  In the resolve command,
we don't know which are "new" patches, and there's really no *way* to
know.

On the other hand, I don't think it's *too* serious a bug.  Adding a
warning to tag would definitely be a good idea... except that searching for
conflicts can be *extremely* expensive, so perhaps it would be a bad idea.
Even if someone came up with a fix in resolve_conflits, I'd say it's better
to let 1.0.3 go without the fix, since the fix would open up the
possibility of introducing much more serious bugs, such as unapplicable
conflict resolutions.
-- 
David Roundy
http://www.darcs.net