changegroup: move branch cache debug message to proper location Before, we logged about performing a branch cache update when we weren't actually doing it. Fix that.

journal: take wlock for writting the 'shared' file As we did for the shared extension itself, we add some locking around the write of the 'shared' file.

debugbuilddag: take wlock to cover '.hg/localtags' This debug command can write local tags. local tags are in the .hg directory and should be covered by the 'wlock'. This is now covered.

fakemergerecord: take wlock to write the merge state The merge state is supposed to be covered by the wlock. We fix the test extensions to comply to that.

shared: take wlock for writting the 'shared' file I do not see a reason why this should not be covered by the wlock.

mq: take wlock when 'qqueue' is doing write operations Apparently when this command was added, the locking was forgotten. No code changes beside the indentation from the locking context.

py3: make check-py3-compat.py use correct module name at loading pure modules Before this patch, check-py3-compat.py implies unintentional ".pure" sub-package name at loading pure modules, because module name is composed by just replacing "/" in the path to actual ".py" file by ".". This makes pure modules belong to "mercurial.pure" package, and prevents them from importing a module belonging to "mercurial" package relatively by "from . import foo" or so. This is reason why pure modules fail to import another module relatively only at examination by check-py3-compat.py.

py3: update output of check-py3-compat.py with python3 Recent work on mercurial/pure/mpatch.py made it import mercurial.policy, and changed output of check-py3-compat.py with python3 in test-check-py3-compat.t. But test-check-py3-compat.t isn't yet updated.

mpatch: raise MemoryError instead of mpatchError if lalloc() failed MemoryError is handled differently in dispatch._runcatch(). Since mpatch_errors[] isn't that useful now, I've changed it to a simple switch statement.

hgweb: config option to control zlib compression level Before this patch, the HTTP transport protocol would always zlib compress certain responses (notably "getbundle" wire protocol commands) at zlib compression level 6. zlib can be a massive CPU resource sink for servers. Some server operators may wish to reduce server-side CPU requirements while requiring more bandwidth. This is common on corporate intranets, for example. Others may wish to use more CPU but reduce bandwidth. This patch introduces a config option to allow server operators to control the zlib compression level. On the "mozilla-unified" generaldelta repository, setting this value to "0" (disable compression) results in server-side CPU utilization for a `hg clone` going from ~180s to ~124s CPU time on my i7-6700K. A level of "1" (which increases the transfer size from ~1,074 MB at level 6 to ~1,222 MB) utilizes ~132s CPU time.