When I run many "darcs query contents" in parallel on the same repository
(because multiple users are clicking on the trac-darcs web site, like
http://allmydata.org ), then I sometimes get this error:  

Running (cd /home/source/darcs/tahoe/server-hashedformat; TZ=UTC darcs query
contents --quiet --match "hash
20080215012747-92b7f-46b20ea5a2f9ea5678b3f901f0818f8f61e9f97a.gz"
"src/allmydata/util/base32.py") failed: 2, darcs failed: Error applying hunk to
file ./src/allmydata/mutable.py : 


If I run the same command on the command-line, or indeed most of the times when
I run it by clicking on the trac-darcs, this doesn't happen, but instead the
darcs query works normally, which suggests that there is a race condition in
which access to the darcs repository is not sufficiently locked.

Zooko: could you make a script to help reproduce this?  See
http://bugs.darcs.net/issue687

This looks to me more like a but in withTempDir.  Are you by any chance running
on Windows? It's possible that createDirectory isn't atomic, which would be
problematic... but Eric's right, we'd need some way to reproduce this in order
to fix it.

It is possible that the trouble is lack of atomicity in reading the repository.
 That's something that we ought to fix:  if we only read the hashed_inventory
once, then we are safe from anything but file deletions, and file deletions
would give us a different (and pretty obvious) error.

David

We need somebody to devise a mechanism by which we can reproduce this bug,
probably some kind of script where we do a show contents and modify the
repository at the same time.

In issue1811 I tried to reproduce this exact problem, but I got a
different error instead.  No status change otherwise; we still need
somebody to devise a means of reproducing this.  Perhaps it's a good
idea to sort out issue1811 first, though.