Sat, 21 Nov 2020 00:10:36 -0500 phabricator: allow local revisions to be specified with `phabupdate`
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 00:10:36 -0500] rev 46037
phabricator: allow local revisions to be specified with `phabupdate` It's way easier and less error prone to specify a revset after importing a series than to manually type in a series of Differentials. Unlike most revision oriented commands, this requires the `--rev` option explicitly because the existing `DREVSPEC` doesn't need to have the leading 'D', and therefore the meaning is ambiguous. I wouldn't have a problem giving precedence to the local revnum, but `phabread` and `phabimport` also use DREVSPEC, and local revisions make no sense there. I would be fine with modifying that definition to require the leading 'D', but I'm not sure how many people are used to not specifying it. Differential Revision: https://phab.mercurial-scm.org/D9356
Fri, 20 Nov 2020 10:51:07 +0100 copies: properly copies parent dictionary before updating it
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 10:51:07 +0100] rev 46036
copies: properly copies parent dictionary before updating it This enforces the copy on write logic. Otherwise independant unrelated branches could affected each other. More testing of these case are coming, but I need that code landed to unlock other performance work in parallel. Differential Revision: https://phab.mercurial-scm.org/D9419
Mon, 30 Nov 2020 14:07:23 +0100 upgrade: display the list of processed revlog before proceeding
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 14:07:23 +0100] rev 46035
upgrade: display the list of processed revlog before proceeding This help to make sure we don't wrongly skip some in the test and to make sure the user is aware of the amount of processing they is signing up for. Differential Revision: https://phab.mercurial-scm.org/D9469
Wed, 02 Dec 2020 08:23:31 +0100 rhg: add a test with persistent-nodemap
Simon Sapin <simon-commits@exyr.org> [Wed, 02 Dec 2020 08:23:31 +0100] rev 46034
rhg: add a test with persistent-nodemap Differential Revision: https://phab.mercurial-scm.org/D9519
Wed, 02 Dec 2020 15:00:49 +0100 rust: use NodePrefix::from_hex instead of hex::decode directly
Simon Sapin <simon-commits@exyr.org> [Wed, 02 Dec 2020 15:00:49 +0100] rev 46033
rust: use NodePrefix::from_hex instead of hex::decode directly This adds support for prefixes with an odd number of hex digits. Differential Revision: https://phab.mercurial-scm.org/D9490
Mon, 30 Nov 2020 19:34:49 +0100 rhg: allow specifying a changeset ID prefix
Simon Sapin <simon-commits@exyr.org> [Mon, 30 Nov 2020 19:34:49 +0100] rev 46032
rhg: allow specifying a changeset ID prefix Differential Revision: https://phab.mercurial-scm.org/D9479
Thu, 03 Dec 2020 13:23:59 -0800 tests: update test-releasenotes-formatting.t with new exit codes
Martin von Zweigbergk <martinvonz@google.com> [Thu, 03 Dec 2020 13:23:59 -0800] rev 46031
tests: update test-releasenotes-formatting.t with new exit codes I didn't have the fuzzywuzzy package installed before, so I didn't notice this test fail earlier (probably when I made `check_incompatible_arguments` return `InputError`). Differential Revision: https://phab.mercurial-scm.org/D9514
Thu, 03 Dec 2020 14:15:39 -0500 merge with stable
Augie Fackler <augie@google.com> [Thu, 03 Dec 2020 14:15:39 -0500] rev 46030
merge with stable
Thu, 03 Dec 2020 13:36:24 -0500 Added signature for changeset 1d5189a57405 stable
Augie Fackler <raf@durin42.com> [Thu, 03 Dec 2020 13:36:24 -0500] rev 46029
Added signature for changeset 1d5189a57405
Thu, 03 Dec 2020 13:36:23 -0500 Added tag 5.6.1 for changeset 1d5189a57405 stable
Augie Fackler <raf@durin42.com> [Thu, 03 Dec 2020 13:36:23 -0500] rev 46028
Added tag 5.6.1 for changeset 1d5189a57405
Wed, 02 Dec 2020 15:39:01 -0800 rebase: clear merge state when aborting in-memory merge on dirty working copy stable 5.6.1
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:39:01 -0800] rev 46027
rebase: clear merge state when aborting in-memory merge on dirty working copy Differential Revision: https://phab.mercurial-scm.org/D9509
Wed, 02 Dec 2020 15:15:16 -0800 tests: show that in-memory rebase leaves state when working copy is dirty stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:15:16 -0800] rev 46026
tests: show that in-memory rebase leaves state when working copy is dirty When in-memory rebase falls back to on-disk rebase, it checks if the working copy is dirty. If it is, it aborts the rebase. However, it leaves the rebase state on disk. I broke it in feffeb18d412 (rebase: teach in-memory rebase to not restart with on-disk rebase on conflict, 2020-09-18). Differential Revision: https://phab.mercurial-scm.org/D9508
Fri, 27 Nov 2020 14:54:37 -0500 extensions: avoid a crash when the version isn't properly byteified on py3 stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 14:54:37 -0500] rev 46025
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
Mon, 23 Nov 2020 11:47:06 -0500 ui: ensure `getpass()` returns bytes stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 23 Nov 2020 11:47:06 -0500] rev 46024
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
Thu, 26 Nov 2020 02:28:42 -0500 packaging: regenerate the Windows requirements manifest on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 02:28:42 -0500] rev 46023
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
Thu, 26 Nov 2020 03:09:56 -0500 pyoxidizer: point to the py3 requirements instead of py2 on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 03:09:56 -0500] rev 46022
pyoxidizer: point to the py3 requirements instead of py2 on Windows Differential Revision: https://phab.mercurial-scm.org/D9406
Sat, 21 Nov 2020 16:55:07 -0500 extensions: gracefully warn when doing min version check with no local version stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 16:55:07 -0500] rev 46021
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
Sat, 28 Nov 2020 11:15:54 +0900 diff: do not concatenate immutable bytes while building a/b bodies (issue6445) stable
Yuya Nishihara <yuya@tcha.org> [Sat, 28 Nov 2020 11:15:54 +0900] rev 46020
diff: do not concatenate immutable bytes while building a/b bodies (issue6445) Use bytearray instead. I don't know what's changed since Python 2, but bytes concatenation is 100x slow on Python 3. % python2.7 -m timeit -s "s = b''" "for i in range(10000): s += b'line'" 1000 loops, best of 3: 321 usec per loop % python3.9 -m timeit -s "s = b''" "for i in range(10000): s += b'line'" 5 loops, best of 5: 39.2 msec per loop Benchmark using tailwind.css (measuring the fast path, a is empty): % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 1.580 secs (user 1.560+0.000 sys 0.020+0.000) (this) time: real 1.610 secs (user 1.570+0.000 sys 0.030+0.000) % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 114.500 secs (user 114.460+0.000 sys 0.030+0.000) (this) time: real 2.180 secs (user 2.140+0.000 sys 0.040+0.000) Benchmark using random tabular text data (not the fast path): % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf % hg ci -ma % dd if=/dev/urandom bs=1k count=1000 | hexdump -v -e '16/1 "%3u," "\n"' > ttf % hg ci -mb % HGRCPATH=/dev/null python2.7 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 3.240 secs (user 3.040+0.000 sys 0.200+0.000 (this) time: real 3.230 secs (user 3.070+0.000 sys 0.160+0.000) % HGRCPATH=/dev/null python3.9 ./hg log -R /tmp/issue6445 -p --time \ --color=always --config diff.word-diff=true >/dev/null (prev) time: real 44.130 secs (user 43.850+0.000 sys 0.270+0.000) (this) time: real 4.170 secs (user 3.850+0.000 sys 0.310+0.000)
Tue, 01 Dec 2020 01:18:21 -0500 procutil: use rapply(tonativestr, ...) to preserve lists when they come in stable
Augie Fackler <augie@google.com> [Tue, 01 Dec 2020 01:18:21 -0500] rev 46019
procutil: use rapply(tonativestr, ...) to preserve lists when they come in This was broken when script was a list instead of a string. I caught this with an internal extension at Google, and I'm not really sure why it wasn't caught in any kind of CI. Differential Revision: https://phab.mercurial-scm.org/D9471
Wed, 02 Dec 2020 12:33:51 -0800 statprof: separate functions and "line", assume 4 digit line numbers
Kyle Lippincott <spectral@google.com> [Wed, 02 Dec 2020 12:33:51 -0800] rev 46018
statprof: separate functions and "line", assume 4 digit line numbers Previously, the profile output looked like this (I've removed many lines that are mostly inconsequential): ``` | 100.0% 0.02s hg: <module> line 43: dispatch.run() | 100.0% 0.02s dispatch.py: run line 115: status = dispatch(req) | 100.0% 0.02s dispatch.py: _runcatchfunc line 432: return _dispatch(req) \ 50.0% 0.01s dispatch.py: _dispatch line 1228: return runcommand( | 50.0% 0.01s dispatch.py: runcommand line 883: ret = _runcommand(ui, optio... | 50.0% 0.01s dispatch.py: _runcommand line 1240: return cmdfunc() | 50.0% 0.01s localrepo.py: __getitem__ line 1670: quick_access = self._quick_... | 50.0% 0.01s localrepo.py: _quick_access_changeidline 1650: return self._quick_access_c... | 50.0% 0.01s localrepo.py: __get__ line 179: return getattr(unfi, self.n... | 50.0% 0.01s util.py: __get__ line 1747: result = self.func(obj) | 50.0% 0.01s localrepo.py: _quick_access_changeid_wcline 1611: cl = self.unfiltered().chan... | 50.0% 0.01s localrepo.py: __get__ line 110: return super(_basefilecache... | 50.0% 0.01s util.py: __getattribute__line 245: self.__spec__.loader.exec_m... | 50.0% 0.01s <frozen importlib._bootstrap_external>: exec_moduleline 783: | 50.0% 0.01s <frozen importlib._bootstrap>: _call_with_frames_removedline 219: | 50.0% 0.01s changelog.py: <module> line 376: class changelog(revlog.revl... | 50.0% 0.01s util.py: __getattribute__line 245: self.__spec__.loader.exec_m... | 50.0% 0.01s <frozen importlib._bootstrap_external>: exec_moduleline 779: | 50.0% 0.01s <frozen importlib._bootstrap_external>: get_codeline 868: | 50.0% 0.01s <frozen importlib._bootstrap_external>: path_statsline 1012: | 50.0% 0.01s <frozen importlib._bootstrap_external>: _path_statline 87: ``` This has a few problems, though I'm only addressing some of them. 1. If the stuff before "line ###" is long, there's no separation between the function name and the "line" string. 2. If the stuff before "line ###" is really long, there's excessive separation between the "line" string and the line number. 3. We frequently have 4-digit line numbers, the code on the right wasn't dynamically indented and ended up quite messy looking. To solve these problems, I've added a ", " prefix before "line" iff it would otherwise not have any separation such as spaces. I've added a 'max' so that we never use a negative width (which is the cause of problem #2 above), and I've added a default assumption of 4 digit line numbers (but again using a 'max' so this shouldn't cause problems if we go beyond that. With these changes, it now looks like this: ``` | 100.0% 0.02s hg: <module> line 43: dispatch.run() | 100.0% 0.02s dispatch.py: run line 115: status = dispatch(req) | 100.0% 0.02s dispatch.py: _runcatchfunc line 432: return _dispatch(req) \ 50.0% 0.01s dispatch.py: _dispatch line 1228: return runcommand( | 50.0% 0.01s dispatch.py: runcommand line 883: ret = _runcommand(ui, optio... | 50.0% 0.01s dispatch.py: _runcommand line 1240: return cmdfunc() | 50.0% 0.01s localrepo.py: __getitem__ line 1670: quick_access = self._quick_... | 50.0% 0.01s localrepo.py: _quick_access_changeid, line 1650: return self._quick_access_c... | 50.0% 0.01s localrepo.py: __get__ line 179: return getattr(unfi, self.n... | 50.0% 0.01s util.py: __get__ line 1747: result = self.func(obj) | 50.0% 0.01s localrepo.py: _quick_access_changeid_wc, line 1611: cl = self.unfiltered().chan... | 50.0% 0.01s localrepo.py: __get__ line 110: return super(_basefilecache... | 50.0% 0.01s util.py: __getattribute__, line 245: self.__spec__.loader.exec_m... | 50.0% 0.01s <frozen importlib._bootstrap_external>: exec_module, line 783: | 50.0% 0.01s <frozen importlib._bootstrap>: _call_with_frames_removed, line 219: | 50.0% 0.01s changelog.py: <module> line 376: class changelog(revlog.revl... | 50.0% 0.01s util.py: __getattribute__, line 245: self.__spec__.loader.exec_m... | 50.0% 0.01s <frozen importlib._bootstrap_external>: exec_module, line 779: | 50.0% 0.01s <frozen importlib._bootstrap_external>: get_code, line 868: | 50.0% 0.01s <frozen importlib._bootstrap_external>: path_stats, line 1012: | 50.0% 0.01s <frozen importlib._bootstrap_external>: _path_stat, line 87: ``` Differential Revision: https://phab.mercurial-scm.org/D9511
Wed, 02 Dec 2020 15:38:05 -0800 statprof: fix off-by-one-line error in output
Kyle Lippincott <spectral@google.com> [Wed, 02 Dec 2020 15:38:05 -0800] rev 46017
statprof: fix off-by-one-line error in output martinvonz claims they thought that this was intentional, but couldn't remember the reasoning for it. I can't understand why it would be preferable, and I didn't see anything in the comments in the file about why this would be useful, so I'm hopefully not breaking anything by "fixing" it. ### Old output ``` | 100.0% 0.01s dispatch.py: run line 43: dispatch.run() | 100.0% 0.01s dispatch.py: dispatch line 115: status = dispatch(req) | 100.0% 0.01s dispatch.py: _runcatch line 266: ret = _runcatch(req) or 0 | 100.0% 0.01s dispatch.py: _callcatch line 442: return _callcatch(ui, _runc... | 100.0% 0.01s scmutil.py: callcatch line 451: return scmutil.callcatch(ui... | 100.0% 0.01s dispatch.py: _runcatchfunc line 155: return func() | 100.0% 0.01s dispatch.py: _dispatch line 432: return _dispatch(req) | 100.0% 0.01s hg.py: repository line 1179: repo = hg.repository( | 100.0% 0.01s hg.py: _peerorrepo line 221: peer = _peerorrepo( | 100.0% 0.01s util.py: __getattribute__ line 188: obj = _peerlookup(path).ins... | 100.0% 0.01s localrepo.py: makelocalrepositoryline 3227: return makelocalrepository(... | 100.0% 0.01s localrepo.py: __init__ line 683: return cls( | 100.0% 0.01s util.py: __getattribute__ line 1262: self._extrafilterid = repov... | 100.0% 0.01s <frozen importlib._bootstrap_external>: exec_moduleline 245: self.__spec__.loader.exec_m... | 100.0% 0.01s <frozen importlib._bootstrap_external>: get_codeline 779: | 100.0% 0.01s <frozen importlib._bootstrap_external>: path_statsline 868: | 100.0% 0.01s <frozen importlib._bootstrap_external>: _path_statline 1012: ``` ### New output ``` | 100.0% 0.01s hg: <module> line 43: dispatch.run() | 100.0% 0.01s dispatch.py: run line 115: status = dispatch(req) | 100.0% 0.01s dispatch.py: dispatch line 266: ret = _runcatch(req) or 0 | 100.0% 0.01s dispatch.py: _runcatch line 442: return _callcatch(ui, _runc... | 100.0% 0.01s dispatch.py: _callcatch line 451: return scmutil.callcatch(ui... | 100.0% 0.01s scmutil.py: callcatch line 155: return func() | 100.0% 0.01s dispatch.py: _runcatchfunc line 432: return _dispatch(req) | 100.0% 0.01s dispatch.py: _dispatch line 1179: repo = hg.repository( | 100.0% 0.01s hg.py: repository line 221: peer = _peerorrepo( | 100.0% 0.01s hg.py: _peerorrepo line 188: obj = _peerlookup(path).ins... | 100.0% 0.01s localrepo.py: instance line 3227: return makelocalrepository(... | 100.0% 0.01s localrepo.py: makelocalrepositoryline 683: return cls( | 100.0% 0.01s localrepo.py: __init__ line 1262: self._extrafilterid = repov... | 100.0% 0.01s util.py: __getattribute__ line 245: self.__spec__.loader.exec_m... | 100.0% 0.01s <frozen importlib._bootstrap_external>: exec_moduleline 779: | 100.0% 0.01s <frozen importlib._bootstrap_external>: get_codeline 868: | 100.0% 0.01s <frozen importlib._bootstrap_external>: path_statsline 1012: | 100.0% 0.01s <frozen importlib._bootstrap_external>: _path_statline 87: ``` Differential Revision: https://phab.mercurial-scm.org/D9510
Thu, 03 Dec 2020 08:09:56 +0100 phab-refresh: do not error out when the stack is empty
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 03 Dec 2020 08:09:56 +0100] rev 46016
phab-refresh: do not error out when the stack is empty Actually, empty stack is easier to get than I expected (and harmless). When a stack is publish, heptapod will detect the even, empty the stack (triggering CI) and "forgetting" the branch afterward. So we stop returning as error in this case. Differential Revision: https://phab.mercurial-scm.org/D9513
Wed, 02 Dec 2020 20:10:27 +0100 run-tests: allow some slack about 'waiting on lock' message
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 02 Dec 2020 20:10:27 +0100] rev 46015
run-tests: allow some slack about 'waiting on lock' message It is common to run the tests on very loaded machine when concurrent run might take a bit longer. Such message are usually harmless, but anoying as they break the tests. Test that explicitly depends on this value have been adjusted. This make them more robust anyway. A fun case was `test-clone-pull-corruption.t` which, without the previous changeset introducing extra flushing, ended use having a line 31 (`pulling from ../source`) changing order because the warning message was no longer flushing stdin before using stderr (stderr being invisible in the test). Differential Revision: https://phab.mercurial-scm.org/D9507
Wed, 02 Dec 2020 23:15:11 +0100 pull: flush stdin after the `pull from` message
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 02 Dec 2020 23:15:11 +0100] rev 46014
pull: flush stdin after the `pull from` message That message can end up being flushed after some stderr message in some case, leading to confusing output. Differential Revision: https://phab.mercurial-scm.org/D9506
Wed, 02 Dec 2020 20:10:22 +0100 tests: explicitly skip the lock warning in some remotefilelog tests
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 02 Dec 2020 20:10:22 +0100] rev 46013
tests: explicitly skip the lock warning in some remotefilelog tests The output was conditional zed, so lets official skip it instead. Differential Revision: https://phab.mercurial-scm.org/D9505
Wed, 02 Dec 2020 20:02:35 +0100 tests: use the right python when running dummyssh for narrow
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 02 Dec 2020 20:02:35 +0100] rev 46012
tests: use the right python when running dummyssh for narrow some plateform no longer have a `python` executable. Differential Revision: https://phab.mercurial-scm.org/D9504
Wed, 02 Dec 2020 11:05:53 -0800 copies: avoid materializing a full directory map during copy tracing
Kyle Lippincott <spectral@google.com> [Wed, 02 Dec 2020 11:05:53 -0800] rev 46011
copies: avoid materializing a full directory map during copy tracing Materializing a full copy of every directory in a treemanifest repo can be quite expensive, even with a narrow matcher. For flat manifest repos, this should be equivalent - it will still materialize (and cache) a dict of all of the dirs inside of the manifest object, we just don't get a copy of it. In a repo I have here, this brings the time for a simple rebase from 11.197s to 4.609s. Differential Revision: https://phab.mercurial-scm.org/D9503
Wed, 02 Dec 2020 15:39:01 -0800 rebase: clear merge state when aborting in-memory merge on dirty working copy
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:39:01 -0800] rev 46010
rebase: clear merge state when aborting in-memory merge on dirty working copy Differential Revision: https://phab.mercurial-scm.org/D9509
Wed, 02 Dec 2020 15:15:16 -0800 tests: show that in-memory rebase leaves state when working copy is dirty
Martin von Zweigbergk <martinvonz@google.com> [Wed, 02 Dec 2020 15:15:16 -0800] rev 46009
tests: show that in-memory rebase leaves state when working copy is dirty When in-memory rebase falls back to on-disk rebase, it checks if the working copy is dirty. If it is, it aborts the rebase. However, it leaves the rebase state on disk. I broke it in feffeb18d412 (rebase: teach in-memory rebase to not restart with on-disk rebase on conflict, 2020-09-18). Differential Revision: https://phab.mercurial-scm.org/D9508
Fri, 27 Nov 2020 18:32:20 +0530 helptext: document share safe functionality in `hg help config -v`
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 27 Nov 2020 18:32:20 +0530] rev 46008
helptext: document share safe functionality in `hg help config -v` If share safe functionality is enabled, we read `.hg/hgrc' of shared source. Differential Revision: https://phab.mercurial-scm.org/D9413
Fri, 27 Nov 2020 18:28:14 +0530 helptext: mention in `hg help config` that `.hg/hgrc-not-shared` is consulted
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 27 Nov 2020 18:28:14 +0530] rev 46007
helptext: mention in `hg help config` that `.hg/hgrc-not-shared` is consulted Recently we added `.hg/hgrc-not-shared` which is a config file which won't be shared with shares when share-safe mode is enabled. Irrespective of whether we are using share-safe or not, we consult this file now. Let's document that. Differential Revision: https://phab.mercurial-scm.org/D9412
Fri, 27 Nov 2020 18:11:47 +0530 share: add documentation about share-safe mode in `hg help -e share`
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 27 Nov 2020 18:11:47 +0530] rev 46006
share: add documentation about share-safe mode in `hg help -e share` Differential Revision: https://phab.mercurial-scm.org/D9411
Fri, 27 Nov 2020 18:11:04 +0530 helptext: update first hg version when share-safe will be released
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 27 Nov 2020 18:11:04 +0530] rev 46005
helptext: update first hg version when share-safe will be released I authored the patch which added the helptext before 5.6 release hoping that my patches will make it. However they didn't before the release and were pushed after the release only. Differential Revision: https://phab.mercurial-scm.org/D9410
Mon, 23 Nov 2020 14:15:26 +0530 share: show warning if share is outdated while source supports share-safe
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 23 Nov 2020 14:15:26 +0530] rev 46004
share: show warning if share is outdated while source supports share-safe Previous patches in the series and some which are already committed implements share safe functionality where config and requirements will be shared too. Rolling this feature has a problem that existing shares may never upgrade as they will never learn about the new config. To help the transition, we show a warning message if the share source supports share-safe mechanism. This provides the source repo ability to upgrade and pass on the message to shares that you should reshare and upgrade too. Differential Revision: https://phab.mercurial-scm.org/D9369
Fri, 16 Oct 2020 18:57:55 +0530 upgrade: add support to downgrade share safe mode
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 16 Oct 2020 18:57:55 +0530] rev 46003
upgrade: add support to downgrade share safe mode In previous patch we added support to upgrade current repository to use share safe mode. This patch adds support to downgrade to remove share-safe mode. Differential Revision: https://phab.mercurial-scm.org/D9358
Thu, 25 Jun 2020 13:13:21 +0530 upgrade: add support for experimental safe share mode
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 25 Jun 2020 13:13:21 +0530] rev 46002
upgrade: add support for experimental safe share mode Recently we introduce the share-safe functionality which makes shares share requirements and config of share source. This patch adds support to `debugupgraderepo` command to upgrade repository to share-safe mode when `format.exp-share-safe` config is enabled. Differential Revision: https://phab.mercurial-scm.org/D9144
Mon, 30 Nov 2020 14:11:03 +0530 chgserver: catch RepoError while loading configuration
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 30 Nov 2020 14:11:03 +0530] rev 46001
chgserver: catch RepoError while loading configuration Recent share safe work introduced functionality to read share source config file on dispatch. This can result in RepoError while reading config file as the shared source might not be present. `test-share.t#safe` was failing with chg earlier because of this. Differential Revision: https://phab.mercurial-scm.org/D9462
Sat, 28 Nov 2020 16:59:40 -0500 registrar: clarify the documentation about some byte strings being required
Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Nov 2020 16:59:40 -0500] rev 46000
registrar: clarify the documentation about some byte strings being required I *thought* these needed to be byte strings, but didn't remember and had to search out examples. Differential Revision: https://phab.mercurial-scm.org/D9489
Mon, 30 Nov 2020 12:30:58 -0800 match: skip walking up the directory hierarchy if the number of pats are small
Kyle Lippincott <spectral@google.com> [Mon, 30 Nov 2020 12:30:58 -0800] rev 45999
match: skip walking up the directory hierarchy if the number of pats are small Previously, we would receive a path like abc/def/ghi and "walk up" the directory hierarchy, checking abc/def, abc, and `b''` to see if they were in the set of prefixes that this matcher covered. We did this indiscriminately - we generated all of these paths even if the set of prefixes the matcher covered was completely empty, which is the case for a lot of repos at my company (the narrow matcher we use is usually non-recursive). This brings the time for a rebase in one of my repos from 12.20s to 10.87s. In this particular repo, this is entirely due to the `len(prefix_set) == 0` check, as I do not have any recursive patterns in the narrowspec. Differential Revision: https://phab.mercurial-scm.org/D9488
Tue, 01 Dec 2020 22:19:01 +0100 relnotes: document better memory use for unbundle
Joerg Sonnenberger <joerg@bec.de> [Tue, 01 Dec 2020 22:19:01 +0100] rev 45998
relnotes: document better memory use for unbundle Differential Revision: https://phab.mercurial-scm.org/D9481
Mon, 30 Nov 2020 14:06:45 +0100 upgrade: add an explicite --filelogs arguments
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 14:06:45 +0100] rev 45997
upgrade: add an explicite --filelogs arguments This make it possible to select no revlog for upgrade, which is useful for some upgrade target or in some specific cases (eg: persistent-nodemap or share-safe update). Differential Revision: https://phab.mercurial-scm.org/D9468
Mon, 30 Nov 2020 19:26:54 +0100 rhg: add a test for --rev with a hex changeset ID
Simon Sapin <simon-commits@exyr.org> [Mon, 30 Nov 2020 19:26:54 +0100] rev 45996
rhg: add a test for --rev with a hex changeset ID And fix error message formatting Differential Revision: https://phab.mercurial-scm.org/D9478
Tue, 01 Dec 2020 02:07:15 +0100 upgrade: move optimisation to something more declarative
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 02:07:15 +0100] rev 45995
upgrade: move optimisation to something more declarative This is not great yet, but still better than the previous state. This get use one step closer to having all the possible "actions" clearly declared and moved in a dedicated module. Differential Revision: https://phab.mercurial-scm.org/D9475
Mon, 30 Nov 2020 23:54:25 +0100 upgrade: capitalize the `deficiency` constant
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 23:54:25 +0100] rev 45994
upgrade: capitalize the `deficiency` constant I am reworking this code and moving to the current naming scheme help readability. Differential Revision: https://phab.mercurial-scm.org/D9474
Mon, 30 Nov 2020 23:52:29 +0100 upgrade: capitalize the `deficiency` constant
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 23:52:29 +0100] rev 45993
upgrade: capitalize the `deficiency` constant I am reworking this code and moving to the current naming scheme help readability. Differential Revision: https://phab.mercurial-scm.org/D9473
Mon, 30 Nov 2020 09:47:46 -0800 tests: set old git default branch name for compatibility
Martin von Zweigbergk <martinvonz@google.com> [Mon, 30 Nov 2020 09:47:46 -0800] rev 45992
tests: set old git default branch name for compatibility Git's default branch name has changed on my machine (from "master" to "main"). Let's set the old name in our tests so we're compatible with both defaults (and maybe still compatible with Git versions that don't know about the config option). Differential Revision: https://phab.mercurial-scm.org/D9470
Sat, 28 Nov 2020 14:15:55 +0100 heptapod-ci: automatically refresh existing phabricator Diff on push
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 14:15:55 +0100] rev 45991
heptapod-ci: automatically refresh existing phabricator Diff on push If a changeset have been submitted to Phabricator and a new version is pushed to heptapod, we should refresh the state on Phabricator. If we do not do this, they are a risk of an older version being applied from Phabricator. In this situation content-divergence will be (rightfully) detected by evolution. We only refresh the Diff if the test pass, to avoid updating Phabricator with broken content. Differential Revision: https://phab.mercurial-scm.org/D9451
Sat, 28 Nov 2020 14:11:54 +0100 contrib: add a small script to refresh all diff in the current stack
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 14:11:54 +0100] rev 45990
contrib: add a small script to refresh all diff in the current stack This will be useful to introduce automatic refresh through heptapod. Differential Revision: https://phab.mercurial-scm.org/D9460
Mon, 30 Nov 2020 14:48:02 +0530 tests: conditionalize return code on chg in test-config.t
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 30 Nov 2020 14:48:02 +0530] rev 45989
tests: conditionalize return code on chg in test-config.t If there is any error while reading config, chg just returns 255 instead of 30. It seems to me that we cannot conditionalize only return codes in output using trailing `(chg !)` and hence used testcases. The test was failing with chg but after this patch, it now passes. Differential Revision: https://phab.mercurial-scm.org/D9463
Fri, 27 Nov 2020 21:32:42 +0530 tests: update test-chg.t with output change
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 27 Nov 2020 21:32:42 +0530] rev 45988
tests: update test-chg.t with output change Since this part of tests is only run with chg, hence it didn't get updated when the error message changed. Differential Revision: https://phab.mercurial-scm.org/D9414
Mon, 23 Nov 2020 14:33:58 +0100 rust-format: pin the formatted to a specific nightly version
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 23 Nov 2020 14:33:58 +0100] rev 45987
rust-format: pin the formatted to a specific nightly version Version 1.50 change the way rust-format behave. We pin the version for now, we can figure out something better later.
Fri, 20 Nov 2020 11:22:28 +0100 copies: clarify the return of _merge_copies_dict
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 11:22:28 +0100] rev 45986
copies: clarify the return of _merge_copies_dict I misused that function twice in the past few days, so lets clarify the API. Differential Revision: https://phab.mercurial-scm.org/D9418
Fri, 20 Nov 2020 10:38:46 +0100 copies: avoid unwanted side effect from one branch to another
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 10:38:46 +0100] rev 45985
copies: avoid unwanted side effect from one branch to another Without this copy, change in a one descendant branch (With "remove" change only) could affect computation on another descendant branches. This was not caugh by the test because the test graph are "too simple". I started writing more test in that regards, but I a submitting this changes earlier because I want to get more code landed to allow other optimisation work to happens. Differential Revision: https://phab.mercurial-scm.org/D9416
Thu, 26 Nov 2020 09:54:16 +0100 rhg: use `format_bytes!` for error messages
Raphaël Gomès <rgomes@octobus.net> [Thu, 26 Nov 2020 09:54:16 +0100] rev 45984
rhg: use `format_bytes!` for error messages This change also includes a formatting changing with the new `rustfmt` version, but I'm expecting it to have already been applied in another patch by the time this lands. Differential Revision: https://phab.mercurial-scm.org/D9407
Mon, 30 Nov 2020 10:18:36 +0100 packaging: don't use plain 'python' if another python has been specified
Mathias De Mare <mathias.de_mare@nokia.com> [Mon, 30 Nov 2020 10:18:36 +0100] rev 45983
packaging: don't use plain 'python' if another python has been specified Before this change, packaging on CentOS 8 failed because 'python' is used instead of 'python3'. Change was tested with: - make docker-centos7 - make docker-centos8 - make docker-ubuntu-bionic Differential Revision: https://phab.mercurial-scm.org/D9464
Thu, 26 Nov 2020 02:00:00 -0500 packaging: add pygit2 to the py3 Windows installers
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 02:00:00 -0500] rev 45982
packaging: add pygit2 to the py3 Windows installers This is needed to be able to use the git extension. The extension no longer complains about the library being not installed, but `hg log -r .` on a repo that works in WSL yielded a TypeError: ... File "mercurial.hg", line 188, in _peerorrepo File "mercurial.localrepo", line 3224, in instance File "mercurial.localrepo", line 623, in makelocalrepository File "hgext.git", line 117, in _makestore File "hgext.git", line 48, in __init__ TypeError: Repository unable to unpack backend. Differential Revision: https://phab.mercurial-scm.org/D9405
Mon, 30 Nov 2020 12:40:28 +0100 upgrade: directly use the upgrade action constant
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 12:40:28 +0100] rev 45981
upgrade: directly use the upgrade action constant This make the code simpler and will make it simpler to add more case in the future. Differential Revision: https://phab.mercurial-scm.org/D9467
Mon, 30 Nov 2020 12:24:36 +0100 upgrade: rename UPGRADE_FILELOG to UPGRADE_FILELOGS
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Nov 2020 12:24:36 +0100] rev 45980
upgrade: rename UPGRADE_FILELOG to UPGRADE_FILELOGS They are multiple filelog to upgrade, so this seems more accurate. Differential Revision: https://phab.mercurial-scm.org/D9466
Mon, 23 Nov 2020 12:54:46 +0100 bisect: add `-G` to an `hg log` command in a test
Simon Sapin <simon-commits@exyr.org> [Mon, 23 Nov 2020 12:54:46 +0100] rev 45979
bisect: add `-G` to an `hg log` command in a test This helps readers see what shape of DAG to expect Differential Revision: https://phab.mercurial-scm.org/D9373
Mon, 23 Nov 2020 12:45:39 +0100 bisect: refactor to work on a list of revspecs
Simon Sapin <simon-commits@exyr.org> [Mon, 23 Nov 2020 12:45:39 +0100] rev 45978
bisect: refactor to work on a list of revspecs This will allow adding a `--rev` flag that can be passed more than once. Differential Revision: https://phab.mercurial-scm.org/D9372
Fri, 20 Nov 2020 10:35:42 +0100 copies: simplify the call to _merge_copies_dict
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 10:35:42 +0100] rev 45977
copies: simplify the call to _merge_copies_dict Let's get the argument into the right order, then call the function once. Differential Revision: https://phab.mercurial-scm.org/D9417
Fri, 20 Nov 2020 10:49:32 +0100 copies: fast path no-op merge
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 10:49:32 +0100] rev 45976
copies: fast path no-op merge If the two sides of the merge are the same (they come an unaltered common ancestors) we don't need any merging. Differential Revision: https://phab.mercurial-scm.org/D9415
Mon, 05 Oct 2020 01:49:04 +0200 copies-rust: encapsulate internal sets on `changes`
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Oct 2020 01:49:04 +0200] rev 45975
copies-rust: encapsulate internal sets on `changes` The goal is to eventually stop creating the underlying set. So we need to encapsulate the call first. Differential Revision: https://phab.mercurial-scm.org/D9306
Fri, 30 Oct 2020 19:06:12 +0100 copies-rust: pre-indent some code to clarify the next patch
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 30 Oct 2020 19:06:12 +0100] rev 45974
copies-rust: pre-indent some code to clarify the next patch The next patch will need this new indentation, having it done explicitly beforehand makes that next patch clearer. Differential Revision: https://phab.mercurial-scm.org/D9305
Mon, 05 Oct 2020 01:31:32 +0200 copies-rust: combine the iteration over remove and copies into one
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 05 Oct 2020 01:31:32 +0200] rev 45973
copies-rust: combine the iteration over remove and copies into one In the underlying data, the copies information and the removal information are interleaved. And in the consumer code, the consumption could be interleaved too. So, we make the processing closer to the underlying data by fusing the two iterators into one. Later, we will directly consume the underlying data and that logic to combine the two iterators will be unnecessary. Differential Revision: https://phab.mercurial-scm.org/D9304
Fri, 02 Oct 2020 15:41:31 +0200 copies-rust: move is_ancestor caching within the rust code
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Oct 2020 15:41:31 +0200] rev 45972
copies-rust: move is_ancestor caching within the rust code Now that the OrdMap merging is fast, smaller things start to matters. We move the caching of `is_ancestor` call within the Rust code. This avoid round-trip to Python and help us to shave more time on our slower case: Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 2.780174 s, 2.137894 s, -0.642280 s, × 0.7690 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 9.843481 s, 8.100385 s, -1.743096 s, × 0.8229 Note: I would happily have used native code for ancestors computation, however I failed (did not tried hard) to created a rust version that goes as fast as the current C version. Below are full tables for: - this change compared to the previous change - this change compared to filelog performance Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000049 s, 0.000047 s, -0.000002 s, × 0.9592 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000182 s, 0.000181 s, -0.000001 s, × 0.9945 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.005872 s, 0.005852 s, -0.000020 s, × 0.9966 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000229 s, 0.000229 s, +0.000000 s, × 1.0000 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000058 s, 0.000058 s, +0.000000 s, × 1.0000 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000148 s, 0.000146 s, -0.000002 s, × 0.9865 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001205 s, 0.001206 s, +0.000001 s, × 1.0008 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.025662 s, 0.025275 s, -0.000387 s, × 0.9849 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.080113 s, 0.080303 s, +0.000190 s, × 1.0024 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.153030 s, 0.152641 s, -0.000389 s, × 0.9975 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.098774 s, 0.099107 s, +0.000333 s, × 1.0034 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 2.780174 s, 2.137894 s, -0.642280 s, × 0.7690 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.022218 s, 0.022202 s, -0.000016 s, × 0.9993 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.252125 s, 0.228946 s, -0.023179 s, × 0.9081 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000186 s, 0.000186 s, +0.000000 s, × 1.0000 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000133 s, 0.000133 s, +0.000000 s, × 1.0000 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000320 s, 0.000320 s, +0.000000 s, × 1.0000 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001336 s, 0.001339 s, +0.000003 s, × 1.0022 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.015573 s, 0.015694 s, +0.000121 s, × 1.0078 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.018667 s, 0.018457 s, -0.000210 s, × 0.9888 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.112534 s, 0.111691 s, -0.000843 s, × 0.9925 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 1.231869 s, 1.166017 s, -0.065852 s, × 0.9465 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000197 s, 0.000197 s, +0.000000 s, × 1.0000 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000637 s, 0.000626 s, -0.000011 s, × 0.9827 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000303 s, 0.000303 s, +0.000000 s, × 1.0000 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001663 s, 0.001679 s, +0.000016 s, × 1.0096 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.007008 s, 0.006947 s, -0.000061 s, × 0.9913 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.127385 s, 0.133070 s, +0.005685 s, × 1.0446 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.008740 s, 0.008705 s, -0.000035 s, × 0.9960 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.005783 s, 0.005913 s, +0.000130 s, × 1.0225 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.102184 s, 0.101373 s, -0.000811 s, × 0.9921 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.046220 s, 0.046526 s, +0.000306 s, × 1.0066 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.315271 s, 0.313954 s, -0.001317 s, × 0.9958 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 3.478747 s, 3.367395 s, -0.111352 s, × 0.9680 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 4.766435 s, 4.691820 s, -0.074615 s, × 0.9843 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001214 s, 0.001199 s, -0.000015 s, × 0.9876 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001221 s, 0.001216 s, -0.000005 s, × 0.9959 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000613 s, 0.000613 s, +0.000000 s, × 1.0000 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001904 s, 0.001906 s, +0.000002 s, × 1.0011 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.093000 s, 0.092766 s, -0.000234 s, × 0.9975 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.132194 s, 0.136074 s, +0.003880 s, × 1.0294 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.009069 s, 0.009067 s, -0.000002 s, × 0.9998 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.006169 s, 0.006243 s, +0.000074 s, × 1.0120 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.115540 s, 0.114463 s, -0.001077 s, × 0.9907 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.435381 s, 0.433683 s, -0.001698 s, × 0.9961 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.415461 s, 0.411278 s, -0.004183 s, × 0.9899 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.155946 s, 0.155133 s, -0.000813 s, × 0.9948 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.048521 s, 0.048933 s, +0.000412 s, × 1.0085 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 9.843481 s, 8.100385 s, -1.743096 s, × 0.8229 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 1.465128 s, 1.446720 s, -0.018408 s, × 0.9874 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.374283 s, 1.369537 s, -0.004746 s, × 0.9965 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 5.255158 s, 5.186079 s, -0.069079 s, × 0.9869 Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor -------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000892 s, 0.000047 s, -0.000845 s, × 0.052691 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.001823 s, 0.000181 s, -0.001642 s, × 0.099287 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.018063 s, 0.005852 s, -0.012211 s, × 0.323977 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.001505 s, 0.000229 s, -0.001276 s, × 0.152159 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.205895 s, 0.000058 s, -0.205837 s, × 0.000282 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.017021 s, 0.000146 s, -0.016875 s, × 0.008578 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.019422 s, 0.001206 s, -0.018216 s, × 0.062095 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.767740 s, 0.025275 s, -0.742465 s, × 0.032921 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 1.188515 s, 0.080303 s, -1.108212 s, × 0.067566 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 1.251968 s, 0.152641 s, -1.099327 s, × 0.121921 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 1.616799 s, 0.099107 s, -1.517692 s, × 0.061298 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.001057 s, 2.137894 s, +2.136837 s, × 2022.605487 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 1.069485 s, 0.022202 s, -1.047283 s, × 0.020760 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.350162 s, 0.228946 s, -1.121216 s, × 0.169569 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.028008 s, 0.000186 s, -0.027822 s, × 0.006641 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.132281 s, 0.000133 s, -0.132148 s, × 0.001005 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.025311 s, 0.000320 s, -0.024991 s, × 0.012643 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.052957 s, 0.001339 s, -0.051618 s, × 0.025285 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.038011 s, 0.015694 s, -0.022317 s, × 0.412880 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.198639 s, 0.018457 s, -0.180182 s, × 0.092917 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.955713 s, 0.111691 s, -0.844022 s, × 0.116867 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 3.838886 s, 1.166017 s, -2.672869 s, × 0.303738 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.024548 s, 0.000197 s, -0.024351 s, × 0.008025 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.143394 s, 0.000626 s, -0.142768 s, × 0.004366 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.026046 s, 0.000303 s, -0.025743 s, × 0.011633 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.085440 s, 0.001679 s, -0.083761 s, × 0.019651 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.195656 s, 0.006947 s, -0.188709 s, × 0.035506 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.190874 s, 0.133070 s, -2.057804 s, × 0.060738 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.090208 s, 0.008705 s, -0.081503 s, × 0.096499 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.747367 s, 0.005913 s, -0.741454 s, × 0.007912 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 1.152863 s, 0.101373 s, -1.051490 s, × 0.087932 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.598336 s, 0.046526 s, -6.551810 s, × 0.007051 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 3.255015 s, 0.313954 s, -2.941061 s, × 0.096452 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 15.668041 s, 3.367395 s, -12.300646 s, × 0.214921 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 20.439638 s, 4.691820 s, -15.747818 s, × 0.229545 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.080923 s, 0.001199 s, -0.079724 s, × 0.014817 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.498456 s, 0.001216 s, -0.497240 s, × 0.002440 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.020798 s, 0.000613 s, -0.020185 s, × 0.029474 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.226930 s, 0.001906 s, -0.225024 s, × 0.008399 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1.113005 s, 0.092766 s, -1.020239 s, × 0.083347 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.230671 s, 0.136074 s, -2.094597 s, × 0.061001 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089672 s, 0.009067 s, -0.080605 s, × 0.101113 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.740221 s, 0.006243 s, -0.733978 s, × 0.008434 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 1.185881 s, 0.114463 s, -1.071418 s, × 0.096521 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.086072 s, 0.433683 s, +0.347611 s, × 5.038607 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.081321 s, 0.411278 s, +0.329957 s, × 5.057464 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 7.528370 s, 0.155133 s, -7.373237 s, × 0.020606 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.757368 s, 0.048933 s, -6.708435 s, × 0.007241 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.643752 s, 8.100385 s, +0.456633 s, × 1.059739 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 9.704242 s, 1.446720 s, -8.257522 s, × 0.149081 mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 0.092845 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 26.626870 s, 1.369537 s, -25.257333 s, × 0.051434 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 0.092953 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 0.227131 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 18.884666 s, 5.186079 s, -13.698587 s, × 0.274619 mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 21.451622 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 25.152558 s, killed Differential Revision: https://phab.mercurial-scm.org/D9303
Tue, 21 Apr 2020 15:00:32 +0200 copies-rust: leverage the immutability for efficient update
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Apr 2020 15:00:32 +0200] rev 45971
copies-rust: leverage the immutability for efficient update The immutable OrdMap has a diff function. That function yield items for each difference (missing in minor; missing in major; present in both, but different). We reorganise the manifest merging code to use this new function. We gather the data we would need to inject into the `minor` or `major` dict and eventually update one of them. The semantic of the merge itself is kept as is. Why are we doing this? Last year we contributed a patch making that diff function quickly detect some of the identical subsection when comparing two OrdMap cloned from a common ancestors (because they point to the very same node in memory). As a result: - That diff function is very fast in most of our cases, - It is important to maximize the "common" part by minimising the amount of unnecessary changes we do in theses Map. This is why we gather update for both and update the one with the smaller update. In practice, this yield a massive speed up on all our slow cases. Some examples below.: Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 33.527067 s, 2.780174 s, -30.746893 s, × 0.0829 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : killed(>120), 1.231869 s mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : killed(>120), 3.478747 s mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 83.508590 s, 9.843481 s, -73.665109 s, × 0.1179 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 55.079813 s, 1.465128 s, -53.614685 s, × 0.0266 The performance compared to the Python code are now comparable (worst case are a score percent slower)" You an check the full table below for details. The big new is that, with this change, we are now faster filelog in most case, . Below is an highlight of some pretty nice win: Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor --------------------------------------------------------------------------------------------------------------------------------------- pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.354211 s, 0.252125 s, -1.102086 s, × 0.186179 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.939593 s, 0.112534 s, -0.827059 s, × 0.119769 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 3.824967 s, 1.231869 s, -2.593098 s, × 0.322060 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 1.142414 s, 0.102184 s, -1.040230 s, × 0.089446 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.667504 s, 0.046220 s, -6.621284 s, × 0.006932 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 3.267274 s, 0.315271 s, -2.952003 s, × 0.096494 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 16.038104 s, 3.478747 s, -12.559357 s, × 0.216905 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 20.639928 s, 4.766435 s, -15.873493 s, × 0.230933 They they are a handful of slower case where we perform less well. A good Share of them are really pathological "service" merge in mozilla-try, but not all of them. Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor --------------------------------------------------------------------------------------------------------------------------------------- pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.001055 s, 2.780174 s, +2.779119 s, × 2635.236019 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.088715 s, 0.435381 s, +0.346666 s, × 4.907637 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.080765 s, 0.415461 s, +0.334696 s, × 5.144072 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.598509 s, 9.843481 s, +2.244972 s, × 1.295449 mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 0.092232 s, killed mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 0.093892 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 0.227503 s, killed mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 21.145391 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 25.304164 s, killed Below are two different tables for full performance comparison - this changeset against the previous one (spoiler: it is much better) - this changeset against the python code (spoiler: still slower, but it gets more comparable) - this changeset against the filelog code (spoiler: better in many case, but not all) Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000049 s, 0.000049 s, +0.000000 s, × 1.0000 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000179 s, 0.000182 s, +0.000003 s, × 1.0168 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.006494 s, 0.005872 s, -0.000622 s, × 0.9042 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000339 s, 0.000229 s, -0.000110 s, × 0.6755 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000057 s, 0.000058 s, +0.000001 s, × 1.0175 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000299 s, 0.000148 s, -0.000151 s, × 0.4950 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001200 s, 0.001205 s, +0.000005 s, × 1.0042 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.025120 s, 0.025662 s, +0.000542 s, × 1.0216 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.506921 s, 0.080113 s, -0.426808 s, × 0.1580 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 1.272060 s, 0.153030 s, -1.119030 s, × 0.1203 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.690941 s, 0.098774 s, -0.592167 s, × 0.1430 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 33.527067 s, 2.780174 s, -30.746893 s, × 0.0829 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.021970 s, 0.022218 s, +0.000248 s, × 1.0113 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.772094 s, 0.252125 s, -1.519969 s, × 0.1423 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000185 s, 0.000186 s, +0.000001 s, × 1.0054 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000135 s, 0.000133 s, -0.000002 s, × 0.9852 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000329 s, 0.000320 s, -0.000009 s, × 0.9726 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001343 s, 0.001336 s, -0.000007 s, × 0.9948 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.029396 s, 0.015573 s, -0.013823 s, × 0.5298 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.040210 s, 0.018667 s, -0.021543 s, × 0.4642 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 4.556794 s, 0.112534 s, -4.444260 s, × 0.0247 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : killed , 1.231869 s mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000199 s, 0.000197 s, -0.000002 s, × 0.9899 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000639 s, 0.000637 s, -0.000002 s, × 0.9969 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000542 s, 0.000303 s, -0.000239 s, × 0.5590 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001685 s, 0.001663 s, -0.000022 s, × 0.9869 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.006954 s, 0.007008 s, +0.000054 s, × 1.0078 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.132938 s, 0.127385 s, -0.005553 s, × 0.9582 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.008683 s, 0.008740 s, +0.000057 s, × 1.0066 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.005956 s, 0.005783 s, -0.000173 s, × 0.9710 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.963905 s, 0.102184 s, -0.861721 s, × 0.1060 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.049239 s, 0.046220 s, -0.003019 s, × 0.9387 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 4.217003 s, 0.315271 s, -3.901732 s, × 0.0748 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : killed , 3.478747 s mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : killed , 4.766435 s mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001197 s, 0.001214 s, +0.000017 s, × 1.0142 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001213 s, 0.001221 s, +0.000008 s, × 1.0066 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000762 s, 0.000613 s, -0.000149 s, × 0.8045 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001909 s, 0.001904 s, -0.000005 s, × 0.9974 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.093021 s, 0.093000 s, -0.000021 s, × 0.9998 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.134536 s, 0.132194 s, -0.002342 s, × 0.9826 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.009071 s, 0.009069 s, -0.000002 s, × 0.9998 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.006206 s, 0.006169 s, -0.000037 s, × 0.9940 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 1.150502 s, 0.115540 s, -1.034962 s, × 0.1004 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 1.114864 s, 0.435381 s, -0.679483 s, × 0.3905 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 1.042658 s, 0.415461 s, -0.627197 s, × 0.3985 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.447402 s, 0.155946 s, -0.291456 s, × 0.3486 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.051132 s, 0.048521 s, -0.002611 s, × 0.9489 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 83.508590 s, 9.843481 s, -73.665109 s, × 0.1179 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 55.079813 s, 1.465128 s, -53.614685 s, × 0.0266 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.442793 s, 1.374283 s, -0.068510 s, × 0.9525 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : killed , 5.255158 s Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000044 s, 0.000049 s, +0.000005 s, × 1.1136 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000138 s, 0.000182 s, +0.000044 s, × 1.3188 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.005052 s, 0.005872 s, +0.000820 s, × 1.1623 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000219 s, 0.000229 s, +0.000010 s, × 1.0457 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000055 s, 0.000058 s, +0.000003 s, × 1.0545 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000128 s, 0.000148 s, +0.000020 s, × 1.1562 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001089 s, 0.001205 s, +0.000116 s, × 1.1065 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.017407 s, 0.025662 s, +0.008255 s, × 1.4742 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.094175 s, 0.080113 s, -0.014062 s, × 0.8507 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.238009 s, 0.153030 s, -0.084979 s, × 0.6430 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.125876 s, 0.098774 s, -0.027102 s, × 0.7847 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 3.581556 s, 2.780174 s, -0.801382 s, × 0.7762 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.016721 s, 0.022218 s, +0.005497 s, × 1.3287 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.242367 s, 0.252125 s, +0.009758 s, × 1.0403 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000165 s, 0.000186 s, +0.000021 s, × 1.1273 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000114 s, 0.000133 s, +0.000019 s, × 1.1667 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000296 s, 0.000320 s, +0.000024 s, × 1.0811 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001124 s, 0.001336 s, +0.000212 s, × 1.1886 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.013060 s, 0.015573 s, +0.002513 s, × 1.1924 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.017112 s, 0.018667 s, +0.001555 s, × 1.0909 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.660350 s, 0.112534 s, -0.547816 s, × 0.1704 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 10.032499 s, 1.231869 s, -8.800630 s, × 0.1228 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000189 s, 0.000197 s, +0.000008 s, × 1.0423 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000462 s, 0.000637 s, +0.000175 s, × 1.3788 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000270 s, 0.000303 s, +0.000033 s, × 1.1222 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001474 s, 0.001663 s, +0.000189 s, × 1.1282 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.004806 s, 0.007008 s, +0.002202 s, × 1.4582 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.085150 s, 0.127385 s, +0.042235 s, × 1.4960 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007064 s, 0.008740 s, +0.001676 s, × 1.2373 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004741 s, 0.005783 s, +0.001042 s, × 1.2198 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.190133 s, 0.102184 s, -0.087949 s, × 0.5374 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.035651 s, 0.046220 s, +0.010569 s, × 1.2965 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.440694 s, 0.315271 s, -0.125423 s, × 0.7154 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 18.454163 s, 3.478747 s, -14.975416 s, × 0.1885 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 31.562719 s, 4.766435 s, -26.796284 s, × 0.1510 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001189 s, 0.001214 s, +0.000025 s, × 1.0210 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001204 s, 0.001221 s, +0.000017 s, × 1.0141 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000586 s, 0.000613 s, +0.000027 s, × 1.0461 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001845 s, 0.001904 s, +0.000059 s, × 1.0320 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.063822 s, 0.093000 s, +0.029178 s, × 1.4572 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.088038 s, 0.132194 s, +0.044156 s, × 1.5016 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007389 s, 0.009069 s, +0.001680 s, × 1.2274 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004868 s, 0.006169 s, +0.001301 s, × 1.2673 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.222450 s, 0.115540 s, -0.106910 s, × 0.5194 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.370675 s, 0.435381 s, +0.064706 s, × 1.1746 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.358020 s, 0.415461 s, +0.057441 s, × 1.1604 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.145235 s, 0.155946 s, +0.010711 s, × 1.0737 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.037606 s, 0.048521 s, +0.010915 s, × 1.2902 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.382439 s, 9.843481 s, +2.461042 s, × 1.3334 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 7.273506 s, 1.465128 s, -5.808378 s, × 0.2014 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.074593 s, 1.374283 s, +0.299690 s, × 1.2789 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 27.746195 s, 5.255158 s, -22.491037 s, × 0.1894 Repo Case Source-Rev Dest-Rev filelog sidedata Difference Factor --------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000906 s, 0.000049 s, -0.000857 s, × 0.054084 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.001832 s, 0.000182 s, -0.001650 s, × 0.099345 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.018101 s, 0.005872 s, -0.012229 s, × 0.324402 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.001508 s, 0.000229 s, -0.001279 s, × 0.151857 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.207438 s, 0.000058 s, -0.207380 s, × 0.000280 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.016956 s, 0.000148 s, -0.016808 s, × 0.008728 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.019129 s, 0.001205 s, -0.017924 s, × 0.062993 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.772050 s, 0.025662 s, -0.746388 s, × 0.033239 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 1.181775 s, 0.080113 s, -1.101662 s, × 0.067790 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 1.255717 s, 0.153030 s, -1.102687 s, × 0.121867 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 1.628132 s, 0.098774 s, -1.529358 s, × 0.060667 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 0.001055 s, 2.780174 s, +2.779119 s, × 2635.236019 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 1.056756 s, 0.022218 s, -1.034538 s, × 0.021025 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 1.354211 s, 0.252125 s, -1.102086 s, × 0.186179 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.027759 s, 0.000186 s, -0.027573 s, × 0.006701 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.133382 s, 0.000133 s, -0.133249 s, × 0.000997 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.025353 s, 0.000320 s, -0.025033 s, × 0.012622 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.052939 s, 0.001336 s, -0.051603 s, × 0.025237 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.037532 s, 0.015573 s, -0.021959 s, × 0.414926 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.195401 s, 0.018667 s, -0.176734 s, × 0.095532 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.939593 s, 0.112534 s, -0.827059 s, × 0.119769 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 3.824967 s, 1.231869 s, -2.593098 s, × 0.322060 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.024626 s, 0.000197 s, -0.024429 s, × 0.008000 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.141098 s, 0.000637 s, -0.140461 s, × 0.004515 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.025973 s, 0.000303 s, -0.025670 s, × 0.011666 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.085098 s, 0.001663 s, -0.083435 s, × 0.019542 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.196623 s, 0.007008 s, -0.189615 s, × 0.035642 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.182911 s, 0.127385 s, -2.055526 s, × 0.058356 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.088865 s, 0.008740 s, -0.080125 s, × 0.098351 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.731211 s, 0.005783 s, -0.725428 s, × 0.007909 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 1.142414 s, 0.102184 s, -1.040230 s, × 0.089446 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.667504 s, 0.046220 s, -6.621284 s, × 0.006932 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 3.267274 s, 0.315271 s, -2.952003 s, × 0.096494 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 16.038104 s, 3.478747 s, -12.559357 s, × 0.216905 mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 20.639928 s, 4.766435 s, -15.873493 s, × 0.230933 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.080513 s, 0.001214 s, -0.079299 s, × 0.015078 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.502965 s, 0.001221 s, -0.501744 s, × 0.002428 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.021408 s, 0.000613 s, -0.020795 s, × 0.028634 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.228498 s, 0.001904 s, -0.226594 s, × 0.008333 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1.118490 s, 0.093000 s, -1.025490 s, × 0.083148 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 2.188390 s, 0.132194 s, -2.056196 s, × 0.060407 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.089755 s, 0.009069 s, -0.080686 s, × 0.101042 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.750223 s, 0.006169 s, -0.744054 s, × 0.008223 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 1.189708 s, 0.115540 s, -1.074168 s, × 0.097116 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.088715 s, 0.435381 s, +0.346666 s, × 4.907637 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.080765 s, 0.415461 s, +0.334696 s, × 5.144072 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 7.487310 s, 0.155946 s, -7.331364 s, × 0.020828 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 6.676682 s, 0.048521 s, -6.628161 s, × 0.007267 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.598509 s, 9.843481 s, +2.244972 s, × 1.295449 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 9.871850 s, 1.465128 s, -8.406722 s, × 0.148415 mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 0.092232 s, killed mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 26.471560 s, 1.374283 s, -25.097277 s, × 0.051915 mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 0.093892 s, killed mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 0.227503 s, killed mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 19.064699 s, 5.255158 s, -13.809541 s, × 0.275649 mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 21.145391 s, killed mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 25.304164 s, killed Differential Revision: https://phab.mercurial-scm.org/D9302
Sun, 29 Nov 2020 00:05:50 +0100 phabricator: use the `http.timeout` config for conduit call
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 29 Nov 2020 00:05:50 +0100] rev 45970
phabricator: use the `http.timeout` config for conduit call Adding some timeout definitely help looping faster through the "bad connection" that I suffer from. So lets make it available. Differential Revision: https://phab.mercurial-scm.org/D9453
Sat, 28 Nov 2020 19:58:37 +0100 phabricator: introduce a `phabricator.retry` option
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 19:58:37 +0100] rev 45969
phabricator: introduce a `phabricator.retry` option For the past 2 days, my connection to phab.mercurial-scm.org became extremely poor. In practice this mean that any conduit call has a fairly high change to hang and die. Giving the amount of call done by the phabricator extension, it means the when I am lucky I can get 1 or 2 Diff to update after a few try, but anything sizeable doesn't have any hope to get through. This changesets introduce a new option for the fabricator extension to try retry failed command itself. So that I can get Diff through. As you can guess, this changeset managed to reach Phabricator thanks to itself. Differential Revision: https://phab.mercurial-scm.org/D9449
Tue, 24 Nov 2020 16:17:16 -0500 packaging: drop Disco (19.04) and add Focal (20.04)
Matt Harbison <matt_harbison@yahoo.com> [Tue, 24 Nov 2020 16:17:16 -0500] rev 45968
packaging: drop Disco (19.04) and add Focal (20.04) Disco support ended in January 2020, and Focal does not have an announced EOL. Something is now installing and configuring `tzdata`, which was throwing up an interactive prompt to configure the timezone. Aside from being hostile to automation, the prompt didn't actually accept input and hung the process. This propagates the host's timezone into the image via environment variable in order to skip the prompt, and avoid hardcoding a value. Differential Revision: https://phab.mercurial-scm.org/D9396
Tue, 24 Nov 2020 14:47:24 -0500 make: drop Trusty and Artful targets
Matt Harbison <matt_harbison@yahoo.com> [Tue, 24 Nov 2020 14:47:24 -0500] rev 45967
make: drop Trusty and Artful targets These were removed from the packaging makefile in 0363bb086c57. Differential Revision: https://phab.mercurial-scm.org/D9395
Tue, 24 Nov 2020 14:03:19 -0500 packaging: add `HG_DOCKER_OWN_USER` to `dockerdeb` like exists in `dockerrpm`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 24 Nov 2020 14:03:19 -0500] rev 45966
packaging: add `HG_DOCKER_OWN_USER` to `dockerdeb` like exists in `dockerrpm` I was getting build failures when it was trying to write to the working directory on CentOS 7 without this. It is basically the same as was added to the RPM builder in 4c0d4bbdc395. For some reason, this doesn't work with Xenial, and the only solution I found was to invoke it with UID 1000 on the host side. It doesn't EOL until April 2024, but it also has python 3.5.2, so this build complication is the least of the problems with supporting it after py2 is dropped. Differential Revision: https://phab.mercurial-scm.org/D9394
Sun, 29 Nov 2020 15:17:14 +0100 heptapod-ci: do not publish changeset when doing the local clone
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 29 Nov 2020 15:17:14 +0100] rev 45965
heptapod-ci: do not publish changeset when doing the local clone Otherwise, checks and script relying on some changeset being draft fails. Differential Revision: https://phab.mercurial-scm.org/D9461
Mon, 02 Nov 2020 19:25:26 +0100 copies-rust: pre-indent some code to clarify the next changeset
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 02 Nov 2020 19:25:26 +0100] rev 45964
copies-rust: pre-indent some code to clarify the next changeset The next changeset will massively rewrite the next function. However having a clear diff on the core semantic of the function will help making the next changesets clearer. So we do most of the churn beforehand. Differential Revision: https://phab.mercurial-scm.org/D9301
Tue, 21 Apr 2020 11:28:48 +0200 copies-rust: use immutable "OrdMap" to store copies information
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Apr 2020 11:28:48 +0200] rev 45963
copies-rust: use immutable "OrdMap" to store copies information The large majority of time is currently spent coping and merging directories. the `IM` crate offer "immutable" Map, that use "copy on write" internally. The new object use the same API as the standard HashMap. So switching to it is trivial and it reduce copying cost significantly. More importantly, using immutable structure will unlock new possibility for a massive speed up of the "merging" part. This will came in a later changesets. Performance wise, we get very significant boost in the worst case. Below is some highlight of how we fare compared to the previous changeset. Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 62.468362 s, 33.527067 s, -28.941295 s, × 0.5367 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 3.619850 s, 0.963905 s, -2.655945 s, × 0.2663 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 11.926587 s, 4.217003 s, -7.709584 s, × 0.3536 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 10.674920 s, 1.114864 s, -9.560056 s, × 0.1044 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 19.647038 s, 1.442793 s, -18.204245 s, × 0.0734 And we sometimes catch up with the performance of the python code as highlighted below: Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.074593 s, 1.442793 s, +0.368200 s, × 1.3426 However, multiple case remains significantly slower, as highlighted below Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.190133 s, 0.963905 s, +0.773772 s, × 5.0696 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.440694 s, 4.217003 s, +3.776309 s, × 9.5690 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.370675 s, 1.114864 s, +0.744189 s, × 3.0077 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 3.581556 s, 33.527067 s, +29.945511 s, × 9.3610 Below are two different tables for full performance comparison - this changeset against the previous one (spoiler: it is much better) - this changeset against the python code (spoiler: still slower, but it gets more comparable) This changeset compared to the previous one =========================================== Repo Cases Source-Rev Dest-Rev Old-Time New-Time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000046 s, 0.000049 s, +0.000003 s, × 1.0652 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000173 s, 0.000179 s, +0.000006 s, × 1.0347 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.006303 s, 0.006494 s, +0.000191 s, × 1.0303 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000229 s, 0.000339 s, +0.000110 s, × 1.4803 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000056 s, 0.000057 s, +0.000001 s, × 1.0179 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000143 s, 0.000299 s, +0.000156 s, × 2.0909 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001166 s, 0.001200 s, +0.000034 s, × 1.0292 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.022931 s, 0.025120 s, +0.002189 s, × 1.0955 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.852446 s, 0.506921 s, -0.345525 s, × 0.5947 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 2.221824 s, 1.272060 s, -0.949764 s, × 0.5725 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 1.194162 s, 0.690941 s, -0.503221 s, × 0.5786 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 62.468362 s, 33.527067 s, -28.941295 s, × 0.5367 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.022116 s, 0.021970 s, -0.000146 s, × 0.9934 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 2.972788 s, 1.772094 s, -1.200694 s, × 0.5961 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000180 s, 0.000185 s, +0.000005 s, × 1.0278 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000123 s, 0.000135 s, +0.000012 s, × 1.0976 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000315 s, 0.000329 s, +0.000014 s, × 1.0444 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001297 s, 0.001343 s, +0.000046 s, × 1.0355 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.024884 s, 0.029396 s, +0.004512 s, × 1.1813 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.032653 s, 0.040210 s, +0.007557 s, × 1.2314 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 4.230118 s, 4.556794 s, +0.326676 s, × 1.0772 mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000197 s, 0.000199 s, +0.000002 s, × 1.0102 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000622 s, 0.000639 s, +0.000017 s, × 1.0273 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000296 s, 0.000542 s, +0.000246 s, × 1.8311 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001626 s, 0.001685 s, +0.000059 s, × 1.0363 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.006218 s, 0.006954 s, +0.000736 s, × 1.1184 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.132760 s, 0.132938 s, +0.000178 s, × 1.0013 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.029001 s, 0.008683 s, -0.020318 s, × 0.2994 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.005886 s, 0.005956 s, +0.000070 s, × 1.0119 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 3.619850 s, 0.963905 s, -2.655945 s, × 0.2663 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.058678 s, 0.049239 s, -0.009439 s, × 0.8391 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 11.926587 s, 4.217003 s, -7.709584 s, × 0.3536 mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001204 s, 0.001197 s, -0.000007 s, × 0.9942 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001217 s, 0.001213 s, -0.000004 s, × 0.9967 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000605 s, 0.000762 s, +0.000157 s, × 1.2595 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001876 s, 0.001909 s, +0.000033 s, × 1.0176 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.078190 s, 0.093021 s, +0.014831 s, × 1.1897 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.135428 s, 0.134536 s, -0.000892 s, × 0.9934 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.029123 s, 0.009071 s, -0.020052 s, × 0.3115 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.006141 s, 0.006206 s, +0.000065 s, × 1.0106 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 4.857827 s, 1.150502 s, -3.707325 s, × 0.2368 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 10.674920 s, 1.114864 s, -9.560056 s, × 0.1044 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 9.789462 s, 1.042658 s, -8.746804 s, × 0.1065 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 1.087890 s, 0.447402 s, -0.640488 s, × 0.4113 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.060556 s, 0.051132 s, -0.009424 s, × 0.8444 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : killed , 83.508590 s mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : killed , 55.079813 s mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 19.647038 s, 1.442793 s, -18.204245 s, × 0.0734 This changeset compared to the Python Code ========================================== Repo Cases Source-Rev Dest-Rev Py-time Rust-time Difference Factor ------------------------------------------------------------------------------------------------------------------------------------ mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 0.000044 s, 0.000049 s, +0.000005 s, × 1.1136 mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 0.000138 s, 0.000179 s, +0.000041 s, × 1.2971 mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 0.005052 s, 0.006494 s, +0.001442 s, × 1.2854 pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 0.000219 s, 0.000339 s, +0.000120 s, × 1.5479 pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 0.000055 s, 0.000057 s, +0.000002 s, × 1.0364 pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 0.000128 s, 0.000299 s, +0.000171 s, × 2.3359 pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 0.001089 s, 0.001200 s, +0.000111 s, × 1.1019 pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 0.017407 s, 0.025120 s, +0.007713 s, × 1.4431 pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 0.094175 s, 0.506921 s, +0.412746 s, × 5.3828 pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 0.238009 s, 1.272060 s, +1.034051 s, × 5.3446 pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 0.125876 s, 0.690941 s, +0.565065 s, × 5.4891 pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 3.581556 s, 33.527067 s, +29.945511 s, × 9.3610 pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 0.016721 s, 0.021970 s, +0.005249 s, × 1.3139 pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 0.242367 s, 1.772094 s, +1.529727 s, × 7.3116 netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 0.000165 s, 0.000185 s, +0.000020 s, × 1.1212 netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 0.000114 s, 0.000135 s, +0.000021 s, × 1.1842 netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 0.000296 s, 0.000329 s, +0.000033 s, × 1.1115 netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 0.001124 s, 0.001343 s, +0.000219 s, × 1.1948 netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 0.013060 s, 0.029396 s, +0.016336 s, × 2.2508 netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 0.017112 s, 0.040210 s, +0.023098 s, × 2.3498 netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 0.660350 s, 4.556794 s, +3.896444 s, × 6.9006 netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 10.032499 s, killed mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 0.000189 s, 0.000199 s, +0.000010 s, × 1.0529 mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 0.000462 s, 0.000639 s, +0.000177 s, × 1.3831 mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 0.000270 s, 0.000542 s, +0.000272 s, × 2.0074 mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 0.001474 s, 0.001685 s, +0.000211 s, × 1.1431 mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 0.004806 s, 0.006954 s, +0.002148 s, × 1.4469 mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.085150 s, 0.132938 s, +0.047788 s, × 1.5612 mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007064 s, 0.008683 s, +0.001619 s, × 1.2292 mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004741 s, 0.005956 s, +0.001215 s, × 1.2563 mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 0.190133 s, 0.963905 s, +0.773772 s, × 5.0696 mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.035651 s, 0.049239 s, +0.013588 s, × 1.3811 mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 0.440694 s, 4.217003 s, +3.776309 s, × 9.5690 mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 18.454163 s, killed mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 31.562719 s, killed mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 0.001189 s, 0.001197 s, +0.000008 s, × 1.0067 mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 0.001204 s, 0.001213 s, +0.000009 s, × 1.0075 mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 0.000586 s, 0.000762 s, +0.000176 s, × 1.3003 mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 0.001845 s, 0.001909 s, +0.000064 s, × 1.0347 mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 0.063822 s, 0.093021 s, +0.029199 s, × 1.4575 mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 0.088038 s, 0.134536 s, +0.046498 s, × 1.5282 mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 0.007389 s, 0.009071 s, +0.001682 s, × 1.2276 mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 0.004868 s, 0.006206 s, +0.001338 s, × 1.2749 mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 0.222450 s, 1.150502 s, +0.928052 s, × 5.1720 mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 0.370675 s, 1.114864 s, +0.744189 s, × 3.0077 mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 0.358020 s, 1.042658 s, +0.684638 s, × 2.9123 mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 0.145235 s, 0.447402 s, +0.302167 s, × 3.0805 mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 0.037606 s, 0.051132 s, +0.013526 s, × 1.3597 mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 7.382439 s, 83.508590 s, +76.126151 s, × 11.3118 mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 7.273506 s, 55.079813 s, +47.806307 s, × 7.5727 mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 1.074593 s, 1.442793 s, +0.368200 s, × 1.3426 mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 27.746195 s, killed Differential Revision: https://phab.mercurial-scm.org/D9300
Thu, 01 Oct 2020 18:52:13 +0200 copies: use the rust code for `combine_changeset_copies`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Oct 2020 18:52:13 +0200] rev 45962
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
Wed, 18 Sep 2019 13:21:38 +0200 tests: simplify and extend pull-bundle test using debugbuilddag
Joerg Sonnenberger <joerg@bec.de> [Wed, 18 Sep 2019 13:21:38 +0200] rev 45961
tests: simplify and extend pull-bundle test using debugbuilddag Differential Revision: https://phab.mercurial-scm.org/D9443
Sat, 28 Nov 2020 00:25:04 -0500 helptext: document the mechanism for extensions to report a version
Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Nov 2020 00:25:04 -0500] rev 45960
helptext: document the mechanism for extensions to report a version Differential Revision: https://phab.mercurial-scm.org/D9448
Sat, 28 Nov 2020 13:42:55 +0100 heptapod-ci: add a explicite "test" phases
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 13:42:55 +0100] rev 45959
heptapod-ci: add a explicite "test" phases We are about to add more stage Differential Revision: https://phab.mercurial-scm.org/D9454
Sat, 28 Nov 2020 17:23:50 +0100 test: fix some expect output in a traceback
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 17:23:50 +0100] rev 45958
test: fix some expect output in a traceback The lines moved around because of 89a2afe31e82. Differential Revision: https://phab.mercurial-scm.org/D9447
Sat, 28 Nov 2020 16:35:20 +0530 help: fix a grammar/typo in hg help dates
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 28 Nov 2020 16:35:20 +0530] rev 45957
help: fix a grammar/typo in hg help dates Differential Revision: https://phab.mercurial-scm.org/D9442
Sat, 28 Nov 2020 14:29:50 +0100 rust: fix non-utf8 char in requirements.rs
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 28 Nov 2020 14:29:50 +0100] rev 45956
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
Sun, 29 Nov 2020 19:17:35 +0530 run-tests: use a context manager when looking for available ports
Matt Harbison <matt_harbison@yahoo.com> [Sun, 29 Nov 2020 19:17:35 +0530] rev 45955
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
Fri, 27 Nov 2020 15:54:46 -0500 dispatch: print the version of each extension in the bug report, if available
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 15:54:46 -0500] rev 45954
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
Fri, 27 Nov 2020 15:45:37 -0500 dispatch: sort the loaded extension names in the bug report
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 15:45:37 -0500] rev 45953
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
Fri, 27 Nov 2020 15:39:27 -0500 dispatch: quote the extension when printing the bug report
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 15:39:27 -0500] rev 45952
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
Fri, 27 Nov 2020 14:31:59 -0500 dispatch: print the version of the extension being blamed in a bug report
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 14:31:59 -0500] rev 45951
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
Thu, 26 Nov 2020 15:09:57 -0500 git: show the version of `pygit2` with verbose version output
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 15:09:57 -0500] rev 45950
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
Fri, 27 Nov 2020 15:17:42 -0500 git: add the standard `testedwith` attribute
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 15:17:42 -0500] rev 45949
git: add the standard `testedwith` attribute Otherwise this shows up as an external extension. Differential Revision: https://phab.mercurial-scm.org/D9435
Fri, 27 Nov 2020 15:00:39 -0500 tests: add a comment that we're purposely testing py2 extension attributes
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 15:00:39 -0500] rev 45948
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
Fri, 27 Nov 2020 14:54:37 -0500 extensions: avoid a crash when the version isn't properly byteified on py3
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 14:54:37 -0500] rev 45947
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
Fri, 27 Nov 2020 19:35:37 -0500 formatting: drop a few extra double quotes in docstrings
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 19:35:37 -0500] rev 45946
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
Thu, 01 Oct 2020 18:51:40 +0200 copies: introduce the hg-cpython wrapper for `combine_changeset_copies`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Oct 2020 18:51:40 +0200] rev 45945
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
Thu, 01 Oct 2020 18:51:06 +0200 copies: introduce a basic Rust function for `combine_changeset_copies`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Oct 2020 18:51:06 +0200] rev 45944
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
Fri, 27 Nov 2020 17:11:56 -0500 hghave: adjust the detection of `pylint` for modern versions
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 17:11:56 -0500] rev 45943
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
Fri, 27 Nov 2020 17:03:29 -0500 formating: upgrade to black 20.8b1
Augie Fackler <raf@durin42.com> [Fri, 27 Nov 2020 17:03:29 -0500] rev 45942
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
Fri, 27 Nov 2020 17:00:00 -0500 osutil: reformat triple-quoted string so black doesn't confuse itself
Augie Fackler <raf@durin42.com> [Fri, 27 Nov 2020 17:00:00 -0500] rev 45941
osutil: reformat triple-quoted string so black doesn't confuse itself Differential Revision: https://phab.mercurial-scm.org/D9429
Fri, 27 Nov 2020 16:59:14 -0500 merge: remove spurious ' and trailing whitespace from triple-quoted string
Augie Fackler <raf@durin42.com> [Fri, 27 Nov 2020 16:59:14 -0500] rev 45940
merge: remove spurious ' and trailing whitespace from triple-quoted string Differential Revision: https://phab.mercurial-scm.org/D9428
Fri, 27 Nov 2020 17:00:25 -0500 cleanup: fix a few recent black formatting violations
Matt Harbison <matt_harbison@yahoo.com> [Fri, 27 Nov 2020 17:00:25 -0500] rev 45939
cleanup: fix a few recent black formatting violations Differential Revision: https://phab.mercurial-scm.org/D9427
Wed, 25 Nov 2020 12:33:37 +0100 rhg: check that .hg/requires is ASCII
Simon Sapin <simon-commits@exyr.org> [Wed, 25 Nov 2020 12:33:37 +0100] rev 45938
rhg: check that .hg/requires is ASCII Differential Revision: https://phab.mercurial-scm.org/D9400
Tue, 24 Nov 2020 18:52:38 +0100 rhg: exit with relevant code for unsupported requirements
Simon Sapin <simon-commits@exyr.org> [Tue, 24 Nov 2020 18:52:38 +0100] rev 45937
rhg: exit with relevant code for unsupported requirements Differential Revision: https://phab.mercurial-scm.org/D9399
Tue, 06 Oct 2020 03:25:15 +0200 revlog: store new index entries as binary
Joerg Sonnenberger <joerg@bec.de> [Tue, 06 Oct 2020 03:25:15 +0200] rev 45936
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
Wed, 11 Nov 2020 20:44:45 +0100 packaging: enable rust extensions on centos
Mathias De Mare <mathias.de_mare@nokia.com> [Wed, 11 Nov 2020 20:44:45 +0100] rev 45935
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
Sat, 21 Nov 2020 22:46:09 -0500 tests: use `testrepohg` in one more place in test-check-code.t
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 22:46:09 -0500] rev 45934
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
Sat, 21 Nov 2020 16:20:49 -0500 setup: copy pythonXY.dll next to the hg.exe wrapper when building
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 16:20:49 -0500] rev 45933
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
Sun, 22 Nov 2020 15:07:09 -0500 exthelper: update the examples to be python3 complaint
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Nov 2020 15:07:09 -0500] rev 45932
exthelper: update the examples to be python3 complaint Differential Revision: https://phab.mercurial-scm.org/D9368
Sun, 22 Nov 2020 14:55:40 -0500 helptext: byteify extensions examples
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Nov 2020 14:55:40 -0500] rev 45931
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
Sun, 22 Nov 2020 14:53:17 -0500 helptext: fix sentence in extensions documentation
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Nov 2020 14:53:17 -0500] rev 45930
helptext: fix sentence in extensions documentation Differential Revision: https://phab.mercurial-scm.org/D9366
Mon, 23 Nov 2020 11:47:06 -0500 ui: ensure `getpass()` returns bytes
Matt Harbison <matt_harbison@yahoo.com> [Mon, 23 Nov 2020 11:47:06 -0500] rev 45929
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
Thu, 26 Nov 2020 02:28:42 -0500 packaging: regenerate the Windows requirements manifest on Windows
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 02:28:42 -0500] rev 45928
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
Thu, 26 Nov 2020 03:09:56 -0500 pyoxidizer: point to the py3 requirements instead of py2 on Windows
Matt Harbison <matt_harbison@yahoo.com> [Thu, 26 Nov 2020 03:09:56 -0500] rev 45927
pyoxidizer: point to the py3 requirements instead of py2 on Windows Differential Revision: https://phab.mercurial-scm.org/D9406
Wed, 25 Nov 2020 22:38:23 -0500 git: update test for hg and git output changes
Augie Fackler <raf@durin42.com> [Wed, 25 Nov 2020 22:38:23 -0500] rev 45926
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
Wed, 25 Nov 2020 22:23:23 -0500 gitlog: add tiprev() function
Augie Fackler <raf@durin42.com> [Wed, 25 Nov 2020 22:23:23 -0500] rev 45925
gitlog: add tiprev() function Lots of stuff was broken because this was missing. Differential Revision: https://phab.mercurial-scm.org/D9402
Tue, 24 Nov 2020 17:49:16 +0100 requirements: move loading to hg-core and add parsing
Simon Sapin <simon-commits@exyr.org> [Tue, 24 Nov 2020 17:49:16 +0100] rev 45924
requirements: move loading to hg-core and add parsing No functional change, checking comes later. Differential Revision: https://phab.mercurial-scm.org/D9398
Tue, 24 Nov 2020 15:11:58 +0100 rhg: add a `debugrequirements` subcommand
Simon Sapin <simon-commits@exyr.org> [Tue, 24 Nov 2020 15:11:58 +0100] rev 45923
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
Wed, 25 Nov 2020 11:08:28 -0500 pyoxidizer: make sure defaultrc directory exists before trying to write to it
Augie Fackler <augie@google.com> [Wed, 25 Nov 2020 11:08:28 -0500] rev 45922
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
Sat, 21 Nov 2020 13:30:50 +0530 commands: fix checking of share safe requirement on `config --shared`
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 21 Nov 2020 13:30:50 +0530] rev 45921
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
Fri, 20 Nov 2020 14:34:15 +0530 dispatch: pass root path in ui.readconfig() as root of main repo
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 20 Nov 2020 14:34:15 +0530] rev 45920
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
Fri, 16 Oct 2020 19:03:09 +0530 scmutil: try-delete `.hg/store/requires` if store requirements are empty
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 16 Oct 2020 19:03:09 +0530] rev 45919
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
Mon, 23 Nov 2020 10:39:51 -0800 errors: raise InputError on bad top-level flags
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 10:39:51 -0800] rev 45918
errors: raise InputError on bad top-level flags Differential Revision: https://phab.mercurial-scm.org/D9388
Mon, 23 Nov 2020 23:08:58 -0800 errors: raise StateError on uncommitted changes when merge starts
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 23:08:58 -0800] rev 45917
errors: raise StateError on uncommitted changes when merge starts Differential Revision: https://phab.mercurial-scm.org/D9393
Mon, 23 Nov 2020 16:48:13 -0800 errors: raise StateError when there are unresolves merge conflicts
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 16:48:13 -0800] rev 45916
errors: raise StateError when there are unresolves merge conflicts Differential Revision: https://phab.mercurial-scm.org/D9392
Mon, 23 Nov 2020 16:20:02 -0800 errors: introduce SecurityError and use it in a few places
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 16:20:02 -0800] rev 45915
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
Mon, 23 Nov 2020 16:05:03 -0800 errors: raise InputError when too few arguments given to alias
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 16:05:03 -0800] rev 45914
errors: raise InputError when too few arguments given to alias Differential Revision: https://phab.mercurial-scm.org/D9389
Tue, 17 Nov 2020 16:32:03 -0800 errors: raise InputError on bad bookmark argument
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Nov 2020 16:32:03 -0800] rev 45913
errors: raise InputError on bad bookmark argument Differential Revision: https://phab.mercurial-scm.org/D9385
Mon, 23 Nov 2020 12:27:22 -0800 errors: raise ConfigError on bad alias definition
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 12:27:22 -0800] rev 45912
errors: raise ConfigError on bad alias definition Differential Revision: https://phab.mercurial-scm.org/D9384
Mon, 23 Nov 2020 10:42:03 -0800 errors: raise InputError on bad repo arguments
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 10:42:03 -0800] rev 45911
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
Mon, 23 Nov 2020 14:48:05 -0800 errors: drop trailing "!" for some errors about bookmarks
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 14:48:05 -0800] rev 45910
errors: drop trailing "!" for some errors about bookmarks Differential Revision: https://phab.mercurial-scm.org/D9382
Mon, 23 Nov 2020 12:47:08 -0800 errors: remove trailing "!" in messages about bad top-level args
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 12:47:08 -0800] rev 45909
errors: remove trailing "!" in messages about bad top-level args Differential Revision: https://phab.mercurial-scm.org/D9381
Mon, 23 Nov 2020 12:42:57 -0800 errors: remove trailing "!" in messages about creating new heads on push
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 12:42:57 -0800] rev 45908
errors: remove trailing "!" in messages about creating new heads on push Differential Revision: https://phab.mercurial-scm.org/D9380
Mon, 23 Nov 2020 12:31:53 -0800 errors: consistently don't use trailing "!" in "not found in manifest" message
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 12:31:53 -0800] rev 45907
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
Mon, 23 Nov 2020 11:18:48 -0800 errors: remove trailing "!" from some error messages for consistency
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 11:18:48 -0800] rev 45906
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
Mon, 23 Nov 2020 12:20:19 +0100 bisect: use tuple literal instead of split on string literal
Simon Sapin <simon-commits@exyr.org> [Mon, 23 Nov 2020 12:20:19 +0100] rev 45905
bisect: use tuple literal instead of split on string literal Differential Revision: https://phab.mercurial-scm.org/D9371
Mon, 23 Nov 2020 11:58:52 +0100 hgignore: add VS Code config
Simon Sapin <simon-commits@exyr.org> [Mon, 23 Nov 2020 11:58:52 +0100] rev 45904
hgignore: add VS Code config Differential Revision: https://phab.mercurial-scm.org/D9370
Mon, 23 Nov 2020 11:56:10 -0800 tests: make test-worker.t pass on py2
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 11:56:10 -0800] rev 45903
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
Mon, 23 Nov 2020 11:30:43 -0800 tests: update test-https.t's #no-defaultcacertsloaded block with new exit code
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 11:30:43 -0800] rev 45902
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
Sun, 22 Nov 2020 23:53:09 +0530 chg: fix test-check-clang-format.t failure
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 22 Nov 2020 23:53:09 +0530] rev 45901
chg: fix test-check-clang-format.t failure Differential Revision: https://phab.mercurial-scm.org/D9365
Tue, 17 Nov 2020 21:30:50 -0500 log: add bookmark option to "hg log"
Sebastien Boisvert <sebhtml@protonmail.com> [Tue, 17 Nov 2020 21:30:50 -0500] rev 45900
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
Sat, 21 Nov 2020 16:55:07 -0500 extensions: gracefully warn when doing min version check with no local version
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 16:55:07 -0500] rev 45899
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
Sat, 21 Nov 2020 15:34:54 -0500 make: switch the PYTHON default to `py.exe -3` on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Nov 2020 15:34:54 -0500] rev 45898
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
Fri, 20 Nov 2020 21:06:38 +0100 heptapod-ci: hosting base image on registry.heptapod.net
Georges Racinet <georges.racinet@octobus.net> [Fri, 20 Nov 2020 21:06:38 +0100] rev 45897
heptapod-ci: hosting base image on registry.heptapod.net We are now touching the rate limits of Docker Hub.
Fri, 20 Nov 2020 07:37:09 +0100 context: small update to ctx.status doc
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 07:37:09 +0100] rev 45896
context: small update to ctx.status doc The order of the "arguments" were not too clear, so we update the documentation to clarify that.
Mon, 16 Nov 2020 16:00:50 -0800 errors: use exit code 10 for parse errors
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 16:00:50 -0800] rev 45895
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
Fri, 20 Nov 2020 14:43:21 -0800 errors: raise ConfigError on failure to parse config file
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 14:43:21 -0800] rev 45894
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
Mon, 16 Nov 2020 10:56:54 -0800 histedit: don't crash if commit message is empty
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 10:56:54 -0800] rev 45893
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
Mon, 02 Nov 2020 11:03:56 +0100 copies: cache the ancestor checking call when tracing copy
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 02 Nov 2020 11:03:56 +0100] rev 45892
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
Fri, 20 Nov 2020 10:34:26 -0800 errors: remove ParseError.args
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 10:34:26 -0800] rev 45891
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
Fri, 20 Nov 2020 13:55:32 -0800 errors: let ParseError use Abort.__bytes__
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 13:55:32 -0800] rev 45890
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
Fri, 20 Nov 2020 10:31:56 -0800 config: clean up message about ignored untrusted config
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 10:31:56 -0800] rev 45889
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
Fri, 20 Nov 2020 10:22:58 -0800 tests: use new ParseError.format() in test-trusted.py
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 10:22:58 -0800] rev 45888
tests: use new ParseError.format() in test-trusted.py Differential Revision: https://phab.mercurial-scm.org/D9351
Thu, 19 Nov 2020 15:13:39 -0800 errors: make ParseError a subtype of Abort
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Nov 2020 15:13:39 -0800] rev 45887
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
Fri, 20 Nov 2020 13:24:45 -0800 tests: make doctests not depend on str(ParseError()) format
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 13:24:45 -0800] rev 45886
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
Fri, 20 Nov 2020 09:17:38 -0800 errors: format "abort: " text in a new Abort.format() method
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 09:17:38 -0800] rev 45885
errors: format "abort: " text in a new Abort.format() method This remove some duplication we had. Differential Revision: https://phab.mercurial-scm.org/D9348
Fri, 20 Nov 2020 08:51:45 -0800 errors: make formatparse() an instance method on ParseError
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Nov 2020 08:51:45 -0800] rev 45884
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
Thu, 19 Nov 2020 11:23:59 -0800 errors: create "similarity hint" for UnknownIdentifier eagerly in constructor
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Nov 2020 11:23:59 -0800] rev 45883
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
Thu, 19 Nov 2020 12:20:26 -0800 errors: move similarity_hint() to error module
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Nov 2020 12:20:26 -0800] rev 45882
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
Thu, 19 Nov 2020 09:19:44 -0800 errors: morph reportsimilar() into similarity_hint()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Nov 2020 09:19:44 -0800] rev 45881
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
Thu, 19 Nov 2020 10:29:06 -0800 errors: restructure formatparse() to clarify conditions a bit
Martin von Zweigbergk <martinvonz@google.com> [Thu, 19 Nov 2020 10:29:06 -0800] rev 45880
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
Thu, 19 Nov 2020 14:55:55 -0500 pyoxidizer: run buildifier
Augie Fackler <augie@google.com> [Thu, 19 Nov 2020 14:55:55 -0500] rev 45879
pyoxidizer: run buildifier Differential Revision: https://phab.mercurial-scm.org/D9342
Tue, 17 Nov 2020 16:23:57 -0800 errors: raise InputError in `hg absorb`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Nov 2020 16:23:57 -0800] rev 45878
errors: raise InputError in `hg absorb` Differential Revision: https://phab.mercurial-scm.org/D9340
Thu, 22 Oct 2020 14:14:59 -0700 errors: introduce CanceledError and use it in a few places
Martin von Zweigbergk <martinvonz@google.com> [Thu, 22 Oct 2020 14:14:59 -0700] rev 45877
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
Tue, 17 Nov 2020 15:51:09 -0800 errors: raise InputError in `hg split`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Nov 2020 15:51:09 -0800] rev 45876
errors: raise InputError in `hg split` Differential Revision: https://phab.mercurial-scm.org/D9338
Tue, 17 Nov 2020 15:42:42 -0800 errors: raise StateError in `hg bisect`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Nov 2020 15:42:42 -0800] rev 45875
errors: raise StateError in `hg bisect` Differential Revision: https://phab.mercurial-scm.org/D9337
Tue, 17 Nov 2020 15:37:18 -0800 errors: raise InputError in `hg debugobsolete`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Nov 2020 15:37:18 -0800] rev 45874
errors: raise InputError in `hg debugobsolete` Differential Revision: https://phab.mercurial-scm.org/D9336
Mon, 16 Nov 2020 16:25:04 -0800 errors: raise InputError when line range to followlines() is out of bounds
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 16:25:04 -0800] rev 45873
errors: raise InputError when line range to followlines() is out of bounds Differential Revision: https://phab.mercurial-scm.org/D9333
Sat, 07 Nov 2020 22:31:29 +0100 transaction: split new files into a separate set
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Nov 2020 22:31:29 +0100] rev 45872
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
Sat, 07 Nov 2020 21:34:09 +0100 transaction: change list of journal entries into a dictionary
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Nov 2020 21:34:09 +0100] rev 45871
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
Sat, 07 Nov 2020 19:24:12 +0100 transaction: rename find to findoffset and drop backup file support
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Nov 2020 19:24:12 +0100] rev 45870
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
Sat, 07 Nov 2020 17:56:01 +0100 transaction: drop per-file extra data support
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Nov 2020 17:56:01 +0100] rev 45869
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
Thu, 12 Nov 2020 14:07:34 -0800 templates: define a {onelinesummary} keyword
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 14:07:34 -0800] rev 45868
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
Fri, 30 Oct 2020 12:46:38 -0700 relnotes: document new [command-templates] section
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Oct 2020 12:46:38 -0700] rev 45867
relnotes: document new [command-templates] section Differential Revision: https://phab.mercurial-scm.org/D9266
Fri, 30 Oct 2020 13:26:18 -0700 help: document the new [command-templates] config section
Martin von Zweigbergk <martinvonz@google.com> [Fri, 30 Oct 2020 13:26:18 -0700] rev 45866
help: document the new [command-templates] config section Differential Revision: https://phab.mercurial-scm.org/D9265
Sun, 08 Nov 2020 16:23:35 -0500 strip: move into core
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 08 Nov 2020 16:23:35 -0500] rev 45865
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
Sat, 07 Nov 2020 16:36:19 -0800 revlog: pass sidedata argument to flagutil.processflagswrite()
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Nov 2020 16:36:19 -0800] rev 45864
revlog: pass sidedata argument to flagutil.processflagswrite() Bug found through pytype. Differential Revision: https://phab.mercurial-scm.org/D9280
Sat, 07 Nov 2020 16:45:58 -0800 pure: guard against empty blocks
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Nov 2020 16:45:58 -0800] rev 45863
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
Mon, 16 Nov 2020 16:38:57 +0100 rust-status: don't bubble up os errors, translate them to bad matches
Raphaël Gomès <rgomes@octobus.net> [Mon, 16 Nov 2020 16:38:57 +0100] rev 45862
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
Mon, 16 Nov 2020 16:36:00 +0100 rust-status: properly translate OSError to Python
Raphaël Gomès <rgomes@octobus.net> [Mon, 16 Nov 2020 16:36:00 +0100] rev 45861
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
Mon, 16 Nov 2020 21:28:42 -0800 shelve: clear merge state after partial shelve
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 21:28:42 -0800] rev 45860
shelve: clear merge state after partial shelve Differential Revision: https://phab.mercurial-scm.org/D9335
Mon, 16 Nov 2020 22:38:36 -0800 tests: show that interactive shelve can leave the repo with a merge state
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 22:38:36 -0800] rev 45859
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
Mon, 16 Nov 2020 10:30:53 -0800 histedit: disable color while rendering template for use in plan
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 10:30:53 -0800] rev 45858
histedit: disable color while rendering template for use in plan Differential Revision: https://phab.mercurial-scm.org/D9324
Mon, 16 Nov 2020 10:30:06 -0800 tests: show how `hg histedit` can put color codes in histedit plan
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 10:30:06 -0800] rev 45857
tests: show how `hg histedit` can put color codes in histedit plan Differential Revision: https://phab.mercurial-scm.org/D9323
Fri, 13 Nov 2020 09:41:49 -0800 split: disable color while rendering template for use in commit message
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Nov 2020 09:41:49 -0800] rev 45856
split: disable color while rendering template for use in commit message Differential Revision: https://phab.mercurial-scm.org/D9322
Thu, 12 Nov 2020 17:06:45 -0800 tests: show how `hg split` can put color codes in commit template
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 17:06:45 -0800] rev 45855
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
Mon, 16 Nov 2020 16:00:13 -0800 dispatch: move some helper functions down into scmutil
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 16:00:13 -0800] rev 45854
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
Mon, 16 Nov 2020 15:11:51 -0800 errors: raise more specific errors from rewriteutil
Martin von Zweigbergk <martinvonz@google.com> [Mon, 16 Nov 2020 15:11:51 -0800] rev 45853
errors: raise more specific errors from rewriteutil Differential Revision: https://phab.mercurial-scm.org/D9330
Tue, 17 Nov 2020 19:29:08 +0900 chgserver: backport py3 buffered I/O workarounds from procutil
Yuya Nishihara <yuya@tcha.org> [Tue, 17 Nov 2020 19:29:08 +0900] rev 45852
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.
Tue, 03 Nov 2020 11:24:21 +0900 chg: reset errno prior to calling strtol() stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:24:21 +0900] rev 45851
chg: reset errno prior to calling strtol() Otherwise we can't figure out if the last strtol() invocation failed or not.
Tue, 03 Nov 2020 11:15:50 +0900 chg: do not close dir fd while iterating stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:15:50 +0900] rev 45850
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.
Tue, 03 Nov 2020 11:12:25 +0900 chg: show debug message for each fd to be closed stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:12:25 +0900] rev 45849
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.
Tue, 03 Nov 2020 11:06:15 +0900 chg: apply clang-format stable
Yuya Nishihara <yuya@tcha.org> [Tue, 03 Nov 2020 11:06:15 +0900] rev 45848
chg: apply clang-format
Thu, 12 Nov 2020 15:28:06 -0800 errors: use InputError for some errors on `hg clone`
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 15:28:06 -0800] rev 45847
errors: use InputError for some errors on `hg clone` Differential Revision: https://phab.mercurial-scm.org/D9329
Thu, 12 Nov 2020 13:22:40 -0800 errors: raise InputError when given non-existent paths etc
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Nov 2020 13:22:40 -0800] rev 45846
errors: raise InputError when given non-existent paths etc Differential Revision: https://phab.mercurial-scm.org/D9328
(0) -30000 -10000 -3000 -1000 -192 +192 +1000 +3000 tip