With the most recent darcs unstable, the following gives an invalid pending:
C:\>mkdir test
C:\>cd test
C:\test>darcs init
C:\test>cat >foo
1
2
3
C:\test>darcs add foo
C:\test>darcs revert -a
darcs: bug in darcs!
There was an attempt to write an invalid pending!
If possible, please send the contents of _darcs/patches/pending_buggy
along with a bug report.
Please report this to bugs@darcs.net
If possible include the output of 'darcs --exact-version'.

The contents of pending_buggy look like:
{
addfile ./foo
hunk ./foo 1
-1
-2
-3
rmfile ./foo
}

As far as I can tell, sift_for_pending isn't doing its job properly - because
the addfile doesn't include the hunk of contents, it can't cancel against the
removal hunk, so we're left with something that can't be applied.  It might be
possible to fix this by allowing coalesceFilePatch (in PatchCommute) coalesce an
AddFile and a Hunk to produce an AddFile, in the case where it's all being done
in pending, but I don't know whether that idea is basically stupid, or how to
cleanly pass the required state through.

Any thoughts?

Edwin

On Fri, Dec 15, 2006 at 03:11:41PM +0000, Edwin wrote:
> 
> New submission from Edwin <edwin.thomson@businesswebsoftware.com>:
> 
> With the most recent darcs unstable, the following gives an invalid
> pending:

I think this is a bug I fixed last weekend, which hasn't yet made it into
darcs unstable.  If you could write up a test that reproduces this (and
send a patch), it'd be great (both for checking that I've really fixed it,
and avoiding the same mistake in the future).

> As far as I can tell, sift_for_pending isn't doing its job properly - because
> the addfile doesn't include the hunk of contents, it can't cancel against the
> removal hunk, so we're left with something that can't be applied.  It might be
> possible to fix this by allowing coalesceFilePatch (in PatchCommute) coalesce an
> AddFile and a Hunk to produce an AddFile, in the case where it's all being done
> in pending, but I don't know whether that idea is basically stupid, or how to
> cleanly pass the required state through.
> 
> Any thoughts?

I'd like to see how this works with my latest version of darcs (which Eric
hasn't yet reviewed).  My guess is that sift_for_pending is actually
getting a bad patch sequence to start with.
-- 
David Roundy
Department of Physics
Oregon State University

David Roundy wrote:
> David Roundy <droundy@darcs.net> added the comment:
> My guess is that sift_for_pending is actually
> getting a bad patch sequence to start with.

Quite possibly.  I don't really understand what it should be getting, 
but its input is:
{
{
addfile ./foo
}
{
hunk ./foo 1
-stuff
rmfile ./foo
}
}

and its output is:
{
addfile ./foo
hunk ./foo 1
-stuff
rmfile ./foo
}

I've also sent a patch adding a test for this.

Edwin

On Fri, Dec 15, 2006 at 06:02:57PM +0000, Edwin Thomson wrote:
> >David Roundy <droundy@darcs.net> added the comment:
> >My guess is that sift_for_pending is actually
> >getting a bad patch sequence to start with.
> 
> Quite possibly.  I don't really understand what it should be getting, 
> but its input is:
> {
> {
> addfile ./foo
> }
> {
> hunk ./foo 1
> -stuff
> rmfile ./foo
> }
> }

Yeah, that's an invalid sequence of patches, since you can't remove a line
from a file you just added.
-- 
David Roundy
Department of Physics
Oregon State University

This is fixed, due to your patch providing a test case.  Thanks!

David