Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 Mar 2020 19:44:28 -0700] rev 44639
hgcli: customize for Mercurial
Now that we have a shiny new PyOxidizer-based hgcli project, let's
customize it for Mercurial!
This commit replaces the auto-generated pyoxidizer.bzl with one
that installs Mercurial from the local source repository.
A README.md with build instructions has been added.
The Cargo.toml file has been updated to reflect the proper license
and reference the added README.md.
In my Linux environment, running the test suite yields 27 failures.
It's worth noting the run time of the test harness on Linux on my
Ryzen 3950X:
before: 378s wall; 9982s user; 1195s sys
after: 353s wall; 8996s user; 958s sys
% orig: 93.4 wall; 90.1 user; 80.2 sys
While I haven't measured explicitly, I suspect the performance win is
due to in-memory resource loading (which is known to be faster than
Python's filesystem importer).
Differential Revision: https://phab.mercurial-scm.org/D8351
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 Mar 2020 19:07:36 -0700] rev 44638
hgcli: add stub PyOxidizer project
Using commit
c772a1379c3026314eda1c8ea244b86c0658951d of
PyOxidizer, I ran `pyoxidizer init-rust-project hgcli` to
create a stub Rust project. The only modifications I made from
what that command produced are:
* Update location of pyembed crate to PyOxidizer's Git repository.
* Removed some trailing whitespace from pyoxidizer.bzl
* Added auto-generated Cargo.lock file
Subsequent commits will modify the stub project to Mercurial's
needs.
Differential Revision: https://phab.mercurial-scm.org/D8350
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 31 Mar 2020 18:56:41 -0700] rev 44637
hgcli: remove legacy project
This code is a logical precursor to PyOxidizer. It is now
defunct.
Differential Revision: https://phab.mercurial-scm.org/D8349
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Mar 2020 11:55:06 +0100] rev 44636
nodemap: automatically "vacuum" the persistent nodemap when too sparse
We arbitrarily pick "10%" as the threshold.
Differential Revision: https://phab.mercurial-scm.org/D8193
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 03:18:57 +0100] rev 44635
nodemap: display percentage of unused in `hg debugnodemap`
This is useful to assess the density of the cache.
Differential Revision: https://phab.mercurial-scm.org/D8192
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 03:05:52 +0100] rev 44634
nodemap: make sure on disk change get rolled back with the transaction
In case of errors, we need to rollback the change made to the persistent
nodemap.
Differential Revision: https://phab.mercurial-scm.org/D8191
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 02:23:38 +0100] rev 44633
nodemap: test that concurrent process don't see the pending transaction
We don't want other client to read uncommitted data, until the transaction is
really committed.
Differential Revision: https://phab.mercurial-scm.org/D8190
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Mar 2020 23:41:35 +0100] rev 44632
testlib: adjust wait-on-file timeout according to the global test timeout
Lets assume that if test timeout have been set to be twice as long, it means
local timeout should be twice as long too.
I am not aware of any case were extending timeout for file based synchronisation
was necessary, but the safety seems simple to implements.
Differential Revision: https://phab.mercurial-scm.org/D8316
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 02:23:28 +0100] rev 44631
testlib: add a small scrip to help process to synchronise using file
Creating and waiting for files is a robust way to synchronise two processes
running concurrently. We already use this approach in various tests. I am adding
a official script to do so before adding more usage of this.
Differential Revision: https://phab.mercurial-scm.org/D8189
Augie Fackler <augie@google.com> [Tue, 31 Mar 2020 16:14:10 -0400] rev 44630
setup: work around old versions of distutils breaking setup.py
I'm not really sure how to trigger this, but we saw it in our build
environment for Windows at Google. This fixed it. Sigh.