interactive: do not prompt about files given in command line For commit and revert commands with --interactive and explicit files given in the command line, we now skip the invite to "examine changes to <file> ? [Ynesfdaq?]". The reason for this is that, if <file> is specified by the user, asking for confirmation is redundant. In patch.filterpatch(), we now use an optional "match" argument to conditionally call the prompt() function when entering a new "header" item. We use .exact() method to compare with files from the "header" in order to only consider (rel)path patterns. Add tests with glob patterns for commit and revert, to make sure we still ask to examine files in these cases.

zstandard: vendor python-zstandard 0.11 The upstream source distribution from PyPI was extracted. Unwanted files were removed. The clang-format ignore list was updated to reflect the new source of files. The project contains a vendored copy of zstandard 1.3.8. The old version was 1.3.6. This should result in some minor performance wins. test-check-py3-compat.t was updated to reflect now-passing tests on Python 3.8. Some HTTP tests were updated to reflect new zstd compression output. # no-check-commit because 3rd party code has different style guidelines Differential Revision: https://phab.mercurial-scm.org/D6199

cext: make osutil.c PY_SSIZE_T_CLEAN This is needed to avoid a deprecation warning on Python 3.8. With this change, we no longer see deprecation warnings for this issue on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D6198

cext: make parsers.c PY_SSIZE_T_CLEAN This is needed to avoid a deprecation warning in Python 3.8. I believe the conversion of int to Py_ssize_t is harmless in the changed locations. But this being C code, it should be audited with care. Differential Revision: https://phab.mercurial-scm.org/D6197

cext: make revlog.c PY_SSIZE_T_CLEAN Without this, Python 3.8 emits a deprecation warning, as using int for # values is deprecated. Many existing modules use PY_SSIZE_T_CLEAN, so this shouldn't be contentious. I audited the file for all # formatters and verified we are using Py_ssize_t everywhere now. Differential Revision: https://phab.mercurial-scm.org/D6196

tests: add optional output for Python 2.7 deprecation We already had one of these a few lines above. We need it here as well. Differential Revision: https://phab.mercurial-scm.org/D6203

setup: use raw string for regular expression Otherwise Python 3.8 complains about the backslash. Differential Revision: https://phab.mercurial-scm.org/D6202

automation: use raw strings when there are backslashes Otherwise Python 3.8 complains. Differential Revision: https://phab.mercurial-scm.org/D6201

perf: make perf.run-limits code work with Python 3 We need b'' because perf.py isn't run through the source transformer. We need to cast the exception to bytes using pycompat.bytestr() because ValueError can't be %s formatted due to built-in exceptions lacking __bytes__. We need to pycompat.sysstr() before the float() and int() cast so the ValueError message doesn't have b'' in it. Even with that, it looks like the error message for the ValueError for float casts added quotes, so we need to account for that in test output. Differential Revision: https://phab.mercurial-scm.org/D6200

localrepo: rename crev in _filecommit() to cnode, since it's a node I know we often use "rev" generically, but here's it always a node, so it helps to be specific. Differential Revision: https://phab.mercurial-scm.org/D6181

tests: unset environment variable P in test-revset2.t (issue6109) The test tests/test-revset2.t fails the test case "Test repo.anyrevs with customized revset overrides" (line 1609) if the environment variable P is set. The test implicitly expects that the environment, in which it is started, does not export the variable 'P'. To solve this issue, unset 'P' right before the test commands are run. Differential Revision: https://phab.mercurial-scm.org/D6195

hgmanpage: use a py2 and py3 compatible iterable protocol

hgmanpage: use range instead of xrange

packaging: allow to run make with python3 Use "?=", otherwise the variable cannot be set from environment.

cleanup: use set literals where possible Differential Revision: https://phab.mercurial-scm.org/D6192

tests: rename "u" to more usual "ui" in test-context.py Differential Revision: https://phab.mercurial-scm.org/D6191

tests: better document the graft copy case Differential Revision: https://phab.mercurial-scm.org/D6190

py2exe: add workaround to allow bundling of hgext3rd.* extensions py2exe doesn't know how to handle namespace packages *at all*, so it treats them like normal packages. As a result, if we try and bundle hgext3rd.evolve in a py2exe build, it won't work if we install evolve into the virtualenv. In order to work around this, tortoisehg installs hgext3rd.evolve etc into its staged hg directory, since it doesn't use a virtualenv. As a workaround for us, we'll just allow any extra packages users want bundled are part of hg during the pseudo-install phase that py2exe uses. I'm not happy about this, but it *works*. As a sample of how you'd make an MSI with evolve bundled: import os import shutil import subprocess import tempfile def stage_evolve(version): """Stage evolve for inclusion in py2exe binary.""" with tempfile.TemporaryDirectory() as temp: evolve = os.path.join(temp, "evolve") subprocess.check_call([ "hg.exe", "clone", "https://www.mercurial-scm.org/repo/evolve/", "--update", version, evolve, ]) dest = os.path.join('..', 'hgext3rd', 'evolve') if os.path.exists(dest): shutil.rmtree(dest) shutil.copytree(os.path.join(evolve, "hgext3rd", "evolve"), dest) def main(): stage_evolve('tip') print("\0") print("hgext3rd") print("hgext3rd.evolve") print("hgext3rd.evolve.hack") print("hgext3rd.evolve.thirdparty") if __name__ == "__main__": main() is a script you can pass to the wix/build.py as --extra-packages-script, and the resulting .msi will have an hg binary with evolve baked in. users will still need to enable evolve in their hgrc, so you'd probably also want to bundle configs in your msi for an enterprise environment, but that's already easy to do with the support for extra features and wxs files in the wix build process. Differential Revision: https://phab.mercurial-scm.org/D6189

wix: fix the package build when not adding features Should have used ifdef, not if. Sigh. Differential Revision: https://phab.mercurial-scm.org/D6187

histedit: narrow the scope of discarded ui output In 34165875fa5df813bec3a0cd348932b304d44efb, a lot of the output from histedit was excluded. This slightly adjusts the scope of that exclusion, to both discard more uninsteresting messages, and ensure that pre-merge-tool output gets shown before the external merge tool is executed. Differential Revision: https://phab.mercurial-scm.org/D6177

uncommit: abort if an explicitly given file cannot be uncommitted (BC) I've gotten burned several times by this in the last few days. The former tests look simple enough, but if a good file and a bad file are given, the bad files are silently ignored. Some commands like `forget` will warn about bogus files, but that would likely get lost in the noise of an interactive uncommit. The commit command aborts if a bad file is given, so this seems more consistent for commands that alter the repository.

unshelve: disable unshelve during merge (issue5123) As stated in the issue5123, unshelve can destroy the second parent of the context when tried to unshelve with an uncommitted merge. This patch makes unshelve to abort when called with an uncommitted merge. See how shelve.mergefiles works. Commit structure looks like this: ``` ... -> pctx -> tmpwctx -> shelvectx / / second merge parent pctx = parent before merging working context(first merge parent) tmpwctx = commited working directory after merge(with two parents) shelvectx = shelved context ``` shelve.mergefiles first updates to pctx then it reverts shelvectx to pctx with: ``` cmdutil.revert(ui, repo, shelvectx, repo.dirstate.parents(), *pathtofiles(repo, files), **{'no_backup': True}) ``` Reverting tmpwctx files that were merged from second parent to pctx makes them added because they are not in pctx. Changing this revert operation is crucial to restore parents after unshelve. This is a complicated issue as this is not fixing a regression. Thus, for the time being, unshelve during an uncommitted merge can be aborted. (Details taken from http://mercurial.808500.n3.nabble.com/PATCH-V3-shelve-restore-parents-after-unshelve-issue5123-tt4036858.html#a4037408) Differential Revision: https://phab.mercurial-scm.org/D6169

wix: add functionality to inject additional Features into installer This is the last bit required to be able to glue extra configs etc into the installer. Differential Revision: https://phab.mercurial-scm.org/D6180

wix: add support for additional wxs files As with my previous change for an --extra-prebuiild-script, I'm assuming this is predominantly useful in an enterprise environment and am only adding this to wix and not also to inno install scripts. Differential Revision: https://phab.mercurial-scm.org/D6179

wix: add a hook for a prebuild script to inject extra libraries I need this to build packages for Google so we can bundle some extensions in the installed image. My assumption is that this is most interesting for the .msi images so I only wired it up there. I'm not thrilled with the interface this provides, but it was an easy way to retain debug messages on Windows while also having enough structure to know what lines are actually module names for py2exe. Still pending on my end: I need to bundle a couple of config files, and at least one data file. I'm open to advice on how to do those things, and how to do this better. Differential Revision: https://phab.mercurial-scm.org/D6164

compression: introduce an official `format.revlog-compression` option This option supersedes the `experiment.format.compression` option. The value currently supported are zlib (default) and zstd (if Mercurial was compiled with zstd support). The option gained an explicit reference to `revlog` since this is the target usage here. Different storage methods might require different compression strategies. In our tests, using zstd give a significant CPU usage improvement (both compression and decompressing) while keeping similar repository size. Zstd as other interresting mode (dictionnary, pre-text, etc…) that are probably worth exploring. However, just plain switching from zlib to zstd provide a large benefit.

compression: display compression level in debugformat Now that we have options to control the compression level, we teach `hg debugformat` about them. This is a useful information when comparing repositories. Note that we have no trace of the compression level used to store existing deltas. Actually, it would even varies from one delta to another. So we display the currently set value.

compression: introduce a `storage.revlog.zstd.level` configuration This option control the zstd compression level used when compressing revlog chunk. The usage of zstd for revlog compression has not graduated from experimental yet, but we intend to fix that soon. The option name for the compression level is more straight forward to pick, so this changesets comes first. Having a dedicated option for each compression engine is useful because they don't support the same range of values. I ran the same measurement as for the zlib compression level (in the parent changesets). The variation in repository size is stay mostly in the same (small) range. The "read/write" performance see smallish variation, but are overall much better than zlib. Write performance show the same tend of having better write performance for when reaching high-end compression. Again, we don't intend to change the default zstd compression level (currently: 3) in this series. However this is worth investigating in the future. The Performance comparison of zlib vs zstd is quite impressive. The repository size stay in the same range, but the performance are much better in all situations. Comparison summary ================== We are looking at: - performance range for zlib - performance range for zstd - comparison of default zstd (level-3) to default zlib (level 6) - comparison of the slowest zstd time to the fastest zlib time Read performance: ----------------- | zlib | zstd | cmp | f2s mercurial | 0.170159 - 0.189219 | 0.144127 - 0.149624 | 80% | 88% pypy | 2.679217 - 2.768691 | 1.532317 - 1.705044 | 60% | 63% netbeans | 122.477027 - 141.620281 | 72.996346 - 89.731560 | 58% | 73% mozilla | 147.867662 - 170.572118 | 91.700995 - 105.853099 | 56% | 71% Write performance: ------------------ | zlib | zstd | cmp | f2s mercurial | 53.250304 - 56.2936129 | 40.877025 - 45.677286 | 75% | 86% pypy | 460.721984 - 476.589918 | 270.545409 - 301.002219 | 63% | 65% netbeans | 520.560316 - 715.930400 | 370.356311 - 428.329652 | 55% | 82% mozilla | 739.803002 - 987.056093 | 505.152906 - 591.930683 | 57% | 80% Raw data -------- repo alg lvl .hg/store size 00manifest.d read write mercurial zlib 1 49,402,813 5,963,475 0.170159 53.250304 mercurial zlib 6 47,197,397 5,875,730 0.182820 56.264320 mercurial zlib 9 47,121,596 5,849,781 0.189219 56.293612 mercurial zstd 1 49,737,084 5,966,355 0.144127 40.877025 mercurial zstd 3 48,961,867 5,895,208 0.146376 42.268142 mercurial zstd 5 48,200,592 5,938,676 0.149624 43.162875 mercurial zstd 10 47,833,520 5,913,353 0.145185 44.012489 mercurial zstd 15 47,314,604 5,728,679 0.147686 45.677286 mercurial zstd 20 47,330,502 5,830,539 0.145789 45.025407 mercurial zstd 22 47,330,076 5,830,539 0.143996 44.690460 pypy zlib 1 370,830,572 28,462,425 2.679217 460.721984 pypy zlib 6 340,112,317 27,648,747 2.768691 467.537158 pypy zlib 9 338,360,736 27,639,003 2.763495 476.589918 pypy zstd 1 362,377,479 27,916,214 1.532317 270.545409 pypy zstd 3 354,137,693 27,905,988 1.686718 294.951509 pypy zstd 5 342,640,043 27,655,774 1.705044 301.002219 pypy zstd 10 334,224,327 27,164,493 1.567287 285.186239 pypy zstd 15 329,000,363 26,645,965 1.637729 299.561332 pypy zstd 20 324,534,039 26,199,547 1.526813 302.149827 pypy zstd 22 324,530,595 26,198,932 1.525718 307.821218 netbeans zlib 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans zlib 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans zlib 9 1,197,135,671 155,034,586 141.620281 678.297064 netbeans zstd 1 1,259,581,737 160,840,613 72.996346 370.356311 netbeans zstd 3 1,232,978,122 157,691,551 81.622317 396.733087 netbeans zstd 5 1,208,034,075 160,246,880 83.080549 364.342626 netbeans zstd 10 1,188,624,176 156,083,417 79.323935 403.594602 netbeans zstd 15 1,176,973,589 153,859,477 89.731560 428.329652 netbeans zstd 20 1,162,958,258 151,147,535 82.842667 392.335349 netbeans zstd 22 1,162,707,029 151,150,220 82.565695 402.840655 mozilla zlib 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla zlib 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla zlib 9 2,587,542,494 287,018,264 163.622338 739.803002 mozilla zstd 1 2,723,159,348 286,617,532 91.700995 570.042751 mozilla zstd 3 2,665,055,001 286,152,013 95.240155 561.412805 mozilla zstd 5 2,607,819,817 288,060,030 101.978048 505.152906 mozilla zstd 10 2,558,761,085 283,967,648 104.113481 497.771202 mozilla zstd 15 2,526,216,060 275,581,300 105.853099 591.930683 mozilla zstd 20 2,485,114,806 266,478,859 95.268795 576.515389 mozilla zstd 22 2,484,869,080 266,456,505 94.429282 572.785537

compression: introduce a `storage.revlog.zlib.level` configuration This option control the zlib compression level used when compression revlog chunk. This is also a good excuse to pave the way for a similar configuration option for the zstd compression engine. Having a dedicated option for each compression algorithm is useful because they don't support the same range of values. Using a higher zlib compression impact CPU consumption at compression time, but does not directly affected decompression time. However dealing with small compressed chunk can directly help decompression and indirectly help other revlog logic. I ran some basic test on repositories using different level. I am using the mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite. All tested repository use sparse-revlog and got all their delta recomputed. The different compression level has a small effect on the repository size (about 10% variation in the total range). My quick analysis is that revlog mostly store small delta, that are not affected by the compression level much. So the variation probably mostly comes from better compression of the snapshots revisions, and snapshot revision only represent a small portion of the repository content. I also made some basic timings measurements. The "read" timings are gathered using simple run of `hg perfrevlogrevisions`, the "write" timings using `hg perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and mozilla central). The timings are gathered on a generic machine, (not one of our performance locked machine), so small variation might not be meaningful. However large trend remains relevant. Keep in mind that these numbers are not pure compression/decompression time. They also involve the full revlog logic. In particular the difference in chunk size has an impact on the delta chain structure, affecting performance when writing or reading them. On read/write performance, the compression level has a bigger impact. Counter-intuitively, the higher compression levels improve "write" performance for the large repositories in our tested setting. Maybe because the last 5000 delta chain end up having a very different shape in this specific spot? Or maybe because of a more general trend of better delta chains thanks to the smaller chunk and snapshot. This series does not intend to change the default compression level. However, these result call for a deeper analysis of this performance difference in the future. Full data ========= repo level .hg/store size 00manifest.d read write ---------------------------------------------------------------- mercurial 1 49,402,813 5,963,475 0.170159 53.250304 mercurial 6 47,197,397 5,875,730 0.182820 56.264320 mercurial 9 47,121,596 5,849,781 0.189219 56.293612 pypy 1 370,830,572 28,462,425 2.679217 460.721984 pypy 6 340,112,317 27,648,747 2.768691 467.537158 pypy 9 338,360,736 27,639,003 2.763495 476.589918 netbeans 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans 9 1,197,135,671 155,034,586 141.620281 678.297064 mozilla 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla 9 2,587,542,494 287,018,264 163.622338 739.803002

compression: accept level management for zlib compression We update the zlib related class to be support setting the compression level. This changeset focus on updating the internal only. A way to configure this level will be introduced in the next changeset.