tags: take lock instead of wlock before writing hgtagsfnodes1 cache This cache is shared across stores and hence we should take store lock before writing to it. Otherwise there will be race where one share with wlock is writing to this cache and other share with wlock is trying to read it simultaneously. Differential Revision: https://phab.mercurial-scm.org/D9001

statichttprepo: use LockUnavailable() instead of Abort() for lock (API) If we try to get a lock on statichttprepo, we get `error.Abort()` instead of subclass of `error.LockError()`. The callers which catches `error.LockError` fails to catch this case as the correct error is not raised. Raising `error.LockUnavaible()` is same as what is done for wlock also.

localrepo: warn if we are writing to cache without a lock From quite sometime we have two types of cache, `cache` and `wcache`. The later one is a working copy cache and the first one is a store cache. Let's add a check for warning if we are missing store lock while writing to these caches. This is inspired from some tag cache breakage which is observed when multiple shares are in play. The interesting part is that although we are still taking wlock to write store caches at many places, but still the test pases. Differential Revision: https://phab.mercurial-scm.org/D9000

commit: fix a wrong argument name in documentation Differential Revision: https://phab.mercurial-scm.org/D8985

git: remove unrequired assignment of listignored and listunknown Caught by test-check-pyflakes.t

grep: fix hash(linestate) to not include linenum linestate.__eq__() just compares the line values whereas __hash__() does hash both self.line and self.linenum, which violates the rule. __hash__() was added at fb502719c75c, "python 2.6 compatibility: add __hash__ to classes that have __eq__" with no additional remarks, so this would probably be a simple mistake. The test output changed because difflib.SequenceMatcher() internally uses a dict. As you can see, the line "export" is unchanged at the revision 2, so the new output is correct.

test-grep: document that trivially moved lines might not be detected I'm not going to fix this. I just learned "grep --diff" does clever thing than a simple grep(patch.diff(context=0)), and I think it's better to document how things work.