Tue, 20 Jul 2021 17:20:19 +0200 hgwebdir: avoid systematic full garbage collection
Georges Racinet <georges.racinet@octobus.net> [Tue, 20 Jul 2021 17:20:19 +0200] rev 47909
hgwebdir: avoid systematic full garbage collection Forcing a systematic full garbage collection upon each request can serioulsy harm performance. This is reported as https://bz.mercurial-scm.org/show_bug.cgi?id=6075 With this change we're performing the full collection according to a new setting, `experimental.web.full-garbage-collection-rate`. The default value is 1, which doesn't change the behavior and will allow us to test on real use cases. If the value is 0, no full garbage collection occurs. Regardless of the value of the setting, a partial garbage collection still occurs upon each request (not attempting to collect objects from the oldest generation). This should be enough to take care of reference cycles that have been created by the last request (assessment of this requires changing the setting, not to be 1). In my experience chasing memory leaks in Mercurial servers, the full collection never reclaimed any memory, but this is with Python 3 and biased towards small repositories. On the other hand, as explained in the Python developer docs [1], frequent full collections are very harmful in terms of performance if lots of objects survive the collection, and hence stay in the oldest generation. Note that `gc.collect()` is indeed trying to collect the oldest generation [2]. This happens usually in two cases: - unwanted lingering objects (i.e., an actual memory leak that the GC cannot do anything about). Sadly, we have lots of those these days. - desireable long-term objects, typically in caches (not inner caches carried by repositories, which should be collected with them). This is a subject of interest for the Heptapod project. In short, the flat rate that this change still permits is probably a bad idea in most cases, and the default value can be tweaked later on (or even be set to 0) according to experiments in the wild. The test is inspired from test-hgwebdir-paths.py [1] https://devguide.python.org/garbage_collector/#collecting-the-oldest-generation [2] https://docs.python.org/3/library/gc.html#gc.collect Differential Revision: https://phab.mercurial-scm.org/D11204
Wed, 28 Jul 2021 13:45:07 +0300 obsolete: disable other evolution config options if createmarkers is off
Anton Shestakov <av6@dwimlabs.net> [Wed, 28 Jul 2021 13:45:07 +0300] rev 47908
obsolete: disable other evolution config options if createmarkers is off We used to raise an abort in this case, but recent changes to local clone command (377d8fc20e34) resulted in destrepo both caring about experimental.evolution config options and not initializing extensions. So imagine if you had evolve and allowdivergence enabled in your ~/.hgrc. Local clone stopped working after 377d8fc20e34 because evolve sets experimental.evolution=all, but only on srcrepo, for destrepo the extension is not initialized. It's possible to make local cloning work by initializing extensions for destrepo in some cases, but in other cases (e.g. allowdivergence in ~/.hgrc, evolve extension in original-repo/.hg/hgrc) it would still fail. In a discussion with Pierre-Yves David it was decided to simply force other evolution options to be false if createmarkers is not enabled. Differential Revision: https://phab.mercurial-scm.org/D11223
Wed, 28 Jul 2021 13:47:21 +0300 fix: use obsolete.isenabled() to check for experimental.allowdivergence
Anton Shestakov <av6@dwimlabs.net> [Wed, 28 Jul 2021 13:47:21 +0300] rev 47907
fix: use obsolete.isenabled() to check for experimental.allowdivergence Now that obsolete.isenabled() can also check if divergence is allowed, let's use it for consistency. Other experimental.evolution options are already checked via this function. Differential Revision: https://phab.mercurial-scm.org/D11222
Wed, 28 Jul 2021 13:45:41 +0300 rebase: use obsolete.isenabled() to check for experimental.allowdivergence
Anton Shestakov <av6@dwimlabs.net> [Wed, 28 Jul 2021 13:45:41 +0300] rev 47906
rebase: use obsolete.isenabled() to check for experimental.allowdivergence Now that obsolete.isenabled() can also check if divergence is allowed, let's use it for consistency. Other experimental.evolution options are already checked via this function. Differential Revision: https://phab.mercurial-scm.org/D11221
Fri, 30 Jul 2021 00:11:56 -0400 typing: add several assertions to dirstatemap to appease pytype
Matt Harbison <matt_harbison@yahoo.com> [Fri, 30 Jul 2021 00:11:56 -0400] rev 47905
typing: add several assertions to dirstatemap to appease pytype I think it's been mentioned in IRC that these can't be None in this case. This fixes: File "/mnt/c/Users/Matt/hg/mercurial/dirstatemap.py", line 213, in addfile: unsupported operand type(s) for &: 'None' and 'int' [unsupported-operands] No attribute '__and__' on None or '__rand__' on int Called from (traceback): line 290, in reset_state File "/mnt/c/Users/Matt/hg/mercurial/dirstatemap.py", line 214, in addfile: unsupported operand type(s) for &: 'None' and 'int' [unsupported-operands] No attribute '__and__' on None or '__rand__' on int Called from (traceback): line 290, in reset_state Differential Revision: https://phab.mercurial-scm.org/D11235
Fri, 30 Apr 2021 16:00:40 -0700 tests: allow Google's internal builds of clang-format to be used stable
Kyle Lippincott <spectral@google.com> [Fri, 30 Apr 2021 16:00:40 -0700] rev 47904
tests: allow Google's internal builds of clang-format to be used These builds do not actually include any Google-specific formatting changes; the only reason they don't include the LLVM version number is due to a decision to elide the version number from *all* LLVM/clang projects. For most builds of clang-format, even "unofficial" ones, the LLVM version will be displayed; example: ``` clang-format version 14.0.0 (https://github.com/llvm/llvm-project.git 1830ec94ac022ae0b6d6876fc2251e6b91e5931e) ``` The Google-internal build looks like this: ``` clang-format version google3-trunk (1830ec94ac022ae0b6d6876fc2251e6b91e5931e) ``` Differential Revision: https://phab.mercurial-scm.org/D10538
Tue, 26 Oct 2021 18:53:58 +0530 Added signature for changeset 6ee0244fc1cf stable
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 26 Oct 2021 18:53:58 +0530] rev 47903
Added signature for changeset 6ee0244fc1cf
Tue, 26 Oct 2021 18:53:51 +0530 Added tag 5.9.3 for changeset 6ee0244fc1cf stable
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 26 Oct 2021 18:53:51 +0530] rev 47902
Added tag 5.9.3 for changeset 6ee0244fc1cf
Mon, 25 Oct 2021 17:57:01 +0200 relnotes: update release notes for upcoming 5.9.3 stable 5.9.3
Raphaël Gomès <rgomes@octobus.net> [Mon, 25 Oct 2021 17:57:01 +0200] rev 47901
relnotes: update release notes for upcoming 5.9.3 Differential Revision: https://phab.mercurial-scm.org/D11720
Thu, 21 Oct 2021 14:03:33 +0200 heptapod-ci: actually give pytest more time before timeout stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Oct 2021 14:03:33 +0200] rev 47900
heptapod-ci: actually give pytest more time before timeout `HGTEST_TIMEOUT` is overridden by `HGTEST_SLOWTIMEOUT` for tests marked as slow, which `test-check-pytype.t` is. So this whole time the timeout was 1500s (or 25 minutes), which is unfortunately not long enough for a *lot* of the times it's run on the CI. Differential Revision: https://phab.mercurial-scm.org/D11717
Wed, 20 Oct 2021 18:44:26 +0100 tests: better determinism in test-chg.t stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Wed, 20 Oct 2021 18:44:26 +0100] rev 47899
tests: better determinism in test-chg.t chg tests fail pretty often with "Sample count: *" line disappearing. It disappears because the sample count is zero, in which case a custom message is printed. This commit makes the test succeed in that case. Differential Revision: https://phab.mercurial-scm.org/D11716
Tue, 19 Oct 2021 16:05:20 +0200 python: compatibility for python 3.11 (issue6604) stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 19 Oct 2021 16:05:20 +0200] rev 47898
python: compatibility for python 3.11 (issue6604) The `unittest._TextTestResult` alias has been removed. The "new" name has been available since 3.2, and we only support 3.5.3+. Differential Revision: https://phab.mercurial-scm.org/D11690
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 tip