"darcs changes" reads pristine files, despite having no real business doing so;
to verify, run "darcs changes --debug-verbose"; you should get output like:

Beginning identifying repository .
Done identifying repository .
Identified darcs-2 repo: /home/nwf/tmp/dtest/base.BUSTED.2
Looking for unrecorded changes...
Beginning reading pristine
Reading hash file
0000000472-256877a1618f656ab57ffbcf6e909e479818f0fb29bd6a5f3fe49b17d92bc64e from
pristine.hashed/
I'm doing copyFileUsingCache on
pristine.hashed/0000000472-256877a1618f656ab57ffbcf6e909e479818f0fb29bd6a5f3fe49b17d92bc64e

Tested against a darcs2 repository format; don't know about older formats.
Anyway, this seems simply a waste of time and probably should be fixed?

This most likely indicates a laziness bug... that is, a buggy lack of laziness.
 Reading the pristine cache *should* be 100% lazy, which means that if we try to
read it but don't use it, it shouldn't be read at all.  I'm just not sure
whether it's a bug in the reading of the pristine cache, or in the using of it.
 We need to read it if we are called with 'darcs changes -v -u', so we can
provide context.

Hi Petr. Is this fixed in darcs-hs?

Actually, I don't think I touched changes. But I recall someone else fixing
this for 2.3, let's see.

Ok, changes does a get_unrecorded_in_files_unsorted (on mainline), but
nowadays, this only happens when we actually get some filenames on the
commandline. In darcs-hs, this also uses index, so should be negligible time-

I also happen to think it would be enough to only read pending, but I can't
verify that right now. Either way, things should be pretty OK on the
performance front. I think you can close this (unless you want to investigate
only reading pending, which would of course be a little more efficient).

Thanks Petr.

Nathaniel, could you confirm if Darcs 2.3 avoids this problem?

Hmm, no updates in over 6 months, so I'm marking this presumed-dead. 
Nathaniel, if you could give us an update, we can resolve this properly.
 If not, we'll just leave it at that.  Thanks!

This does indeed appear to be fixed; thanks.

--nwf;