Tue, 31 Mar 2020 19:44:28 -0700 hgcli: customize for Mercurial
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
Tue, 31 Mar 2020 19:07:36 -0700 hgcli: add stub PyOxidizer project
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
Tue, 31 Mar 2020 18:56:41 -0700 hgcli: remove legacy project
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
Thu, 26 Mar 2020 11:55:06 +0100 nodemap: automatically "vacuum" the persistent nodemap when too sparse
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
Fri, 28 Feb 2020 03:18:57 +0100 nodemap: display percentage of unused in `hg debugnodemap`
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
Fri, 28 Feb 2020 03:05:52 +0100 nodemap: make sure on disk change get rolled back with the transaction
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
Fri, 28 Feb 2020 02:23:38 +0100 nodemap: test that concurrent process don't see the pending transaction
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
Fri, 20 Mar 2020 23:41:35 +0100 testlib: adjust wait-on-file timeout according to the global test timeout
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
Fri, 28 Feb 2020 02:23:28 +0100 testlib: add a small scrip to help process to synchronise using file
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
Tue, 31 Mar 2020 16:14:10 -0400 setup: work around old versions of distutils breaking setup.py
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip