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
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
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
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
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
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
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 26 Oct 2021 18:53:58 +0530] rev 47903
Added signature for changeset 6ee0244fc1cf
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 26 Oct 2021 18:53:51 +0530] rev 47902
Added tag 5.9.3 for changeset 6ee0244fc1cf
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
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
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
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