I was going to try to come up with something like:

darcs get --partial --tag=2006-10-05 \
    http://darcs.haskell.org/ghc ghc.breakitnow
# darcs says: darcs: Couldn't read tag
cd ghc.breakitnow
darcs pull --tag=2006-10-22 --all
darcs unpull --last=1
# grab foo.dpatch from this issue or whatever
darcs apply foo.dpatch
darcs pull --tag=2006-10-22 --all
darcs optimize --reorder

to reproduce a bug I ran into in my GHC working dir, but unfortunately the very
first command failed. (As the comment afterwords might hint.)

To repeat:

darcs get --partial --tag=2006-10-05 \
    http://darcs.haskell.org/ghc ghc.breakitnow

grabs the wrong checkpoint. (It grabbed the one for the 2006-10-22 tag when I
last tried it. I'm not sure which it should have grabbed, but that one clearly
ain't it.)

On Mon, Oct 23, 2006 at 21:28:51 +0000, Samuel Bronson wrote:
> darcs get --partial --tag=2006-10-05 \
>     http://darcs.haskell.org/ghc ghc.breakitnow
> # darcs says: darcs: Couldn't read tag

I can reproduce this on my end.  For what it's worth, the error
comes from Depends.get_patches_in_tag, in the function calls

Get.go_to_chosen_version
->   Match.get_one_patchset
-> * Depends.get_patches_in_tag

If I understand correctly, to retrieve the tag 2006-10-05, darcs does a
regular darcs get and then obliterates all patches that come after that
tag. Because of that of the couldn't read tag failure, darcs does not
obliterate any patches, leaving the user with a repository that is too
far in the future.

This might be caused by some interaction between this behaviour and the
checkpoints stuff, or it might be completely unrelated.  Any ideas on
how to test this further?

Anyway, I'm not in a position to do anything about it, but thought this
bug could use a little triage/probing.

On Tue, Nov 14, 2006 at 09:25:57PM +0000, Eric Kow wrote:
> If I understand correctly, to retrieve the tag 2006-10-05, darcs does a
> regular darcs get and then obliterates all patches that come after that
> tag. Because of that of the couldn't read tag failure, darcs does not
> obliterate any patches, leaving the user with a repository that is too
> far in the future.
> 
> This might be caused by some interaction between this behaviour and the
> checkpoints stuff, or it might be completely unrelated.  Any ideas on
> how to test this further?

It's just that the logic for grabbing the checkpoint doesn't pay any
attention to the specification of which tag or patch to grab to.  I think
when I wrote this code I didn't figure that any developers would end up
using --partial, and that non-developers wouldn't need to grab older
versions.  That was before I had a clear idea of how large repositories
would get or how necesary --partial would become.

This really shouldn't be too hard to fix.  It'd be nice to first add a test
for it, though, so that we'd be sure to avoid regressing this.  Not that
I'll have time to do this myself, but it's at the level that we certainly
can do something about it.  We'd just need to check whether the tag we're
getting to is before or after the checkpoint and keep looking at older
checkpoints until we reach one that's okay.

I should perhaps point out that it's not expected that "everything will
work" with a partial repository.  With the hashed inventories we ought to
be able to make "lazy" partial repositories, in which patches will be
downloaded on demand (with the current failure result when the download
fails).  The downside of this, though, would be that it could have the
result that a user who naively runs "darcs changes -s" ends up downloading
the entire history of the ghc repository.
-- 
David Roundy
Dept. of Physics
Oregon State University

I believe this is "resolved-in-unstable", because the darcs-2 format doesn't
have checkpointing. See discussion and test in issue517.