copies: use the rust code for `combine_changeset_copies` Changeset centric copy tracing now use the rust code. The rust code focussed on simplicity and will be optimised later. So the performance is not great yet. Now that all the pieces are in place we can start working on performance in the coming changesets. Below is a table that summarize how slower we got: Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000049 s, 0.000046 s, -0.000003 s, × 0.9388 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000112 s, 0.000173 s, +0.000061 s, × 1.5446 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.004216 s, 0.006303 s, +0.002087 s, × 1.4950 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000204 s, 0.000229 s, +0.000025 s, × 1.1225 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000058 s, 0.000056 s, -0.000002 s, × 0.9655 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000112 s, 0.000143 s, +0.000031 s, × 1.2768 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.000339 s, 0.001166 s, +0.000827 s, × 3.4395 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.010214 s, 0.022931 s, +0.012717 s, × 2.2451 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.047497 s, 0.852446 s, +0.804949 s, × 17.9474 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.075297 s, 2.221824 s, +2.146527 s, × 29.5075 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.057322 s, 1.194162 s, +1.136840 s, × 20.8325 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.796264 s, 62.468362 s, +61.672098 s, × 78.4518 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.020491 s, 0.022116 s, +0.001625 s, × 1.0793 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.121612 s, 2.972788 s, +2.851176 s, × 24.4449 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000143 s, 0.000180 s, +0.000037 s, × 1.2587 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000112 s, 0.000123 s, +0.000011 s, × 1.0982 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000232 s, 0.000315 s, +0.000083 s, × 1.3578 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.000721 s, 0.001297 s, +0.000576 s, × 1.7989 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.010115 s, 0.024884 s, +0.014769 s, × 2.4601 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.015461 s, 0.032653 s, +0.017192 s, × 2.1120 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.060756 s, 4.230118 s, +4.169362 s, × 69.6247 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 0.605842 s, killed mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000164 s, 0.000197 s, +0.000033 s, × 1.2012 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000331 s, 0.000622 s, +0.000291 s, × 1.8792 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000249 s, 0.000296 s, +0.000047 s, × 1.1888 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.000711 s, 0.001626 s, +0.000915 s, × 2.2869 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.003438 s, 0.006218 s, +0.002780 s, × 1.8086 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.069869 s, 0.132760 s, +0.062891 s, × 1.9001 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.005701 s, 0.029001 s, +0.023300 s, × 5.0870 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.005757 s, 0.005886 s, +0.000129 s, × 1.0224 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.061826 s, 3.619850 s, +3.558024 s, × 58.5490 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.043354 s, 0.058678 s, +0.015324 s, × 1.3535 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.198979 s, 11.926587 s, +11.727608 s, × 59.9389 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 2.067096 s, killed mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 3.102616 s, killed mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001212 s, 0.001204 s, -0.000008 s, × 0.9934 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001237 s, 0.001217 s, -0.000020 s, × 0.9838 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000557 s, 0.000605 s, +0.000048 s, × 1.0862 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001532 s, 0.001876 s, +0.000344 s, × 1.2245 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.035166 s, 0.078190 s, +0.043024 s, × 2.2235 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.070336 s, 0.135428 s, +0.065092 s, × 1.9254 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.006080 s, 0.029123 s, +0.023043 s, × 4.7900 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.006099 s, 0.006141 s, +0.000042 s, × 1.0069 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.064317 s, 4.857827 s, +4.793510 s, × 75.5294 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.303263 s, 10.674920 s, +10.371657 s, × 35.2002 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.292804 s, 9.789462 s, +9.496658 s, × 33.4335 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.107594 s, 1.087890 s, +0.980296 s, × 10.1111 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.045202 s, 0.060556 s, +0.015354 s, × 1.3397 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 1.926277 s, killed mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 0.794492 s, killed mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 84.521497 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 0.965937 s, 19.647038 s, +18.681101 s, × 20.3399 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 83.367146 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 84.260895 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 3.274537 s, killed mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 42.235843 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 49.872829 s, killed Differential Revision: https://phab.mercurial-scm.org/D9299

tests: simplify and extend pull-bundle test using debugbuilddag Differential Revision: https://phab.mercurial-scm.org/D9443

helptext: document the mechanism for extensions to report a version Differential Revision: https://phab.mercurial-scm.org/D9448

heptapod-ci: add a explicite "test" phases We are about to add more stage Differential Revision: https://phab.mercurial-scm.org/D9454

test: fix some expect output in a traceback The lines moved around because of 89a2afe31e82. Differential Revision: https://phab.mercurial-scm.org/D9447

help: fix a grammar/typo in hg help dates Differential Revision: https://phab.mercurial-scm.org/D9442

rust: fix non-utf8 char in requirements.rs Apparently Phabricator detect `rust/hg-core/src/requirements.rs` file as non utf8 ‽, and mark it as binary. During application it ended up being non-utf8 and this made Rust (and as a result heptapod) very angry:: error: couldn't read hg-core/src/requirements.rs: stream did not contain valid UTF-8 --> hg-core/src/lib.rs:11:9 | 11 | pub mod requirements; | ^^^^^^^^^^^^ error: aborting due to previous error error: could not compile `hg-core`. The after "fixing", the file content has no character matching the following regexp: [^0-9-a-zA-Z /(|).,{}!\[\]:"&=>?_*-;<`'#] So we should be fine, unless Phabricator does something funny again. Differential Revision: https://phab.mercurial-scm.org/D9444

run-tests: use a context manager when looking for available ports Differential Revision: https://phab.mercurial-scm.org/D9441 Differential Revision: https://phab.mercurial-scm.org/D9452

dispatch: print the version of each extension in the bug report, if available Sometimes the wrong extensions is blamed, so we might as well print the version info for all of them. Additionally, since the internal extensions are never blamed, this is a good way to make the pygit2 version available in a bug report. Differential Revision: https://phab.mercurial-scm.org/D9440

dispatch: sort the loaded extension names in the bug report This makes a long list of extensions easier to read. On very rare occasion I've seen issues where the load order mattered, however that info should still be obtainable with `hg config extensions`. Differential Revision: https://phab.mercurial-scm.org/D9439

dispatch: quote the extension when printing the bug report I think this reads better in the wall of text. Differential Revision: https://phab.mercurial-scm.org/D9438

dispatch: print the version of the extension being blamed in a bug report I don't know of a lot of extensions using this, but it seems like useful info in a bug report. Differential Revision: https://phab.mercurial-scm.org/D9437

git: show the version of `pygit2` with verbose version output This seems like useful info to have when debugging. I followed the precedent of hg-git, which prints something like: hggit external 0.9.0a1 (dulwich 0.19.15) We don't have a version number assigned (because it's internal), so it's just the parenthetical. Differential Revision: https://phab.mercurial-scm.org/D9436

git: add the standard `testedwith` attribute Otherwise this shows up as an external extension. Differential Revision: https://phab.mercurial-scm.org/D9435

tests: add a comment that we're purposely testing py2 extension attributes Avoid someone unknowingly removing test coverage. There are tests for a properly byteified `testedwith` a few lines down. I don't see similar for `buglink`, but it's a trivial conversion to bytes, so I'm not concerned about testing the expected/wanted extension state. Differential Revision: https://phab.mercurial-scm.org/D9434

extensions: avoid a crash when the version isn't properly byteified on py3 We already force bytestr on the `testedwith` and `buglink` attributes in dispatch.py when generating a bug report with a similar comment about not every extension being ported to py3. We should do the same here, so the function can be properly typed. Differential Revision: https://phab.mercurial-scm.org/D9433

formatting: drop a few extra double quotes in docstrings These were made obvious by the reformatting in D9430. Differential Revision: https://phab.mercurial-scm.org/D9432

copies: introduce the hg-cpython wrapper for `combine_changeset_copies` This patch focus on the `hg-cpython` part of this work. Bridging the python code with the new rust code in `hg-core`. The next patch will actually plug this in the python code. The rust code use multiple Python callback, python related error within this callback are not expected unless they are a programming error or a data corruption. In addition, these callback will slowly be replaced by native Rust code. For these reasons, we use will deal with unexpected error within this callback using rust Panic and let the `rust-cpython` layer deal with raising a Python exception. The code dealing with the ChangedFile instance is repeating itself a lot. I did not factor these duplication out because that whole code will get replaced by entirely different one in a handful of changesets. Differential Revision: https://phab.mercurial-scm.org/D9298

copies: introduce a basic Rust function for `combine_changeset_copies` This new function mirror the python code. This first implementation does a lot of data copies and is therefore quite slow. However my goal here is to create a simple "frame" from where to start adding optimization. This patch focus on the `hg-core` part of this work. Coming patches will do the necessary `hg-cpython` work to be able to use this from Python. Differential Revision: https://phab.mercurial-scm.org/D9297

hghave: adjust the detection of `pylint` for modern versions I have pylint 2.6.0 installed locally, and it only has a single space. I have no idea when this changed. Differential Revision: https://phab.mercurial-scm.org/D9431

formating: upgrade to black 20.8b1 This required a couple of small tweaks to un-confuse black, but now it works. Big formatting changes come from: * Dramatically improved collection-splitting logic upstream * Black having a strong (correct IMO) opinion that """ is better than ''' Differential Revision: https://phab.mercurial-scm.org/D9430

osutil: reformat triple-quoted string so black doesn't confuse itself Differential Revision: https://phab.mercurial-scm.org/D9429

merge: remove spurious ' and trailing whitespace from triple-quoted string Differential Revision: https://phab.mercurial-scm.org/D9428

cleanup: fix a few recent black formatting violations Differential Revision: https://phab.mercurial-scm.org/D9427

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

helptext: byteify extensions examples Make it easier on the copy/paste crowd. I haven't looked at the other help text to see if there are other instances; I was just looking to confirm `buglink` is meant to be bytes and this popped up along with the code. Differential Revision: https://phab.mercurial-scm.org/D9367

helptext: fix sentence in extensions documentation Differential Revision: https://phab.mercurial-scm.org/D9366

ui: ensure `getpass()` returns bytes Previously, this could return either bytes or str. I'm not sure which direction we should go in, but since the input is bytes, I guess bytes makes sense as output. `debuguigetpass` crashed because it assumed bytes would be returned, `sslcontext.load_cert_chain()` is happy with bytes or str if the type info in PyCharm is correct, and `smtplib.SMTP.login()` wants str. I couldn't figure out how to test this, because the test stalls for input with `echo test | hg debuguigetpass --config ui.interactive=1`, likely because it drains stdin before prompting. The custom input reading with `ui.nontty=1` does not. I'm also a bit concerned with all of this encoding/decoding. The existing code in the mail module uses `encoding.strfromlocal()`, but the username and password are ascii encoded/decoded in `mercurial.url.passwordmgr.find_user_password()` with `pycompat.{str,bytes}url()`. I'm not sure if this inconsistency could cause subtle compatability issues. Differential Revision: https://phab.mercurial-scm.org/D9375

packaging: regenerate the Windows requirements manifest on Windows SecretStorage is a Linux package, and the other stuff removed is a dependency of it. I assume this was last generated on Linux, and noticed this trying to add another package and regenerating on Windows. Differential Revision: https://phab.mercurial-scm.org/D9404

pyoxidizer: point to the py3 requirements instead of py2 on Windows Differential Revision: https://phab.mercurial-scm.org/D9406

git: update test for hg and git output changes Clearly nobody is running this in their CI. :( Differential Revision: https://phab.mercurial-scm.org/D9403

gitlog: add tiprev() function Lots of stuff was broken because this was missing. Differential Revision: https://phab.mercurial-scm.org/D9402

requirements: move loading to hg-core and add parsing No functional change, checking comes later. Differential Revision: https://phab.mercurial-scm.org/D9398

rhg: add a `debugrequirements` subcommand For now it only prints the contents of `.hg/requires` as-is, without parsing. Differential Revision: https://phab.mercurial-scm.org/D9397

pyoxidizer: make sure defaultrc directory exists before trying to write to it When doing some work involving one-file binaries, this line is failing for me. It seems reasonable to just make sure the destination directory exists before splatting the file into it. Differential Revision: https://phab.mercurial-scm.org/D9401

commands: fix checking of share safe requirement on `config --shared` The `if requirements.SHARESAFE_REQUIREMENT in ...` was wrongly placed inside another if statement which made the check unreachable. Differential Revision: https://phab.mercurial-scm.org/D9360

dispatch: pass root path in ui.readconfig() as root of main repo Since we are reading main (shared-source) repository config options, we should pass root as that repository root only. Differential Revision: https://phab.mercurial-scm.org/D9359

scmutil: try-delete `.hg/store/requires` if store requirements are empty When downgrading from a shared-safe repository to non-shared-safe repository, we end up in a case where we had requirements stored in `.hg/store/requires` but no longer want them there. Let's explicitly try delete the `.hg/store/requires` file if store requirements are empty. Differential Revision: https://phab.mercurial-scm.org/D9357

errors: raise InputError on bad top-level flags Differential Revision: https://phab.mercurial-scm.org/D9388

errors: raise StateError on uncommitted changes when merge starts Differential Revision: https://phab.mercurial-scm.org/D9393

errors: raise StateError when there are unresolves merge conflicts Differential Revision: https://phab.mercurial-scm.org/D9392

errors: introduce SecurityError and use it in a few places This is part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. There are perhaps more errors in `sslutil.py` that should raise `SecurityError`; I picked the most clear ones to start with. Differential Revision: https://phab.mercurial-scm.org/D9390

errors: raise InputError when too few arguments given to alias Differential Revision: https://phab.mercurial-scm.org/D9389

errors: raise InputError on bad bookmark argument Differential Revision: https://phab.mercurial-scm.org/D9385

errors: raise ConfigError on bad alias definition Differential Revision: https://phab.mercurial-scm.org/D9384

errors: raise InputError on bad repo arguments I'm not sure if one of these should be StateError... Differential Revision: https://phab.mercurial-scm.org/D9383

errors: drop trailing "!" for some errors about bookmarks Differential Revision: https://phab.mercurial-scm.org/D9382

errors: remove trailing "!" in messages about bad top-level args Differential Revision: https://phab.mercurial-scm.org/D9381

errors: remove trailing "!" in messages about creating new heads on push Differential Revision: https://phab.mercurial-scm.org/D9380

errors: consistently don't use trailing "!" in "not found in manifest" message We already had some places with the same message without the trailing "!". Differential Revision: https://phab.mercurial-scm.org/D9379

errors: remove trailing "!" from some error messages for consistency Some types of exceptions had a trailing "!" printed after the message from the exception itself. I guess some of these errors seem a little more severe (?), but it seems more likely that the inconsistency was just an oversight. Differential Revision: https://phab.mercurial-scm.org/D9378

bisect: use tuple literal instead of split on string literal Differential Revision: https://phab.mercurial-scm.org/D9371

hgignore: add VS Code config Differential Revision: https://phab.mercurial-scm.org/D9370

tests: make test-worker.t pass on py2 I broke the py2 version in https://phab.mercurial-scm.org/D9287 because the `WorkerError.__bytes__()` (or `.__str__()`?) output was different in py2 compared to py3. Part of the problem was that I didn't propagate the status code that was passed in to the superclass so it could get printed. This patch fixes that. I don't know how it worked on py3 before this patch... I also added the usual `__bytes__ = _tobytes` override for good measure. It doesn't seem to be needed for tests to pass, though. Differential Revision: https://phab.mercurial-scm.org/D9377

tests: update test-https.t's #no-defaultcacertsloaded block with new exit code I'm pretty sure I broke this in https://phab.mercurial-scm.org/D9309. It was reported by the Heptapod CI. Differential Revision: https://phab.mercurial-scm.org/D9376

chg: fix test-check-clang-format.t failure Differential Revision: https://phab.mercurial-scm.org/D9365

log: add bookmark option to "hg log" Before pushing a bookmark with "hg push origin -B 'my-topic'", it is useful to inspect the list of commits that are ancestors of the bookmark. By relying on scmutil.bookmarkrevs(), "hg log -B topic" has the same bookmark semantics found in other commands like hg export, hg email, hg strip. Differential Revision: https://phab.mercurial-scm.org/D9341

extensions: gracefully warn when doing min version check with no local version After doing a `make clean`, I started getting cryptic failures to import extensions with the `minimumhgversion` attribute on py3: *** failed to import extension evolve: '>' not supported between instances of 'int' and 'NoneType' *** failed to import extension topic: '>' not supported between instances of 'int' and 'NoneType' This now handles the `(None, None)` tuple before comparing, and disables the extension with the same friendly message as in py2. Differential Revision: https://phab.mercurial-scm.org/D9363

make: switch the PYTHON default to `py.exe -3` on Windows Python3 _is_ named `python.exe` on Windows, but that isn't necessarily on PATH when installing from python.org. I do happen to have a python.exe on PATH in `$LOCALAPPDATA/Microsoft/WindowsApps`, but it appears to be 0 bytes (likely because of permission issues), and doesn't run: $ python -V - Cannot open Pulkit hit the same error as I did though, so it isn't just my system: $ make -C . local make: Entering directory `/home/Dell/repos/hg-committed` python setup.py \ build_py -c -d . \ build_ext -i \ build_hgexe -i \ build_mo - Cannot openmake: *** [local] Error 1 The `py.exe` dispatcher lives in the Windows directory (so it is on PATH), looks up the python.org installation, and invokes that interpreter directly. I get a warning with py39, but if it's our issue, it was an existing one: $ make -C .. local make: Entering directory `/c/Users/Matt/hg' py -3 setup.py \ build_py -c -d . \ build_ext -i \ build_hgexe -i \ build_mo C:\Users\Matt\AppData\Local\Programs\Python\Python39\lib\site-packages\setuptools\distutils_patch.py:25: UserWarning: Distutils was imported before Setuptools. This usage is discouraged and may exhibit undesirable behaviors or errors. Please use Setuptools' objects directly or at least import Setuptools first. warnings.warn( The end result is a py3 based hg.exe that annoyingly won't run because it can't find python39.dll. It will run tests (the ones without the `python3` shbang line anyway), because the test runner adjusts PATH to include the python running it. Differential Revision: https://phab.mercurial-scm.org/D9361

heptapod-ci: hosting base image on registry.heptapod.net We are now touching the rate limits of Docker Hub.

context: small update to ctx.status doc The order of the "arguments" were not too clear, so we update the documentation to clarify that.

errors: use exit code 10 for parse errors Now that `ParseError`s raised while reading the config file has been converted into `ConfigError`s, the remaining parse errors should all be "input errors" (i.e. exit code 10), according to https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9332

errors: raise ConfigError on failure to parse config file This replaces two raises of `ParseError` by `ConfigError`, which makes it so we get the desired exit code when `ui.detailed-exit-code` is enabled. Because the exceptions include a location, I had to add that to `ConfigError` as well. I considered making `ConfigError` a subclass of `ParseError`, but it doesn't feel like it quite passes the "is-a" test. I used "config error: " as prefix for these errors instead of the previous "hg: parse error: ", which seems a little less accurate now (and, as I've said before, I don't know what the "hg: " part is supposed to signify anyway). I can easily be convinced to change the prefix to something else (including "abort: "). Some of the exceptions raised here mean that we fail to even load the `ui` object in the `dispatch` module. When that happens, we don't know to use detailed exit codes, so some tests (e.g. `test-hgrc.t`) still see exit code 255. I'll try to get back to that later. It should be possible to give detailed exit codes if at least part of the config can be read (e.g. when the system-wide one enables detailed exit codes and the user's config fails to parse). Differential Revision: https://phab.mercurial-scm.org/D9355

histedit: don't crash if commit message is empty If the commit message is empty, histedit will crash before this patch because it assumes that `summary.splitlines()` is non-empty. One of our users at work ran into this crash for a commit that was created by an internal system. I don't think we have a good way of testing this because it's hard to create a commit with an empty commit message. I've added a comment to help prevent regressions. Differential Revision: https://phab.mercurial-scm.org/D9325

copies: cache the ancestor checking call when tracing copy A good share of the time spent in this function is spent doing ancestors checking. To avoid spending time in duplicated call, we cache the result of calls. In the slower case, this provide a quite significant performance boost. Below are the result for a set of selected pairs (many of them pathological): (And further down is another table that summarize the current state of filelog based vs changeset base copy tracing) The benchmark have been configured to be killed after 6 minutes of runtime, which mean that any detect slower than 2 minutes will be marked as "killed". This drop some useful information about how much slower these case are… but also prevent 99% of the benchmark time to be spent on case that can be labelled "very slow" anyway. Repo Case Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000044 s, 0.000044 s, +0.000000 s, × 1.0000 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000138 s, 0.000138 s, +0.000000 s, × 1.0000 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.005067 s, 0.005052 s, -0.000015 s, × 0.9970 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000218 s, 0.000219 s, +0.000001 s, × 1.0046 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000053 s, 0.000055 s, +0.000002 s, × 1.0377 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000125 s, 0.000128 s, +0.000003 s, × 1.0240 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001098 s, 0.001089 s, -0.000009 s, × 0.9918 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.017546 s, 0.017407 s, -0.000139 s, × 0.9921 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.096723 s, 0.094175 s, -0.002548 s, × 0.9737 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.271796 s, 0.238009 s, -0.033787 s, × 0.8757 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.128602 s, 0.125876 s, -0.002726 s, × 0.9788 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 7.086742 s, 3.581556 s, -3.505186 s, × 0.5054 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.016634 s, 0.016721 s, +0.000087 s, × 1.0052 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.254225 s, 0.242367 s, -0.011858 s, × 0.9534 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000166 s, 0.000165 s, -0.000001 s, × 0.9940 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000118 s, 0.000114 s, -0.000004 s, × 0.9661 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000296 s, 0.000296 s, +0.000000 s, × 1.0000 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001137 s, 0.001124 s, -0.000013 s, × 0.9886 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.014133 s, 0.013060 s, -0.001073 s, × 0.9241 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.016988 s, 0.017112 s, +0.000124 s, × 1.0073 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.676361 s, 0.660350 s, -0.016011 s, × 0.9763 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 12.515149 s, 10.032499 s, -2.482650 s, × 0.8016 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000186 s, 0.000189 s, +0.000003 s, × 1.0161 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000459 s, 0.000462 s, +0.000003 s, × 1.0065 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000273 s, 0.000270 s, -0.000003 s, × 0.9890 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001503 s, 0.001474 s, -0.000029 s, × 0.9807 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.004862 s, 0.004806 s, -0.000056 s, × 0.9885 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.088291 s, 0.085150 s, -0.003141 s, × 0.9644 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007113 s, 0.007064 s, -0.000049 s, × 0.9931 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004687 s, 0.004741 s, +0.000054 s, × 1.0115 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.198710 s, 0.190133 s, -0.008577 s, × 0.9568 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.036068 s, 0.035651 s, -0.000417 s, × 0.9884 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.465362 s, 0.440694 s, -0.024668 s, × 0.9470 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 24.519684 s, 18.454163 s, -6.065521 s, × 0.7526 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 42.711897 s, 31.562719 s, -11.149178 s, × 0.7390 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001201 s, 0.001189 s, -0.000012 s, × 0.9900 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001216 s, 0.001204 s, -0.000012 s, × 0.9901 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000595 s, 0.000586 s, -0.000009 s, × 0.9849 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001856 s, 0.001845 s, -0.000011 s, × 0.9941 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.064936 s, 0.063822 s, -0.001114 s, × 0.9828 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.090601 s, 0.088038 s, -0.002563 s, × 0.9717 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007510 s, 0.007389 s, -0.000121 s, × 0.9839 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004911 s, 0.004868 s, -0.000043 s, × 0.9912 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.233231 s, 0.222450 s, -0.010781 s, × 0.9538 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.419989 s, 0.370675 s, -0.049314 s, × 0.8826 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.401521 s, 0.358020 s, -0.043501 s, × 0.8917 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.179555 s, 0.145235 s, -0.034320 s, × 0.8089 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.038004 s, 0.037606 s, -0.000398 s, × 0.9895 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 52.838482 s, 7.382439 s, -45.456043 s, × 0.1397 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 8.705874 s, 7.273506 s, -1.432368 s, × 0.8355 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.126708 s, 1.074593 s, -0.052115 s, × 0.9537 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 83.854020 s, 27.746195 s, -56.107825 s, × 0.3309 Below is a table comparing the runtime of the current "filelog centric" algorithm, with the "changeset centric" one, we just modified. The changeset centric algorithm is a significant win in many scenario, but they are still various cases where it is quite slower. When many revision has to be considered the cost of retrieving the copy information, creating new dictionaries, merging dictionaries and checking if revision are ancestors of each other can slow things down. The rest of this series, will introduce a rust version of the copy tracing code to deal with most of theses issues. Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor --------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000914 s, 0.000044 s, - 0.000870 s, × 0.048140 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.001812 s, 0.000138 s, - 0.001674 s, × 0.076159 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.017954 s, 0.005052 s, - 0.012902 s, × 0.281386 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.001509 s, 0.000219 s, - 0.001290 s, × 0.145129 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.206881 s, 0.000055 s, - 0.206826 s, × 0.000266 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.016951 s, 0.000128 s, - 0.016823 s, × 0.007551 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.019096 s, 0.001089 s, - 0.018007 s, × 0.057028 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.762506 s, 0.017407 s, - 0.745099 s, × 0.022829 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 1.179211 s, 0.094175 s, - 1.085036 s, × 0.079863 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 1.249058 s, 0.238009 s, - 1.011049 s, × 0.190551 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 1.614107 s, 0.125876 s, - 1.488231 s, × 0.077985 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.001064 s, 3.581556 s, + 3.580492 s, × 3366.124060 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 1.061275 s, 0.016721 s, - 1.044554 s, × 0.015756 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.341119 s, 0.242367 s, - 1.098752 s, × 0.180720 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.027803 s, 0.000165 s, - 0.027638 s, × 0.005935 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.130014 s, 0.000114 s, - 0.129900 s, × 0.000877 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.024990 s, 0.000296 s, - 0.024694 s, × 0.011845 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.052201 s, 0.001124 s, - 0.051077 s, × 0.021532 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.037642 s, 0.013060 s, - 0.024582 s, × 0.346953 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.197086 s, 0.017112 s, - 0.179974 s, × 0.086825 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.935148 s, 0.660350 s, - 0.274798 s, × 0.706145 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 3.920674 s, 10.032499 s, + 6.111825 s, × 2.558871 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.024232 s, 0.000189 s, - 0.024043 s, × 0.007800 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.141483 s, 0.000462 s, - 0.141021 s, × 0.003265 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.025775 s, 0.000270 s, - 0.025505 s, × 0.010475 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.084922 s, 0.001474 s, - 0.083448 s, × 0.017357 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.194784 s, 0.004806 s, - 0.189978 s, × 0.024673 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.161103 s, 0.085150 s, - 2.075953 s, × 0.039401 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089347 s, 0.007064 s, - 0.082283 s, × 0.079063 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.732171 s, 0.004741 s, - 0.727430 s, × 0.006475 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 1.157287 s, 0.190133 s, - 0.967154 s, × 0.164292 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.726568 s, 0.035651 s, - 6.690917 s, × 0.005300 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 3.266229 s, 0.440694 s, - 2.825535 s, × 0.134924 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 15.860534 s, 18.454163 s, + 2.593629 s, × 1.163527 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 20.450475 s, 31.562719 s, +11.112244 s, × 1.543373 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.080442 s, 0.001189 s, - 0.079253 s, × 0.014781 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.497672 s, 0.001204 s, - 0.496468 s, × 0.002419 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.021183 s, 0.000586 s, - 0.020597 s, × 0.027664 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.230991 s, 0.001845 s, - 0.229146 s, × 0.007987 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1.118461 s, 0.063822 s, - 1.054639 s, × 0.057062 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.206083 s, 0.088038 s, - 2.118045 s, × 0.039907 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089404 s, 0.007389 s, - 0.082015 s, × 0.082647 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.733043 s, 0.004868 s, - 0.728175 s, × 0.006641 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 1.163367 s, 0.222450 s, - 0.940917 s, × 0.191212 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.085456 s, 0.370675 s, + 0.285219 s, × 4.337612 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.083601 s, 0.358020 s, + 0.274419 s, × 4.282485 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 7.366614 s, 0.145235 s, - 7.221379 s, × 0.019715 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.664464 s, 0.037606 s, - 6.626858 s, × 0.005643 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.467836 s, 7.382439 s, - 0.085397 s, × 0.988565 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 9.801294 s, 7.273506 s, - 2.527788 s, × 0.742097 mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 0.091886 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 26.491140 s, 1.074593 s, -25.416547 s, × 0.040564 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 0.092863 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 0.226823 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 18.914630 s, 27.746195 s, + 8.831565 s, × 1.466917 mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 21.198903 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 24.952268 s, killed Differential Revision: https://phab.mercurial-scm.org/D9296

errors: remove ParseError.args With the previous few patches, it is no longer needed (as far as the test suite can tell anyway). Differential Revision: https://phab.mercurial-scm.org/D9354

errors: let ParseError use Abort.__bytes__ The function is no longer used anywhere as far as our tests can tell, so there's no need to have a custom version of it. Differential Revision: https://phab.mercurial-scm.org/D9353

config: clean up message about ignored untrusted config The error message relied on Python's default formatting of arguments to an Exception's constructor. Let's try to make it a little more readable for users. Differential Revision: https://phab.mercurial-scm.org/D9352

tests: use new ParseError.format() in test-trusted.py Differential Revision: https://phab.mercurial-scm.org/D9351

errors: make ParseError a subtype of Abort I didn't plan this before, but the previous two changes made it really easy to make `ParseError` a subtype of `Abort`. It seems obvious with hindsight that I *should* have planned it :) Differential Revision: https://phab.mercurial-scm.org/D9350

tests: make doctests not depend on str(ParseError()) format `ParseError` implements `__bytes__`, but it doesn't implement `__str__`, so it gets the default `__str__` implementation. The next patch will make it so `ParseError` gets a `__str__` implementation, which changes the format slightly. This prepares by making us not depend on the format. Differential Revision: https://phab.mercurial-scm.org/D9349

errors: format "abort: " text in a new Abort.format() method This remove some duplication we had. Differential Revision: https://phab.mercurial-scm.org/D9348

errors: make formatparse() an instance method on ParseError It's just a little simpler this way. Don't ask me what the "hg: " prefix signifies to the user, I just left it as it was. I think we should consider changing the prefixes later (maybe always use "abort: ", or maybe use more specific prefixes in general). Differential Revision: https://phab.mercurial-scm.org/D9347

errors: create "similarity hint" for UnknownIdentifier eagerly in constructor No code wanted to do anything but to produce a hint from it anyway, so we might as well just store the hint in the exception (which already extended `Hint`). That way we can easily convert it to a `ConfigException` when it's parsing of configuration that fails. I was wondering if the purpose of lazily creating the string was so we don't create it in cases where it won't get printed anyway. However, I couldn't find any places where that could happen. If we do find such places, we could instead revert to making it lazy but add a function on `UnknownIdentifier` for creating the hint string. I dropped the comment saying "make sure to check fileset first, as revset can invoke fileset", which was added in 4e240d6ab898 (dispatch: offer near-edit-distance suggestions for {file,rev}set functions, 2015-01-26). I couldn't figure out what it meant. The author of that patch also did not remember the reason for it. Perhaps changes that have happened since then made it so it no longer matters. Differential Revision: https://phab.mercurial-scm.org/D9346

errors: move similarity_hint() to error module I want to be able to reuse it from `UnknownIdentifier`'s constructor. Moving it results in a new import of `difflib` in the `error` module. There was a comment at the top of `error.py` saying "Do not import anything but pycompat here, please", which was added (except for the "pycompat" bit) in 08cabecfa8a8 (errors: move revlog errors, 2009-01-11). I don't know the reason for the comment. I'm guessing the point was to not make the module depend on other Mercurial modules. If that was it, then importing `difflib` should be fine. Sorry about the churn (I moved this code from the `dispatch` module to the `scmutil` module very recently). Differential Revision: https://phab.mercurial-scm.org/D9345

errors: morph reportsimilar() into similarity_hint() The next step is to eagerly create the hint in `UnknownIdentifier`'s constructor. Differential Revision: https://phab.mercurial-scm.org/D9344

errors: restructure formatparse() to clarify conditions a bit The `similar` list will be calculated only for `error.UnknownIdentifier`. It was then printed only if `inst.location is None`, which is true for that exception type, but it's an indirect condition to rely on. Also, it looked from the code like it could both report similarities and print a hint. That would be a little awkward because the similarity report looks similar to the hint (both are printed within parentheses). I also added a `elif` to clarify that. I plan to refactor this more coming patches so the similarity report actually is a hint. Differential Revision: https://phab.mercurial-scm.org/D9343

pyoxidizer: run buildifier Differential Revision: https://phab.mercurial-scm.org/D9342

errors: raise InputError in `hg absorb` Differential Revision: https://phab.mercurial-scm.org/D9340

errors: introduce CanceledError and use it in a few places This very similar to earlier patches (e.g. for `InputError`) and part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9339

errors: raise InputError in `hg split` Differential Revision: https://phab.mercurial-scm.org/D9338

errors: raise StateError in `hg bisect` Differential Revision: https://phab.mercurial-scm.org/D9337

errors: raise InputError in `hg debugobsolete` Differential Revision: https://phab.mercurial-scm.org/D9336

errors: raise InputError when line range to followlines() is out of bounds Differential Revision: https://phab.mercurial-scm.org/D9333

transaction: split new files into a separate set Journal entries with size 0 are common as they represent new revlog files. Move them from the dictionary into a set as the former is more dense. This reduces peak RSS by 70MB for the NetBSD test repository with around 450k files under .hg/store. Differential Revision: https://phab.mercurial-scm.org/D9278

transaction: change list of journal entries into a dictionary The transaction object used to keep a mapping table of path names to journal entries and a list of journal entries consisting of path and file offset to truncate on rollback. The offsets are used in three cases. repair.strip and rollback process all of them in one go, but they care about the order. For them, it is perfectly reasonable to read the journal back from disk as both operations already involve at least one system call per journal entry. The other consumer is the revlog logic for moving from inline to external data storage. It doesn't care about the order of the journal and just needs to original offset stored. Further optimisations are possible here to move the in-memory journal to a set(), but without memoisation of the original revlog size this could turn it into O(n^2) behavior in worst case when many revlogs need to migrated. Differential Revision: https://phab.mercurial-scm.org/D9277

transaction: rename find to findoffset and drop backup file support transaction.find used to support access to both the regular file and backup file list. They have different formats, so any consumer has to be aware of the difference alredy. There is no in-core consumer for the backup file access, so don't provide it. Differential Revision: https://phab.mercurial-scm.org/D9276

transaction: drop per-file extra data support At the moment, transactions support an optional extra data argument for all files to be stored in addition to the original offset. This is used in core only by the revlog inline to external data migration. It is used to memoize the number of revisions before the transaction. That number of can be computed during the walk easily, so drop the requirement. Differential Revision: https://phab.mercurial-scm.org/D9275

templates: define a {onelinesummary} keyword It is sometimes useful to be able to use the configured `command-template.oneline-summary` in higher-level templates. For example, I would like to use it in an internal template that lists commits in a "review unit" (kind of a pull request). This patch adds support for that. We may want to define a way of formatting a context using a command-specific override (from `command-templates.oneline-summary.<command>`), but that will have to be a template function instead. I don't plan to do that, but I'm mentioning it now in case reviewers would prefer that we use a no-arg function (i.e. `{onelinesummary()}`) already today to prepare for that. Differential Revision: https://phab.mercurial-scm.org/D9314

relnotes: document new [command-templates] section Differential Revision: https://phab.mercurial-scm.org/D9266

help: document the new [command-templates] config section Differential Revision: https://phab.mercurial-scm.org/D9265

strip: move into core As discussed at the 5.2 sprint, replace strip extension by a core command, debugstrip. Obviously, the extension stays for backwards compatibility. As an implementation note, I moved the strip file as is into core, which is not done elsewhere, AFAIK. I could have inlined it into debugcommands, but that doesn't sound great. Differential Revision: https://phab.mercurial-scm.org/D9285

revlog: pass sidedata argument to flagutil.processflagswrite() Bug found through pytype. Differential Revision: https://phab.mercurial-scm.org/D9280

pure: guard against empty blocks If blocks is empty, we append `None` to the returned list, which is incorrect. This subtle issue was caught by pytype, which correctly identified the return value as List[Optional[Tuple]] because of this possibility. Differential Revision: https://phab.mercurial-scm.org/D9279

rust-status: don't bubble up os errors, translate them to bad matches In the rare cases when either the OS/filesystem throws an error on an otherwise valid action, or because a path is not representable on the filesystem, or because of concurrent actions in the filesystem, we want to warn the user about said path instead of bubbling up the error, causing an exception to be raised in the Python layer. Differential Revision: https://phab.mercurial-scm.org/D9320

rust-status: properly translate OSError to Python This is probably never going to be called after the next few patches, but we might as well make sure this is done correctly for the future rewrite. Differential Revision: https://phab.mercurial-scm.org/D9319

shelve: clear merge state after partial shelve Differential Revision: https://phab.mercurial-scm.org/D9335

tests: show that interactive shelve can leave the repo with a merge state If part of a file is shelved (as we already do in a test), there will be an unfinished merge state left after `hg shelve` finishes. There should never be a merge conflict and there should never be a reason that the user would like to re-resolve conflicts, so we should clear that state (see next patch). Differential Revision: https://phab.mercurial-scm.org/D9334

histedit: disable color while rendering template for use in plan Differential Revision: https://phab.mercurial-scm.org/D9324

tests: show how `hg histedit` can put color codes in histedit plan Differential Revision: https://phab.mercurial-scm.org/D9323

split: disable color while rendering template for use in commit message Differential Revision: https://phab.mercurial-scm.org/D9322

tests: show how `hg split` can put color codes in commit template With D9255, I made it so `hg split` respects the `commmand-templates.oneline-summary` config. I don't think I realized that the output I modified was being put in a commit message template. The result was that if you have coloring enabled, you get colors in the commit template. This patch show that. The test is unfortunately pretty verbose (like most other `hg split` tests) and shows a bunch of irrelevant "color codes" (templater labels). Differential Revision: https://phab.mercurial-scm.org/D9321

dispatch: move some helper functions down into scmutil I plan to reuse `formatparse()` in the next patch. Differential Revision: https://phab.mercurial-scm.org/D9331

errors: raise more specific errors from rewriteutil Differential Revision: https://phab.mercurial-scm.org/D9330

chgserver: backport py3 buffered I/O workarounds from procutil I've recently switched to new machine and I found chg's stdout is fully buffered. Even though chg server is a daemon process, it inherits the environment where the chg client originally forked the server. This means the server's stdout might have been wrapped by LineBufferedWrapper. That's why we need to do wrap/unwrap in both ways. The "if" condition in _restoreio() looks weird, but I'm not willing to clean things up because stdio behavior is fundamentally different between py2 and py3, and py2 support will be dropped anyway.

chg: reset errno prior to calling strtol() Otherwise we can't figure out if the last strtol() invocation failed or not.

chg: do not close dir fd while iterating It works so long as the dp is the last entry, but readdir(dp) would fail with EBADF. Let's not do that and close the dir fd explicitly.

chg: show debug message for each fd to be closed It helps debugging. The number of file descriptors should be small in most cases, so the console output wouldn't get bloated even with CHG_DEBUG=1.

chg: apply clang-format

errors: use InputError for some errors on `hg clone` Differential Revision: https://phab.mercurial-scm.org/D9329

errors: raise InputError when given non-existent paths etc Differential Revision: https://phab.mercurial-scm.org/D9328

errors: use InputError for errors about bad label names (tags etc) Differential Revision: https://phab.mercurial-scm.org/D9327

errors: use InputError for errors about bad paths Differential Revision: https://phab.mercurial-scm.org/D9326

destutil: raise more specific error when histedit.defaultrev is empty Differential Revision: https://phab.mercurial-scm.org/D9313