darcs fails to unrecord a patch I just recorded (the patch was actually recorded
with an older darcs - 1.0.6 I think):

$ tar -zxf foo.tar.gz 
$ cd foo
$ darcs check
Applying patch 620 of 620... done.
The repository is consistent!
$ darcs --version
1.0.8 (release)
$ darcs what
No changes!
$ cat _darcs/patches/pending
{
}
$ darcs unpull

Tue Oct 17 22:03:45 BST 2006  Ian Lynagh <igloo@earth.li>
  * PARTIAL MERGE: Fix scoped type variables for expression type signatures
Shall I unpull this patch? (1/620)  [ynWvpxqadjk], or ? for help: y

Mon Oct 16 23:35:16 BST 2006  sof@galois.com
  * mark stop event handle as invalid once closed, making shutdowns more graceful.
Shall I unpull this patch? (2/620)  [ynWvpxqadjk], or ? for help: d
darcs: failed to read patch in get_extra:
Fri Apr  7 11:18:39 BST 2006  Simon Marlow <simonmar@microsoft.com>
  * Fix a bug related to threads blocked on blackholes
  We weren't making them live early enough, with the result that
  finalizable objects referred to only by a thread blocked on a black
  hole could be finalized too early (see conc057 test).
Perhaps this is a 'partial' repository?
$

Attachments

• foo.tar.gz

Hmmm.  Does darcs check fail on this? (I haven't gotten around to untarring
and testing myself, and am rather too busy to do so...)
-- 
David Roundy
Dept. of Physics
Oregon State University

On Tue, Oct 17, 2006 at 11:04:58PM +0000, David Roundy wrote:
> 
> David Roundy <droundy@darcs.net> added the comment:
> 
> Hmmm.  Does darcs check fail on this?

No:

$ darcs check
Applying patch 620 of 620... done.
The repository is consistent!

Thanks
Ian

Very odd.

David

Does unrecording it with 1.0.6 work?

Is this a partial repository?

See also issue20, issue275.

On Wed, Oct 18, 2006 at 05:25:13AM +0000, Eric Kow wrote:
> 
> Eric Kow <eric.kow@gmail.com> added the comment:
> 
> Does unrecording it with 1.0.6 work?

No, that's why I upgraded.

> Is this a partial repository?

Yes.

Thanks
Ian

BTW, I saw this bug just yesterday, and Simon PJ has seen it at least a couple
of times.  In the end I had to work around it by pulling patches into a new
non-partial repository.

It's worrying how often I have to resort to using non-partial repositories when
something goes wrong: usually a get_extra crash of some kind.  Sometimes it's a
bug, but not always.  It would be nice if the error message could indicate
whether the crash is unexpected or not.

On Tue, Nov 28, 2006 at 10:13:57AM +0000, Simon Marlow wrote:
> It's worrying how often I have to resort to using non-partial repositories when
> something goes wrong: usually a get_extra crash of some kind.  Sometimes it's a
> bug, but not always.  It would be nice if the error message could indicate
> whether the crash is unexpected or not.

The trouble is that partial repositories were not originally designed to be
used by "main" developers, since it never occurred to me that repositories
would get *that* huge.  I expected them to be used only to get and pull and
perhaps occasionally record and send patches.  So in the design, it was
considered okay for darcs to "just fail" on partial repositories, which
made them much easier to implement, but is now causing trouble.  The
problem is that they differ from ordinary repositories in a way that is
practically indistinguishable from a disk error--the missing patches just
don't exist.

On the other hand, tracking down the reason for unexpected failure using
partial repositories is a valuable thing to do even for full repositories,
as it means a reduction of the number of patches that are read, which is
very good for everyone.  Alas, once again, I will need to focus on other
features.  :( Maybe after the term is over I'll have a bit more energy for
darcs hacking.
-- 
David Roundy
Department of Physics
Oregon State University

I've now also got a repository that you can't get with --partial, but can
without it. It's rather large so I haven't attached it, but I'll try to keep it
around so I can test with it in the future. Here's a log of it going wrong:

igloo@monk:~$ du -sh ghc-partial-get-of-me-fails/
185M    ghc-partial-get-of-me-fails/
igloo@monk:~$ darcs get --partial ghc-partial-get-of-me-fails will_fail
This is the GHC darcs repository (HEAD branch)

For more information, visit the GHC developer wiki at
  http://hackage.haskell.org/trac/ghc
**********************
Copying patch 270 of 270... done!

Fail: failed to read patch in get_extra:
Thu Oct  5 07:36:24 PDT 2006  simonpj@microsoft.com
  * Teach SpecConstr about Cast
  
  This patch teaches SpecConstr about casts; see Note [SpecConstr for casts]
  
Perhaps this is a 'partial' repository?
igloo@monk:~$ darcs get ghc-partial-get-of-me-fails will_work
This is the GHC darcs repository (HEAD branch)

For more information, visit the GHC developer wiki at
  http://hackage.haskell.org/trac/ghc
**********************
Copying patch 15125 of 15125... done!
Finished getting.
igloo@monk:~$ 


Thanks
Ian

I think this can be considered fixed with the new hashed format (and the darcs-2
format), so I'm marking it as resolved-in-unstable.  The bug is still there, but
only for folks using the old format.