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.
Fri, 05 Aug 2016 15:00:53 +0200 branchmap: simplify error handlind when writing rev branch cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 05 Aug 2016 15:00:53 +0200] rev 29745
branchmap: simplify error handlind when writing rev branch cache Now that we have a general try except, we can move the error handling from the individual writes in it. Code will be reindented in the next changeset to help this on readability.
Fri, 05 Aug 2016 14:57:16 +0200 branchmap: acquires lock before writting the rev branch cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 05 Aug 2016 14:57:16 +0200] rev 29744
branchmap: acquires lock before writting the rev branch cache We now attempt to acquire a lock and write the branch cache within that lock. This would prevent cache corruption when multiple processes try to write the cache at the same time.
Fri, 05 Aug 2016 14:54:46 +0200 branchmap: preparatory indent of indent the branch rev writing code
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 05 Aug 2016 14:54:46 +0200] rev 29743
branchmap: preparatory indent of indent the branch rev writing code The rev branch cache is written without a lock, we are going to fix this but we indent the code beforehand to make the next changeset clearer.
Sun, 07 Aug 2016 09:47:07 +0900 mpatch: silence warning about maybe-uninitialized variable
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 09:47:07 +0900] rev 29742
mpatch: silence warning about maybe-uninitialized variable It's false positive, but it wouldn't be possible for gcc to know PyBytes_FromStringAndSize() sets PyErr_Occurred(). mercurial/mpatch_module.c:105:47: warning: 'r' may be used uninitialized in this function [-Wmaybe-uninitialized] PyErr_SetString(mpatch_Error, mpatch_errors[-r]);
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip