Note that this is not just an issue with commits or rollbacks.  Here's a
way to corrupt the repo with two (successful!) pulls:

Add something like this to localrepository.pull after locking the repo,
just to make the race very easy to exploit:

        import time
	time.sleep(5)

Then create one repo with a long history and another one with a shorter
(but different) history.  And then pull them both into a third
repository.  Boom.

hg init source1
cd source1
touch foo
hg add foo
for i in $(seq 10); do echo $1 >> foo; hg ci -m $i; done
cd ..
hg clone -r 0 source1 source2
cd source2
echo a >> foo
hg ci -m a
cd ..
hg init corrupted
cd corrupted
hg pull ../source1 & sleep 1; hg pull ../source2

Both pulls think there was no problem, but:
$ hg verify
checking changesets
changelog data length off by 854 bytes
Segmentation fault

Rereading the manifest and the changelog after locking the repo fixes
this.