darcs: src/Darcs/Patch/Real.lhs:422:21-50: Irrefutable pattern failed for
pattern Data.Maybe.Just a2'

How exciting!  Unfortunately, I can't attach the repository for forensics, but I
can say it involves a three-way conflict (all self-generated; three branches of
development)

Attached is the darcs --exact-version

I also tried to reproduce it with a current one, but the repository is broken
and I'll have to work at it some more

Attachments

• eversion-1

I forgot to add: this is a --darcs-2 repository

This is a very scary bug.  Definitely urgent.  And Eric, anything you can do to
reproduce this bug would be *very* much appreciated!

David

So I've been trying to re-create things so that I can reproduce the bug, but now
I'm getting parse errors (unfortunately, I don't have a snapshot of how things
were before I ran into trouble).

If it helps, here is the patch that I'm getting parse errors on.

Attachments

• conflictor-chunk

> So I've been trying to re-create things so that I can reproduce the bug, but now
> I'm getting parse errors (unfortunately, I don't have a snapshot of how things
> were before I ran into trouble).

I guess you can ignore the chunk-related errors.  This was me
foolishly trying to see if I could reproduce the error with a fresher
darcs (in which the chunk stuff had been rolled back).  Right, so now
I'm working with a chunky darcs and have no more parse errors.  Will
try to make the problem reproducable

On Mon, Feb 18, 2008 at 04:52:24PM -0000, Eric Kow wrote:
> > So I've been trying to re-create things so that I can reproduce the bug, but now
> > I'm getting parse errors (unfortunately, I don't have a snapshot of how things
> > were before I ran into trouble).
> 
> I guess you can ignore the chunk-related errors.  This was me
> foolishly trying to see if I could reproduce the error with a fresher
> darcs (in which the chunk stuff had been rolled back).  Right, so now
> I'm working with a chunky darcs and have no more parse errors.  Will
> try to make the problem reproducable

Argh, that's frustrating.  The trouble is that chunky darcs had bugs in it
that I never tracked down (which is why I rolled it back!).  :(  But if you
can reproduce this with a chunky darcs, it'll be well worth tracking down
what went wrong.
-- 
David Roundy
Department of Physics
Oregon State University

Alright, I'm making steady progress reconstructing the events that led to this
problem.

I've run into a different, but possibly related problem.

What's good is that I can re-generate this error easily.  So maybe I'll be able
to distill it into a minimal test case

[the repository name is a sort of code: step 07, from t2, branch 2 (the one
about forms), pulled from step 06, got a conflict and resolved it in working)]

======8<================
 $ darcs pull ../07-t2-b2-form-06-con-wrs
Tue Feb 12 17:29:49 GMT 2008  Eric Kow <E.Y.Kow@brighton.ac.uk>
  * Add participants' pack form.
Shall I pull this patch? (1/6)  [ynWvpxdaqjk], or ? for help: a
Backing up ./Makefile(-darcs-backup0)
Backing up ./Local/Reg2008.pm(-darcs-backup1)
Backing up ./index.shtml(-darcs-backup0)
We have conflicts in the following files:
./Local/Reg2008.pm ./Makefile ./index.shtml
                                                                
darcs failed:  applyHunks error:
oo is:
"  return p({id=>\"lastmodified\"},'Last modified: 2008-02-05 13:03').end_div;\n"


o:

"  return p({id=>\"lastmodified\"},'Last modified: 2008-01-04 12:35').end_div;\n"
line:
13
after prefix:
[snip]
==========================

I hate conflicts!!!

I've located the bug that causes this, and it's right smack in the most
complicated commute in the new conflict-handling code.  :(

The trouble is that the input to filterConflictsFL is incorrect in this case,
because we ignore the context of n1, which is problematic when it's a conflict
resolution patch.

I don't (yet) see a solution, and understand that few folks on the nosy list
will follow this, but wanted to write something down lest I forget what I've
figured out.

The problem (as is very common) lies in the fact that we have two "states" to
take into account in this version of the patch theory:  the "tangible"
state--which refers to the actual contents of files and directories--and the
"intangible" state, which refers to the set of patches in the repository.  The
two are interchangeable in the absence of conflicts.  Unfortunately, the
tangible state is the only one we track with our type witnesses, so it's still
easy to introduce bugs in which we get the intangible state wrong--as happens here.

The tangible and intangible states differ only in the case of a conflict
resolution patch, which is a patch that would have conflicted with some changes,
except that those changes have already been made.

Ideally, we'd have a dual type-witness system to track these two states, but
alas, that is not yet in place.  And it might be too tricky to work out in
practice anyhow.

To summarize (and you've been warned, I think, that this message is unlikely to
be comprehensible), when we call

filterConflictsFL p2 n2n1

the trouble is that p2 has in its context some patches that are resolved by a
patch in n2n1, but since n2n1 is stored as a FL Prim, there's no way for
filterConflictsFL to know this.  So we either have to adjust the context of p2
somehow before filtering, or somehow fix the context of n2n1.

Related to this is the fact that we define

n2n1 = n2 +>+ n1

which might actually be wrong at times, if some of the changes in n1 are
resolution patches.  I'm not certain about this.

Anyhow, I think that's all the work on this bug for today.  Hopefully tomorrow
I'll be able to see more clearly.

David

The following patch updated the status of issue701 to be resolved in the unstable branch:

* resolved issue701: fixed bug in commutation of certain conflicting patches. 
We were failing to treat a resolution patch properly when commuting a patch
that depends on the resolution with one that conflicts with it.  :(

You can view the patch details online here: 
http://darcs.net/cgi-bin/darcs.cgi/unstable/?c=annotate&p=20080226223612-72aca-4f81f06d64e5e6b37b9ca08fd112d34eddf912fe.gz

Unfortunately I ran into the same error message again with darcs 2.2.0 (exact
version attached). Also I cannot publish the repository that causes this. As
with kowey's original situation this is happening due to a conflict which has
eben induced by myself.

I am investigating the situation... but I could need some help from someone who
understands this commuting code.

Attachments

• version

Yikes!  Christian, perhaps you could use the outline in
  http://wiki.darcs.net/index.html/Forensics
to help?

Also, it may be worth opening a new ticket for this

Hi Eric,

I'd love to. But I am still a bit confused on the steps written out
in Forensics.  I have identified the lines that cause the conflict
situation in my case by unrecording/recording smaller hunks and
trying to apply those. Now, how can I tell (you) how the target
repo differs from the source repo? How can I get rid of all the
other files in the repo that don't matter? I guess this is what the
boiling down step is about....

Thanks or your help,

Christian

Just thought I would link to our progress on this bug:

http://lists.osuosl.org/pipermail/darcs-users/2009-February/017876.html

I think we should treat Christian's problems as a new bug, which I have filed as
issue1520

Closing this off accordingly