The new 'optimize --upgrade' command fails messily on partial repos.

It should either provide a proper error message, or ideally convert them to lazy
ones if this is actually feasible.

Op 23-09-09 22:50, Ganesh Sittampalam schreef:

> The new 'optimize --upgrade' command fails messily on partial repos.

Clarification request: Does it leave messy error messages on the screen, 
or does it even leave behind a messy repo?

Here's example output optimizing a partial GHC repo.  It makes it past the
corruption check (how? by just replaying from the checkpoint?) and then falls
over and ideas during the hashing patch stage.

Note that whoever fixes this could likely make use of Hopefully.  Also if
converting to lazy (which actually should not be hard), you'll probably need to
create pristine from the checkpoint plus new patches.

Replaying patch 1/418
Replaying patch 299/418

Checking repository in case of corruption...
The repository is consistent.
darcs: unable to read patch:
Fri Sep  5 11:16:36 CEST 1997  simonm
  * [project @ 1997-09-05 09:16:19 by simonm]
  don't set $(WAYS) in ghc/mk/paths.mk, set it explicitly in the
  Makefiles where it is required (compiler/Makefile, lib/Makefile and
  runtime/Makefile).
  
  Remove the overriding of $(WAYS) from utils/*/Makefile.
  
  No need to eliminate warnings for overlapped patterns in
  Happy-generated parsers any more.
  
  Don't compile OccurAnal with -O if we're using a pre-version-2 GHC,
  since it seems there's an optimiser bug.
/private/tmp/ghc_0/_darcs/patches/19970905091636-6c85e-0f84f4eb10ca844ea3be22127df4f22a4f044544.gz:
openBinaryFile: does not exist (No such file o
r directory)