Sun, 07 Aug 2016 17:15:19 +0200 debugbuilddag: take wlock to cover '.hg/localtags'
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:15:19 +0200] rev 29755
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.
Mon, 08 Aug 2016 17:33:45 +0200 fakemergerecord: take wlock to write the merge state
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Mon, 08 Aug 2016 17:33:45 +0200] rev 29754
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.
Sun, 07 Aug 2016 17:10:47 +0200 shared: take wlock for writting the 'shared' file
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:10:47 +0200] rev 29753
shared: take wlock for writting the 'shared' file I do not see a reason why this should not be covered by the wlock.
Sun, 07 Aug 2016 17:00:45 +0200 mq: take wlock when 'qqueue' is doing write operations
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sun, 07 Aug 2016 17:00:45 +0200] rev 29752
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.
Tue, 09 Aug 2016 02:28:34 +0900 py3: make check-py3-compat.py use correct module name at loading pure modules
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 09 Aug 2016 02:28:34 +0900] rev 29751
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.
Tue, 09 Aug 2016 02:28:34 +0900 py3: update output of check-py3-compat.py with python3
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 09 Aug 2016 02:28:34 +0900] rev 29750
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.
Sun, 07 Aug 2016 10:06:56 +0900 mpatch: raise MemoryError instead of mpatchError if lalloc() failed
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 10:06:56 +0900] rev 29749
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.
Sun, 07 Aug 2016 18:09:58 -0700 hgweb: config option to control zlib compression level
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 07 Aug 2016 18:09:58 -0700] rev 29748
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.
Sat, 06 Aug 2016 17:04:22 -0700 help: don't try to render a section on sub-topics
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 06 Aug 2016 17:04:22 -0700] rev 29747
help: don't try to render a section on sub-topics This patch subtly changes the behavior of the parsing of "X.Y" values to not set the "section" variable when rendering a known sub-topic. Previously, "section" would be the same as the sub-topic name. This required the sub-topic RST to have a section named the same as the sub-topic name. When I made this change, the descriptions from help.internalstable started being rendered in command line output. This didn't look correct to me, as it didn't match the formatting of main help pages. I corrected this by moving the top section to help.internalstable and changing the section levels of all the "internals" topics. The end result is that "internals" topics now match the rendering of main topics on both the CLI and HTML. And, "internals" topics no longer require a main section matching the name of the topic.
Fri, 05 Aug 2016 15:01:16 +0200 branchmap: remove extra indent
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 05 Aug 2016 15:01:16 +0200] rev 29746
branchmap: remove extra indent This clean up the rest of the previous changeset.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip