rhg: check that .hg/requires is ASCII Differential Revision: https://phab.mercurial-scm.org/D9400

rhg: exit with relevant code for unsupported requirements Differential Revision: https://phab.mercurial-scm.org/D9399

revlog: store new index entries as binary For a pure-Python unbundle of the current NetBSD test repository, this results in a 10% peak RSS reduction. Using the C revlog index, it shows 25% peak RSS reduction. This is a direct result of avoiding at least 8 objects per new changeset or 200 Bytes+ on AMD64. Differential Revision: https://phab.mercurial-scm.org/D9162

packaging: enable rust extensions on centos Test on CentOS 7, repository with ~170000 tracked files, no untracked files: 10 runs with this enabled: -- Run #0 time: 0.6519973278045654 -- Run #1 time: 0.6933724880218506 -- Run #2 time: 0.7512078285217285 -- Run #3 time: 0.7517638206481934 -- Run #4 time: 0.5966529846191406 -- Run #5 time: 0.5960886478424072 -- Run #6 time: 0.5940573215484619 -- Run #7 time: 0.5963726043701172 -- Run #8 time: 0.6048009395599365 -- Run #9 time: 0.603604793548584 10 runs without this enabled: -- Run #0 time: 2.127584457397461 -- Run #1 time: 2.066192865371704 -- Run #2 time: 2.0831892490386963 -- Run #3 time: 2.077716588973999 -- Run #4 time: 2.07608962059021 -- Run #5 time: 2.072899341583252 -- Run #6 time: 2.094369888305664 -- Run #7 time: 2.067504644393921 -- Run #8 time: 2.069610834121704 -- Run #9 time: 2.0567898750305176 Differential Revision: https://phab.mercurial-scm.org/D9294

tests: use `testrepohg` in one more place in test-check-code.t This is already used elsewhere in the test to access the current hg repo, and avoids an error about the unknown `revlog-compression-zstd` when C extensions aren't built. The only other such error is in test-check-interfaces.py, but I don't see a way to avoid it other than to create an empty scratch repo. Differential Revision: https://phab.mercurial-scm.org/D9364

setup: copy pythonXY.dll next to the hg.exe wrapper when building This avoids the problem of having the newly built binary complaining that it can't find the DLL. There is an option in the python.org installer to add the python install to PATH (which defaulted to "on" with py2, and therefore was not an issue up to this point), but that makes switching between python versions harder. This shouldn't be an issue with the PyOxidizer binary, but that current has issues running some of the tests, and took noticeably longer to build last time I tried it. Differential Revision: https://phab.mercurial-scm.org/D9362

exthelper: update the examples to be python3 complaint Differential Revision: https://phab.mercurial-scm.org/D9368