it seems there is serious (performance-wise) regression in darcs2 since
it completely ignores checkpoint in darcs1 format repository. I've
tested on ghc stable repository today and darcs2 is able to get
--partial sources in 174 minutes, while darcs1 thanks to the checkpoint
in the repository is able to get the same in about 17 minutes.

Assigning to myself to check darcs history: has partial support been removed?
(it lead to some trouble) or is this actually a bug?

Sorry for the noise.  Partial support is still available for old-fashioned
repositories.

This looks like another instance of issue433.  That is, it may be a case of
checkpoint corruption in the GHC repository, fortunately, something that is very
easy to fix.  (For the record, I tried creating a checkpoint in my copy of the
GHC repo, and the partial get worked).

I'm going to resolve this, but let us know if you think this is wrong.  Perhaps
you should take it up with the GHC people.  You'll want them to
 mv _darcs/checkpoints _darcs/old-checkpoints
 darcs optimize --checkpoint
I'm adding Simon Marlow to this ticket, who may or may not be the best person to
contact...

I've tried fixing it similar to how you suggest, but although darcs1 copes fine
with the fixed repo, darcs2 doesn't. Am I doing something wrong?


igloo@monk:/home/darcs/ghc$ mv _darcs/checkpoints
_darcs/checkpoints-darcs-issue873-2
igloo@monk:/home/darcs/ghc$ darcs tag --checkpoint
What is the version name? 2008-06-01
Finished tagging patch 'TAG 2008-06-01'
igloo@monk:/home/darcs/ghc$ darcs --version
1.0.9rc1 (release candidate 1)
igloo@monk:/home/darcs/ghc$ 

$ time darcs get -q --partial --repo-name d1 http://darcs.haskell.org/ghc/
real    3m5.985s
user    0m15.249s
sys     0m1.532s
$ ls -1 d1/_darcs/patches/ | wc -l
1
$ ls -1 d1/_darcs/patches/
20080601155241-3fd76-13b3337cedf6323aab252f8035c39326411e3614.gz
$ darcs --version
1.0.9rc1 (release candidate 1)

$ time darcs2 get -q --partial --repo-name d2 http://darcs.haskell.org/ghc/
[...]
Downloaded: 49,328,595 bytes in 18553 files
Killed
real    143m19.564s
user    1m38.798s
sys     1m27.277s
$ ls -1 d2/_darcs/patches/ | wc -l
18553
$ darcs2 --version
2.0.0 (unknown)

Huh :-(

Maybe the fact that this is a remote repository is causing the problem?  For
example, if you make a checkpoint in your complete local copy, and darcs get
that, do you have a partial repository?

Ok, I don't think it has anything to do with remote/local.  The inventory file
seems to play a role (perhaps a difference in the version of darcs used to
generate it).

One guess is that tag --checkpoint does not optimize the inventory, and that
this confuses darcs.  Maybe it requires the top tag to match one of the items in
the checkpoint-inventory.

Ian, could you try running a darcs optimize --checkpoint?

Does darcs2 have better luck with it?

Actually, a darcs optimize seems to suffice.

I guess this is a regression in darcs2, in that it assumes that inventory files
will always be optimised when deciding if can use a checkpoint or not.

Looks like that's done the trick, thanks!

Ok, I guess this means we now have a non-urgent bug.

Either darcs2 needs to stop assuming the inventory is going to be optimized, or
darcs2 tag --checkpoint needs to optimize the inventory (we'd have to tell
people with earlier darcs to do a darcs optimize if this ever comes up).

I'm guessing the assumption is due to this line in
Darcs.Repository.Checkpoint.identify_checkpoint:
 pis <- (map info . catMaybes . mapRL lastRL) `liftSM` read_repo repository

Perhaps the lastRL?

For some reason, the auto-resolver did not pick up this patch

Tue Jun  3 12:47:07 BST 2008  David Roundy <droundy@darcs.net>
  * resolve issue873: always optimize inventory when adding a tag to old-format
repositories.