A while ago somebody mentioned on IRC that hg pull would corrupt the
repo if it was started while a (soon to be aborted) commit was running
(more details on how to reproduce this below).

After poking it a bit, I think this happens because the manifest is read
in localrepository.__init__ (when the file has already been changed for
the commit), but when we actually get to use the manifest, the aborted
commit has already rolledback the repo.

To try to confirm this, I've tried to reread the manifest after locking
the repo in the pull method, and this does indeed fix this particular
issue.  This is of course only a quick hack, since there are probably a
few other places that would need some fixing.

How to reproduce it:

# create 2 repos, such that one of them can pull from the other
hg init a
cd a
touch foo
hg add foo
hg ci -m 'add foo'
hg clone . ../b
echo >> foo
hg ci -m 'change foo'
cd ..

# go into repo b and start a new commit
cd b
touch bar
hg add bar
hg ci
# do not close your editor

# in another shell, do an hg pull
cd b
hg pull ../a
# this will block, waiting for the lock
# go back to the editor and quit it without saving, to abort the commit.
# it will abort the transaction and rollback everything, without
# problems, but the hg pull will print something like:
pulling from ../a
waiting for lock held by 5592
searching for changes
adding changesets
adding manifests
abort: integrity check failed on 00manifest.d:1!
transaction abort!
rollback completed

# the output of hg verify afterwards
checking changesets
checking manifests
manifest data length off by 103 bytes
crosschecking files in changesets and manifests
checking files
1 files, 1 changesets, 1 total revisions
1 integrity errors encountered!