Mon, 23 Nov 2020 16:39:53 -0800 errors: raise StateError when push fails because it creates new heads
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 16:39:53 -0800] rev 46120
errors: raise StateError when push fails because it creates new heads I decided to raise `StateError` here because the local and remote repos are in an incompatible state. I think remote errors (exit code 100) should be when something goes wrong on the remote and there's nothing the user can do. Differential Revision: https://phab.mercurial-scm.org/D9391
Mon, 23 Nov 2020 10:38:05 -0800 errors: raise InputError on early parse error in dispatch
Martin von Zweigbergk <martinvonz@google.com> [Mon, 23 Nov 2020 10:38:05 -0800] rev 46119
errors: raise InputError on early parse error in dispatch I didn't think this would have any effect on the tests, but it does because the catching in `scmutil.callcatch()` still happens. That's because `dispatch` passes in the function that includes the parsing as an argument to that function. I initially used `ConfigError` here but Matt Harbison convinced me to use `InputError`. I think that makes sense since error is not in a config file. Differential Revision: https://phab.mercurial-scm.org/D9387
Wed, 18 Nov 2020 23:37:09 -0800 errors: raise more specifc errors from narrowcommands
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Nov 2020 23:37:09 -0800] rev 46118
errors: raise more specifc errors from narrowcommands Differential Revision: https://phab.mercurial-scm.org/D9386
Wed, 09 Dec 2020 19:40:30 -0800 errors: use detailed exit code 50 for StorageError
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 19:40:30 -0800] rev 46117
errors: use detailed exit code 50 for StorageError This is done as part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9601
Wed, 09 Dec 2020 20:22:25 -0800 errors: raise InputError if an ambiguous revision id prefix is used
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 20:22:25 -0800] rev 46116
errors: raise InputError if an ambiguous revision id prefix is used It's long bothered me that we include the "00changelog.i" part in a message to the user. This fixes that along with the exit code. Differential Revision: https://phab.mercurial-scm.org/D9600
Thu, 10 Dec 2020 01:18:15 -0800 localrepo: delete obsolete comment about `prefix in repo` raising exception
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 01:18:15 -0800] rev 46115
localrepo: delete obsolete comment about `prefix in repo` raising exception We dropped support for `prefix in repo`, where `prefix` is a hex prefix, in 8b86acc7aa64 (context: drop support for looking up context by ambiguous changeid (API), 2018-04-28), after having deprecated it a while before that. These days you get a `ProgrammingError` instead if you pass in a short nodeid. Differential Revision: https://phab.mercurial-scm.org/D9599
Tue, 01 Dec 2020 21:54:46 +0100 node: import symbols explicitly
Joerg Sonnenberger <joerg@bec.de> [Tue, 01 Dec 2020 21:54:46 +0100] rev 46114
node: import symbols explicitly There is no point in lazy importing mercurial.node, it is used all over the place anyway. So consistently import the used symbols directly. Fix one file using symbols indirectly via mercurial.revlog. Differential Revision: https://phab.mercurial-scm.org/D9480
Sun, 13 Dec 2020 18:29:22 -0800 branching: merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 13 Dec 2020 18:29:22 -0800] rev 46113
branching: merge with stable
Fri, 11 Dec 2020 15:25:11 +0100 debugdiscovery: fix swapped heads and roots
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 15:25:11 +0100] rev 46112
debugdiscovery: fix swapped heads and roots Patch provided without comment… Differential Revision: https://phab.mercurial-scm.org/D9566
Fri, 11 Dec 2020 12:51:09 +0100 debugdiscovery: display the number of roundtrip used
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 11 Dec 2020 12:51:09 +0100] rev 46111
debugdiscovery: display the number of roundtrip used This is a good metric of the complexity of a discovery process. Differential Revision: https://phab.mercurial-scm.org/D9565
Fri, 11 Dec 2020 13:39:56 -0800 copies: make calculating lazy for dir move detection's "addedfiles"
Kyle Lippincott <spectral@google.com> [Fri, 11 Dec 2020 13:39:56 -0800] rev 46110
copies: make calculating lazy for dir move detection's "addedfiles" The information calculated here was only needed if (a) --debug was specified, or (b) a directory move was plausibly detected. With tree manifests (especially in my pathological repo and with our custom setup), pre-calculating the `u1` and `u2` can be quite slow, and it's not even necessary in many cases. Let's delay calculating it until we know it's actually necessary. This should have no observable differences in output. ### Performance I ran a rebase command in my pathological repo, rebasing two nodes across several public phase commits, but where no directory copies exist in any of the paths I'm tracking. #### Before ``` Time (mean ± σ): 3.711 s ± 0.061 s [User: 0.3 ms, System: 1.5 ms] Range (min … max): 3.640 s … 3.827 s 10 runs ``` #### After ``` Time (mean ± σ): 868.3 ms ± 10.1 ms [User: 0.5 ms, System: 1.2 ms] Range (min … max): 856.6 ms … 883.6 ms 10 runs ``` Differential Revision: https://phab.mercurial-scm.org/D9567
Tue, 08 Dec 2020 16:45:13 -0800 mergetools: add new conflict marker format with diffs in
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 16:45:13 -0800] rev 46109
mergetools: add new conflict marker format with diffs in I use 3-way conflict markers. Often when I resolve them, I manually compare one the base with one side and apply the differences to the other side. That can be hard when the conflict marker is large. This patch introduces a new type of conflict marker, which I'm hoping will make it easier to resolve conflicts. The new format uses `<<<<<<<` and `>>>>>>>` to open and close the markers, just like our existing 2-way and 3-way conflict markers. Instead of having 2 or 3 snapshots (left+right or left+base+right), it has a sequence of diffs. A diff looks like this: ``` ------- base +++++++ left a -b +c d ``` A diff that adds one side ("diff from nothing") has a `=======` header instead and does not have have `+` prefixed on its lines. A regular 3-way merge can be viewed as adding one side plus a diff between the base and the other side. It thus has two ways of being represented, depending on which side is being diffed: ``` <<<<<<< ======= left contents on left ------- base +++++++ right contents on -left +right >>>>>>> ``` or ``` <<<<<<< ------- base +++++++ left contents on -right +left ======= right contents on right >>>>>>> ``` I've made it so the new merge tool tries to pick a version that has the most common lines (no difference in the example above). I've called the new tool "mergediff" to stick to the convention of starting with "merge" if the tool tries a regular 3-way merge. The idea came from my pet VCS (placeholder name `jj`), which has support for octopus merges and other ways of ending up with merges of more than 3 versions. I wanted to be able to represent such conflicts in the working copy and therefore thought of this format (although I have not yet implemented it in my VCS). I then attended a meeting with Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for showing a similar format, which reminded me to actually attempt this in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D9551
Thu, 10 Dec 2020 14:39:22 -0800 diff: deprecate -r option
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 14:39:22 -0800] rev 46108
diff: deprecate -r option The new `--from`/`--to` options should be enough to support all the uses cases and are easier to understand, so there is no reason that I'm aware of to use `-r` anymore. Differential Revision: https://phab.mercurial-scm.org/D9564
Thu, 10 Dec 2020 12:06:55 -0800 diff: update synopsis to use --from/--to instead of -r
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:06:55 -0800] rev 46107
diff: update synopsis to use --from/--to instead of -r Differential Revision: https://phab.mercurial-scm.org/D9563
Thu, 10 Dec 2020 12:00:45 -0800 diff: describe behavior by using --from/--to instead of varying revision count
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Dec 2020 12:00:45 -0800] rev 46106
diff: describe behavior by using --from/--to instead of varying revision count I very recently updated the documentation to prefer `--from`/`--to` over `-r`, but I missed the plain-text description of how the command behaves when given different numbers of revisions (I guess I just scanned the text for "-r"). This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D9562
Thu, 10 Dec 2020 13:15:15 -0500 histedit: adjust comment describing `edit` action for clarity
Augie Fackler <augie@google.com> [Thu, 10 Dec 2020 13:15:15 -0500] rev 46105
histedit: adjust comment describing `edit` action for clarity Differential Revision: https://phab.mercurial-scm.org/D9561
Thu, 10 Dec 2020 11:42:49 -0500 histedit: tweak `edit` message to try and guide users to our workflow
Augie Fackler <augie@google.com> [Thu, 10 Dec 2020 11:42:49 -0500] rev 46104
histedit: tweak `edit` message to try and guide users to our workflow histedit predates evolve, so it drops you on an _uncommitted_ version of the commit you're amending/splitting, which is in contrast to git which expects you to use `git commit --amend` (I think - I'm basing this on internal bug reports). My hope is that this output will guide users a little more towards the expected workflow. Differential Revision: https://phab.mercurial-scm.org/D9560
Thu, 10 Dec 2020 14:03:46 +0530 procutil: don't assign stdin to None, use os.devnull instead
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Dec 2020 14:03:46 +0530] rev 46103
procutil: don't assign stdin to None, use os.devnull instead It will be painful to take care of procutil.stdin being None everywhere. Thanks to Yuya who recommended it.
Thu, 10 Dec 2020 13:51:56 +0530 dispatch: move IOError handling and flushing of streams to `dispatch()`
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 10 Dec 2020 13:51:56 +0530] rev 46102
dispatch: move IOError handling and flushing of streams to `dispatch()` Instead of patching both dispatch code and commandserver code, we directly handle this in `dispatch.dispatch()`. Thanks to Yuya who recommended this.
Wed, 09 Dec 2020 00:00:19 -0800 simplemerge: write output only once it's complete
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 00:00:19 -0800] rev 46101
simplemerge: write output only once it's complete `simplemerge()` can write either to `ui.fout` or to the file context (for in-memory merge). This patch simplifies the code a bit by making it build the output the same way regardless of where it's written, and then writes the whole output at once. I don't think it will be a problem that we don't output anything until the whole file is merged even if the file is large. Differential Revision: https://phab.mercurial-scm.org/D9550
Tue, 08 Dec 2020 23:05:53 -0800 simplemerge: avoid quadratic concatenation when building output text
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 23:05:53 -0800] rev 46100
simplemerge: avoid quadratic concatenation when building output text I haven't checked if the difference is measurable, but the new version is no less readable or idiomatic, so I don't think performance numbers are needed. Differential Revision: https://phab.mercurial-scm.org/D9549
Tue, 08 Dec 2020 22:59:17 -0800 simplemerge: work with opts as native strings instead of bytes
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 22:59:17 -0800] rev 46099
simplemerge: work with opts as native strings instead of bytes There was little reason to use `pycompat.byteskwargs()` in `simplemerge()` as far as I could tell. Differential Revision: https://phab.mercurial-scm.org/D9548
Tue, 08 Dec 2020 12:43:18 -0500 hghave: update the check for virtualenv
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Dec 2020 12:43:18 -0500] rev 46098
hghave: update the check for virtualenv This started as `hghave --test-features` failing on Windows in `test-hghave.t`. IDK how this worked, as neither my Linux nor Windows machines have the old attribute with virtualenv 20.2.2, even on py2. I think this was noticed recently because 357d8415aa27 mentioned an AttributeError, and mitigated by making this py2 only. But as mentioned, this is also a problem on py2 (where the failure was observed). When I got this working by removing the attribute reference, the command in the test failed because the `--no-site-package` argument was removed some time ago. Therefore, this backs out 357d8415aa27 and references a known good attribute (which was done to suppress the warning about an unused import) that also ensures the command does not need the argument. Since there appears to be (minor) broken stuff on py3, manually apply the `no-py3` guard that was backed out of the check itself. Differential Revision: https://phab.mercurial-scm.org/D9547
Sat, 05 Dec 2020 23:35:55 +0100 singlehead: introduce option to restrict to public changes
Joerg Sonnenberger <joerg@bec.de> [Sat, 05 Dec 2020 23:35:55 +0100] rev 46097
singlehead: introduce option to restrict to public changes The new experimental.single-head-per-branch:public-changes-only option restricts the single-head-per-branch filter to public changesets. This is useful when serving one repository with different views as publishing and non-publishing repository. Differential Revision: https://phab.mercurial-scm.org/D9525
Thu, 03 Dec 2020 14:39:39 -0800 treemanifest: stop storing full path for each item in manifest._lazydirs
Kyle Lippincott <spectral@google.com> [Thu, 03 Dec 2020 14:39:39 -0800] rev 46096
treemanifest: stop storing full path for each item in manifest._lazydirs This information is obtainable, if needed, based on the lazydirs key (which is the entry name) and the manifest's `dir()` method. ### Performance This is actually both a memory and a performance improvement, but it's likely to be a very small one in most situations. In the pathological repo I've been using for testing other performance work I've done recently, this reduced the time for a rebase operation (rebasing two commits across a public-phase change that touches a sibling of one of my tracked directories where the common parent is massive (>>10k entries)): #### Before ``` Time (mean ± σ): 4.059 s ± 0.121 s [User: 0.9 ms, System: 0.6 ms] Range (min … max): 3.941 s … 4.352 s 10 runs ``` #### After ``` Time (mean ± σ): 3.707 s ± 0.060 s [User: 0.8 ms, System: 0.8 ms] Range (min … max): 3.648 s … 3.818 s 10 runs ``` Differential Revision: https://phab.mercurial-scm.org/D9553
Tue, 08 Dec 2020 10:51:05 -0500 extensions: avoid including `__index__` in the disabled extension list
Matt Harbison <matt_harbison@yahoo.com> [Tue, 08 Dec 2020 10:51:05 -0500] rev 46095
extensions: avoid including `__index__` in the disabled extension list This generated module contains a dictionary of all bundled extension names and their help for builds that cannot enumerate extensions in the filesystem. The disabled list gets displayed in `hg help extensions`, and is also used by `setup.py` to populate `__index__.py` when building. I haven't seen it sneak into either py2exe or PyOxidizer builds, but it does show up when running tests locally after having created an installer. Differential Revision: https://phab.mercurial-scm.org/D9544
Wed, 09 Dec 2020 18:21:16 -0500 windows: continue looking at `%HOME%` for user config files with py3.8+
Matt Harbison <matt_harbison@yahoo.com> [Wed, 09 Dec 2020 18:21:16 -0500] rev 46094
windows: continue looking at `%HOME%` for user config files with py3.8+ The `%HOME%` variable is explicitly called out in `hg help config` as a location that is consulted when reading user files, but python stopped looking at it when expanding '~' in py3.8+.[1] Restore that old functionality by copying in the old implementation (and simplifying it to just use bytes). It could be simplfied further, since only '~' is passed, but I'm not sure yet if we need to make this a generic utility function on Windows. There are other uses of `os.path.expanduser()`, but this is the only case I know of that documents `%HOME%` usage. (The reason for removing it was that it typically isn't set, but it actually is set in MSYS and PowerShell, and `%HOME%` and `%USERPROFILE%` are different in MSYS. I could be convinced to just replace all uses with this as a general utility, so we don't have to think too hard about BC.) [1] https://bugs.python.org/issue36264 Differential Revision: https://phab.mercurial-scm.org/D9559
Wed, 09 Dec 2020 15:50:59 -0500 run-tests: configure the environment to expand `~` properly with Windows py38+
Matt Harbison <matt_harbison@yahoo.com> [Wed, 09 Dec 2020 15:50:59 -0500] rev 46093
run-tests: configure the environment to expand `~` properly with Windows py38+ This was causing tests to point to the actual home path on the system, not the test defined one. Differential Revision: https://phab.mercurial-scm.org/D9558
Wed, 09 Dec 2020 12:57:40 -0500 run-tests: fix `HGTESTEXTRAEXTENSIONS` with py3
Matt Harbison <matt_harbison@yahoo.com> [Wed, 09 Dec 2020 12:57:40 -0500] rev 46092
run-tests: fix `HGTESTEXTRAEXTENSIONS` with py3 Since `extensions` was a str and `section` bytes, it never populated anything. If it had, it would have put bytes into the environment dictionary that is all str. As everything starts and ends as str, remove the incomplete attempt at byteification. It doesn't appear that we had any test coverage of this bit of code, so also add a non-extension config to make sure it is filtered out properly. Differential Revision: https://phab.mercurial-scm.org/D9557
Fri, 04 Dec 2020 17:27:10 +0100 rhg: use persistent nodemap when available
Simon Sapin <simon-commits@exyr.org> [Fri, 04 Dec 2020 17:27:10 +0100] rev 46091
rhg: use persistent nodemap when available … for node ID → revision number lookups, instead on linear scan in a revlog. Differential Revision: https://phab.mercurial-scm.org/D9520
Mon, 07 Dec 2020 18:06:53 +0100 persistent-nodemap: properly ignore non-existent `.nd` data file
Simon Sapin <simon-commits@exyr.org> [Mon, 07 Dec 2020 18:06:53 +0100] rev 46090
persistent-nodemap: properly ignore non-existent `.nd` data file This code was meant to handle the case of a nodemap docket file pointing to a nodemap data file that doesn’t exist (anymore), but most likely caused an `UnboundLocalError` exception instead when `data` was used on the next line without being defined. This case is theoretically possible with a race condition between two hg processes, but is hard to reproduce or test: * Process A reads a docket file and finds a UID in it that points to a given data file name. * Process B decides that this same data file needs compacting. It writes a new one with a different UID, overwrites the docket file, then removes the old data file. * Only then process A tries to a open a file that doesn’t exist anymore. Differential Revision: https://phab.mercurial-scm.org/D9533
Wed, 09 Dec 2020 18:51:52 -0800 docs: prefer `hg diff --from/--to` over `-r`
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 18:51:52 -0800] rev 46089
docs: prefer `hg diff --from/--to` over `-r` This patch includes updating away from the broken `hg diff -r 'date(...)'` (see not in previous patch). Differential Revision: https://phab.mercurial-scm.org/D9555
Wed, 09 Dec 2020 18:31:19 -0800 diff: add --from and --to flags as clearer alternative to -r -r
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 18:31:19 -0800] rev 46088
diff: add --from and --to flags as clearer alternative to -r -r I think it was mistake to let the `-r` flag accept two revisions in `hg diff` in 98633e60067c (Support for 0, 1, or 2 diff revs, 2005-05-07). The command clearly acts on two revisions and having a single flag to indicate which those are is unclear. It got worse when it started accepting revsets as input. This patch introduces `--from` and `--to` flags, each taking a single revision and each defaulting to the working copy. That means that `hg
Thu, 03 Dec 2020 17:18:49 +0530 commandserver: handle IOError related to flushing of streams
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 03 Dec 2020 17:18:49 +0530] rev 46087
commandserver: handle IOError related to flushing of streams After dispatch, without chg we have handling of flushing of streams and exception handling related to it. The exception handling part is important because there can be exceptions when flushing fout or ferr. One such case is in `test-basic.t` which was failing on python3+chg without this patch as this handling was missing from chg. Failure can be seen at https://foss.heptapod.net/octobus/mercurial-devel/-/jobs/128399 Honestly I am not sure which one of `chgserver.py` or `commandserver.py` the change should go in. Differential Revision: https://phab.mercurial-scm.org/D9517
Wed, 02 Dec 2020 14:27:45 +0530 tests: conditionalize output in test-ssh.t with chg+py3
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 02 Dec 2020 14:27:45 +0530] rev 46086
tests: conditionalize output in test-ssh.t with chg+py3 Because of our wrapping around sys.std* and python3 internal buffering, the output order changes. The change in order seems like harmless because just few lines above the same command is run which results in same output. This makes `test-ssh.t` works with --chg on python 3. Differential Revision: https://phab.mercurial-scm.org/D9502
Wed, 02 Dec 2020 14:19:09 +0530 dispatch: disable line ending normalization on sys.stdin if its None
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 02 Dec 2020 14:19:09 +0530] rev 46085
dispatch: disable line ending normalization on sys.stdin if its None Fixes test-chg.t on python 3 with chg. Differential Revision: https://phab.mercurial-scm.org/D9501
Wed, 02 Dec 2020 13:55:17 +0530 procutils: don't try to get `.buffer` if sys.stdin is None
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 02 Dec 2020 13:55:17 +0530] rev 46084
procutils: don't try to get `.buffer` if sys.stdin is None While hunting down following test failure of test-chg.t on Python 3, I stumbled the case when `.buffer` is not available as sys.stdin is None. --- /home/pulkit/repo/hg-committed/tests/test-chg.t +++ /home/pulkit/repo/hg-committed/tests/test-chg.t.err @@ -203,7 +203,31 @@ $ CHGDEBUG=1 chg version -q 0<&- chg: debug: * stdio fds are missing (glob) chg: debug: * execute original hg (glob) - Mercurial Distributed SCM * (glob) + Traceback (most recent call last): + File "/tmp/hgtests.avspvsq4/install/bin/hg", line 43, in <module> + dispatch.run() + File "/usr/lib/python3.6/importlib/util.py", line 233, in __getattribute__ + self.__spec__.loader.exec_module(self) + File "<frozen importlib._bootstrap_external>", line 678, in exec_module + File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed + File "/tmp/hgtests.avspvsq4/install/lib/python/mercurial/dispatch.py", line 726, in <module> + class lazyaliasentry(object): + File "/tmp/hgtests.avspvsq4/install/lib/python/mercurial/dispatch.py", line 737, in lazyaliasentry + @util.propertycache + File "/usr/lib/python3.6/importlib/util.py", line 233, in __getattribute__ + self.__spec__.loader.exec_module(self) + File "<frozen importlib._bootstrap_external>", line 678, in exec_module + File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed + File "/tmp/hgtests.avspvsq4/install/lib/python/mercurial/util.py", line 3473, in <module> + f=procutil.stderr, + File "/usr/lib/python3.6/importlib/util.py", line 233, in __getattribute__ + self.__spec__.loader.exec_module(self) + File "<frozen importlib._bootstrap_external>", line 678, in exec_module + File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed + File "/tmp/hgtests.avspvsq4/install/lib/python/mercurial/utils/procutil.py", line 127, in <module> + stdin = sys.stdin.buffer + AttributeError: 'NoneType' object has no attribute 'buffer' + [1] server lifecycle ---------------- Differential Revision: https://phab.mercurial-scm.org/D9500
Wed, 09 Dec 2020 09:54:49 -0800 share: remove unexpected heading from "verbose" container in help test
Martin von Zweigbergk <martinvonz@google.com> [Wed, 09 Dec 2020 09:54:49 -0800] rev 46083
share: remove unexpected heading from "verbose" container in help test `test-gendoc-*.t` have been failing for me since 91425656e2b1 (share: add documentation about share-safe mode in `hg help -e share`, 2020-11-27) with this kind of output: ``` --- /usr/local/google/home/martinvonz/hg/tests/test-gendoc-ru.t +++ /usr/local/google/home/martinvonz/hg/tests/test-gendoc-ru.t.err @@ -2,3 +2,9 @@ $ $TESTDIR/check-gendoc ru checking for parse errors + gendoc.txt:12818: (SEVERE/4) Unexpected section title. + + Sharing requirements and configs of source repository with shares + ----------------------------------------------------------------- + Exiting due to level-4 (SEVERE) system message. + [1] ``` This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D9552
Tue, 08 Dec 2020 23:01:24 +0100 cext: match format string for 32bit long platforms
Joerg Sonnenberger <joerg@bec.de> [Tue, 08 Dec 2020 23:01:24 +0100] rev 46082
cext: match format string for 32bit long platforms Differential Revision: https://phab.mercurial-scm.org/D9546
Tue, 08 Dec 2020 13:33:40 -0800 status: disable morestatus when using -0
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Dec 2020 13:33:40 -0800] rev 46081
status: disable morestatus when using -0 Without this patch, you get something like this: ``` M a\x00? a.orig\x00# The repository is in an unfinished *merge* state. (esc) # Unresolved merge conflicts: # # a # # To mark files as resolved: hg resolve --mark FILE # To continue: hg commit # To abort: hg merge --abort ``` That doesn't seem like something one would ever want. I considered making it an error to combine `-0` with morestatus, but it seems very likely that that would just make the user spend time trying to figure out how to disable morestatus, so it feels like we might as well just do it for them. Differential Revision: https://phab.mercurial-scm.org/D9545
Sun, 06 Dec 2020 14:45:19 +0100 debugdiscovery: display some information about the initial "undecided" set
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 06 Dec 2020 14:45:19 +0100] rev 46080
debugdiscovery: display some information about the initial "undecided" set The size and shape of the revision that remains "undediced" once the fetched the remote heads and queried the local one have a large impact on the discovery performance, so we display some information about that set. Differential Revision: https://phab.mercurial-scm.org/D9530
Sun, 06 Dec 2020 06:19:15 +0100 debugdiscovery: add some data about the shapes of the sets
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 06 Dec 2020 06:19:15 +0100] rev 46079
debugdiscovery: add some data about the shapes of the sets We display the number of heads and roots or the common and missing set. Differential Revision: https://phab.mercurial-scm.org/D9529
Mon, 07 Dec 2020 21:44:00 -0500 tests: conditionalize the progress timestamp for Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 21:44:00 -0500] rev 46078
tests: conditionalize the progress timestamp for Windows It looks like for py2 on Windows, the start date is 1970. It matches the other platforms for py3, so I'm just going to match the tests and move on, given that py2 is on the way out. Differential Revision: https://phab.mercurial-scm.org/D9541
Mon, 07 Dec 2020 20:38:00 -0500 tests: conditionalize a few Windows specific error messages
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 20:38:00 -0500] rev 46077
tests: conditionalize a few Windows specific error messages Differential Revision: https://phab.mercurial-scm.org/D9540
Mon, 07 Dec 2020 20:32:05 -0500 tests: correct the output order about starting a background thread for Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 20:32:05 -0500] rev 46076
tests: correct the output order about starting a background thread for Windows I didn't track down where this change occurred. I assume it's related to some buffering changes, and/or an explicit flush somewhere. Differential Revision: https://phab.mercurial-scm.org/D9539
Mon, 07 Dec 2020 20:57:50 -0500 tests: update the exit status codes for Windows specific tests
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 20:57:50 -0500] rev 46075
tests: update the exit status codes for Windows specific tests This corresponds to 527ce85c2e60, ebee234d952a, and 568c05d8f3d2. Differential Revision: https://phab.mercurial-scm.org/D9538
Mon, 07 Dec 2020 20:53:01 -0500 tests: drop the trailing exclamation point from some Windows abort messages
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 20:53:01 -0500] rev 46074
tests: drop the trailing exclamation point from some Windows abort messages This likely goes with 95c4cca641f6. Differential Revision: https://phab.mercurial-scm.org/D9537
Mon, 07 Dec 2020 16:37:22 -0500 tests: update output for test-check-pylint.t
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 16:37:22 -0500] rev 46073
tests: update output for test-check-pylint.t The py3 version on Windows appends "(previous run: 10.00/10, +0.00)" with py39. I didn't see that for the exact same version on Linux (with py3.6.9). Differential Revision: https://phab.mercurial-scm.org/D9536
Mon, 07 Dec 2020 16:32:30 -0500 run-tests: extend PATH on Windows to include user installed scripts
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 16:32:30 -0500] rev 46072
run-tests: extend PATH on Windows to include user installed scripts This allows the test environment to see pylint.exe when installed with `pip install --user`, since it isn't normally on PATH. Differential Revision: https://phab.mercurial-scm.org/D9535
Mon, 07 Dec 2020 16:18:28 -0500 run-tests: stuff a `python3.exe` into the test bin directory on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 16:18:28 -0500] rev 46071
run-tests: stuff a `python3.exe` into the test bin directory on Windows Windows doesn't have `python3.exe` as part of the python.org distribution, and that broke every script with a shebang after c102b704edb5. Windows itself provides a `python3.exe` app execution alias[1], but it is some sort of reparse point that MSYS is incapable of handling[2]. When run by MSYS, it simply prints $ python3 -V - Cannot open That in turn caused every `hghave` check, and test that invokes shebang scripts directly, to fail. Rather than try to patch up every script call to be invoked with `$PYTHON` (and regress when non Windows developers forget), copying the executable into the test binary directory with the new name just works. Since this directory is prepended to the system PATH value, it also overrides the broken execution alias. (The `_tmpbindir` is used instead of `_bindir` because the latter causes python3.exe to be copied into the repo next to hg.exe when `test-run-tests.t` runs. Something runs with this version of the executable and subsequent runs of `run-tests.py` inside `test-run-tests.t` try to copy over it while it is in use, and fail. This avoids the failures and the clutter.) I didn't conditionalize this on py3 because `python3.exe` needs to be present (for the shebangs) even when running py2 tests. It shouldn't matter to these simple scripts, and I think the intention is to make the test runner use py3 always, even if testing a py2 build. For now, still supporting py2 is helping to clean up the mess that is py3 tests. [1] https://stackoverflow.com/a/57168165 [2] https://stackoverflow.com/questions/59148628/solved-unable-to-run-python-3-7-on-windows-10-permission-denied#comment104524397_59148666 Differential Revision: https://phab.mercurial-scm.org/D9543
Mon, 07 Dec 2020 23:15:35 -0500 run-tests: fix a typo in an attribute name
Matt Harbison <matt_harbison@yahoo.com> [Mon, 07 Dec 2020 23:15:35 -0500] rev 46070
run-tests: fix a typo in an attribute name At least, I assume it's a typo. Nothing else uses it, but `_tmpbindir` is used. Differential Revision: https://phab.mercurial-scm.org/D9542
Mon, 07 Dec 2020 20:12:36 +0900 test-extension: flush diagnostic message to stabilize chg output
Yuya Nishihara <yuya@tcha.org> [Mon, 07 Dec 2020 20:12:36 +0900] rev 46069
test-extension: flush diagnostic message to stabilize chg output Since chg server may create new file object for the attached stdout, procutil.stdout is not ui.fout and the buffered procutil.stdout data wouldn't be flushed at all. That's why test-extension.t passes without modification on Python 2.
Thu, 03 Dec 2020 01:45:23 -0500 formatting: re-blacken match.py
Matt Harbison <matt_harbison@yahoo.com> [Thu, 03 Dec 2020 01:45:23 -0500] rev 46068
formatting: re-blacken match.py Differential Revision: https://phab.mercurial-scm.org/D9512
Mon, 07 Dec 2020 11:23:34 +0100 transaction: windows workaround for missing line iteration support
Joerg Sonnenberger <joerg@bec.de> [Mon, 07 Dec 2020 11:23:34 +0100] rev 46067
transaction: windows workaround for missing line iteration support The mixedfilemodewrapper doesn't support line iteration, so just read the whole file in one go. Differential Revision: https://phab.mercurial-scm.org/D9532
Sat, 28 Nov 2020 15:04:44 +0100 sidedata: send the correct revision data for wireproto v2
Joerg Sonnenberger <joerg@bec.de> [Sat, 28 Nov 2020 15:04:44 +0100] rev 46066
sidedata: send the correct revision data for wireproto v2 When no sidedata is present, rawdata() and revision() are the same. But as soon as sidedata is present, the way it is currently stored will change the rawdata and that is not desired here, so switch to the correct data accessor. Differential Revision: https://phab.mercurial-scm.org/D9445
Sun, 06 Dec 2020 14:45:04 +0100 debugdiscovery: move various computation earlier
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 06 Dec 2020 14:45:04 +0100] rev 46065
debugdiscovery: move various computation earlier We are about to add more data to debug discovery (eg: data bout the initial undecided set, number of roundtrip, etc). So we start by cleaning up the code by spliting some computation and some display related preparation. Differential Revision: https://phab.mercurial-scm.org/D9524
Sun, 06 Dec 2020 06:23:26 +0100 debugdiscovery: clarify internal key name in debugobsolete
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 06 Dec 2020 06:23:26 +0100] rev 46064
debugdiscovery: clarify internal key name in debugobsolete They were probably clear when they got added initially but with more key around, they gain to be clearer. Differential Revision: https://phab.mercurial-scm.org/D9528
Fri, 20 Nov 2020 14:17:08 +0100 copies-rust: extract the processing of a ChangedFiles in its own function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 14:17:08 +0100] rev 46063
copies-rust: extract the processing of a ChangedFiles in its own function This is a reasonably independent piece of code that we can extract in its own function. This extraction will be very useful for the next changeset, where we will change the iteration order (but still do the same kind of processing). Differential Revision: https://phab.mercurial-scm.org/D9421
Fri, 20 Nov 2020 14:03:40 +0100 copies-rust: move the parent token to an enum
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 20 Nov 2020 14:03:40 +0100] rev 46062
copies-rust: move the parent token to an enum We carry around information about which parent of a revision is been dealt with. So far this was a `usize` but as we are about to pass it around to more function it seems like a good idea to start cleaning this up and use a proper enum. Differential Revision: https://phab.mercurial-scm.org/D9420
Thu, 12 Nov 2020 15:54:10 +0100 copies-rust: parse the changed-file sidedata directly in rust
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 12 Nov 2020 15:54:10 +0100] rev 46061
copies-rust: parse the changed-file sidedata directly in rust It does not make much sense to parse the data into python object using slow python code to later turn them into rust object. We directly pass the binary blob and use it directly in Rust. Ideally we could directly read the sidedata in Rust, using a revlog in Rust. However we do not have this ready to use yet. This more direct approach provides a nice speedup over the board. Especially five cases that we previously too slow to return in the previous changeset are not able to finish. Notably, we are now significantly faster than the Python version of this code in all the meaningful cases. I looked at the various cases that remains significantly slower then the filelog version and they are currently 3 main source of slowness: * The isancestor computation: even if we cache them, if the revs spawn over a large amount of history the ancestry checking is still quite expensive. Using a different approach more centered on the graph we are currently considering might yield significant speed. * Merging of the map from the two parents: in some case, this climb up to ⅔ of the time spent in copy tracing. See inline comment for idea to handle this better. * Extracting data from the filelog. I would like to think this mostly comes from the fact my test repositories pre-date Valentin Gatien-Baron improvement of the `files` field (99ebde4fec99) and that more recent revisions will be faster to fetch. Further testing on this aspect is needed. This revision compared to the previous one: =========================================== Repo Case Source-Rev Dest-Rev # of revisions old time new time Difference Factor time per rev -------------------------------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 1 revs, 0.000047 s, 0.000049 s, +0.000002 s, × 1.0426, 49 µs/rev mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 6 revs, 0.000181 s, 0.000114 s, -0.000067 s, × 0.6298, 19 µs/rev mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 1032 revs, 0.005852 s, 0.004223 s, -0.001629 s, × 0.7216, 4 µs/rev pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 9 revs, 0.000229 s, 0.000305 s, +0.000076 s, × 1.3319, 33 µs/rev pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 1 revs, 0.000058 s, 0.000060 s, +0.000002 s, × 1.0345, 60 µs/rev pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 7 revs, 0.000146 s, 0.000173 s, +0.000027 s, × 1.1849, 24 µs/rev pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 1 revs, 0.001206 s, 0.000446 s, -0.000760 s, × 0.3698, 446 µs/rev pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 6 revs, 0.025275 s, 0.010360 s, -0.014915 s, × 0.4099, 1726 µs/rev pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 4785 revs, 0.080303 s, 0.048002 s, -0.032301 s, × 0.5978, 10 µs/rev pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 6780 revs, 0.152641 s, 0.075705 s, -0.076936 s, × 0.4960, 11 µs/rev pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 5441 revs, 0.099107 s, 0.056705 s, -0.042402 s, × 0.5722, 10 µs/rev pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 43646 revs, 2.137894 s, 0.794685 s, -1.343209 s, × 0.3717, 18 µs/rev pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 26389 revs, 0.022202 s, 0.020209 s, -0.001993 s, × 0.9102, 0 µs/rev pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 11316 revs, 0.228946 s, 0.122475 s, -0.106471 s, × 0.5350, 10 µs/rev netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 2 revs, 0.000186 s, 0.000142 s, -0.000044 s, × 0.7634, 71 µs/rev netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 2 revs, 0.000133 s, 0.000113 s, -0.000020 s, × 0.8496, 56 µs/rev netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 3 revs, 0.000320 s, 0.000241 s, -0.000079 s, × 0.7531, 80 µs/rev netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 9 revs, 0.001339 s, 0.000729 s, -0.000610 s, × 0.5444, 81 µs/rev netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 1421 revs, 0.015694 s, 0.010198 s, -0.005496 s, × 0.6498, 7 µs/rev netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 1533 revs, 0.018457 s, 0.015312 s, -0.003145 s, × 0.8296, 9 µs/rev netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 5750 revs, 0.111691 s, 0.060517 s, -0.051174 s, × 0.5418, 10 µs/rev netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 67005 revs, 1.166017 s, 0.611102 s, -0.554915 s, × 0.5241, 9 µs/rev mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 2 revs, 0.000197 s, 0.000164 s, -0.000033 s, × 0.8325, 82 µs/rev mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 8 revs, 0.000626 s, 0.000334 s, -0.000292 s, × 0.5335, 41 µs/rev mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 9 revs, 0.000303 s, 0.000463 s, +0.000160 s, × 1.5281, 51 µs/rev mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 7 revs, 0.001679 s, 0.000730 s, -0.000949 s, × 0.4348, 104 µs/rev mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 3 revs, 0.006947 s, 0.003522 s, -0.003425 s, × 0.5070, 1174 µs/rev mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.133070 s, 0.072518 s, -0.060552 s, × 0.5450, 12086 µs/rev mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.008705 s, 0.005760 s, -0.002945 s, × 0.6617, 3 µs/rev mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.005913 s, 0.005720 s, -0.000193 s, × 0.9674, 0 µs/rev mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 7839 revs, 0.101373 s, 0.063310 s, -0.038063 s, × 0.6245, 8 µs/rev mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 0.046526 s, 0.043608 s, -0.002918 s, × 0.9373, 0 µs/rev mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 30263 revs, 0.313954 s, 0.204831 s, -0.109123 s, × 0.6524, 6 µs/rev mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 153721 revs, 3.367395 s, 2.161906 s, -1.205489 s, × 0.6420, 14 µs/rev mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 210546 revs, 4.691820 s, 3.291831 s, -1.399989 s, × 0.7016, 15 µs/rev mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 2 revs, 0.001199 s, 0.001213 s, +0.000014 s, × 1.0117, 606 µs/rev mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 2 revs, 0.001216 s, 0.001225 s, +0.000009 s, × 1.0074, 612 µs/rev mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 4 revs, 0.000613 s, 0.000564 s, -0.000049 s, × 0.9201, 141 µs/rev mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 2 revs, 0.001906 s, 0.001549 s, -0.000357 s, × 0.8127, 774 µs/rev mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1 revs, 0.092766 s, 0.035918 s, -0.056848 s, × 0.3872, 35918 µs/rev mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.136074 s, 0.073788 s, -0.062286 s, × 0.5423, 12298 µs/rev mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.009067 s, 0.006151 s, -0.002916 s, × 0.6784, 3 µs/rev mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.006243 s, 0.006165 s, -0.000078 s, × 0.9875, 0 µs/rev mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 6657 revs, 0.114463 s, 0.065421 s, -0.049042 s, × 0.5715, 9 µs/rev mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 40314 revs, 0.433683 s, 0.313749 s, -0.119934 s, × 0.7235, 7 µs/rev mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 38690 revs, 0.411278 s, 0.297867 s, -0.113411 s, × 0.7242, 7 µs/rev mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 54487 revs, 0.155133 s, 0.111300 s, -0.043833 s, × 0.7174, 2 µs/rev mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 0.048933 s, 0.046202 s, -0.002731 s, × 0.9442, 1 µs/rev mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 97052 revs, 8.100385 s, 1.999640 s, -6.100745 s, × 0.2469, 20 µs/rev mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 52031 revs, 1.446720 s, 0.809134 s, -0.637586 s, × 0.5593, 15 µs/rev mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 363753 revs, killed , 47.406785 s, , , 130 µs/rev mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 444327 revs, 1.369537 s, 0.996219 s, -0.373318 s, × 0.7274, 2 µs/rev mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 362229 revs, killed , 47.273399 s, , , 130 µs/rev mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 359344 revs, killed , 47.419099 s, , , 131 µs/rev mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 192665 revs, 5.186079 s, 3.512653 s, -1.673426 s, × 0.6773, 18 µs/rev mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 237259 revs, killed , 44.459049 s, , , 187 µs/rev mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 391148 revs, killed , 52.837926 s, , , 135 µs/rev This revision compared to the python code: ========================================== Repo Case Source-Rev Dest-Rev # of revisions Python-Time Rust-Time Difference Factor time per rev -------------------------------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 1 revs, 0.000044 s, 0.000049 s, +0.000005 s, × 1.1136, 49 µs/rev mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 6 revs, 0.000138 s, 0.000114 s, -0.000024 s, × 0.8261, 19 µs/rev mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 1032 revs, 0.005052 s, 0.004223 s, -0.000829 s, × 0.8359, 4 µs/rev pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 9 revs, 0.000219 s, 0.000305 s, +0.000086 s, × 1.3927, 33 µs/rev pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 1 revs, 0.000055 s, 0.000060 s, +0.000005 s, × 1.0909, 60 µs/rev pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 7 revs, 0.000128 s, 0.000173 s, +0.000045 s, × 1.3516, 24 µs/rev pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 1 revs, 0.001089 s, 0.000446 s, -0.000643 s, × 0.4096, 446 µs/rev pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 6 revs, 0.017407 s, 0.010360 s, -0.007047 s, × 0.5952, 1726 µs/rev pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 4785 revs, 0.094175 s, 0.048002 s, -0.046173 s, × 0.5097, 10 µs/rev pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 6780 revs, 0.238009 s, 0.075705 s, -0.162304 s, × 0.3181, 11 µs/rev pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 5441 revs, 0.125876 s, 0.056705 s, -0.069171 s, × 0.4505, 10 µs/rev pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 43646 revs, 3.581556 s, 0.794685 s, -2.786871 s, × 0.2219, 18 µs/rev pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 26389 revs, 0.016721 s, 0.020209 s, +0.003488 s, × 1.2086, 0 µs/rev pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 11316 revs, 0.242367 s, 0.122475 s, -0.119892 s, × 0.5053, 10 µs/rev netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 2 revs, 0.000165 s, 0.000142 s, -0.000023 s, × 0.8606, 71 µs/rev netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 2 revs, 0.000114 s, 0.000113 s, -0.000001 s, × 0.9912, 56 µs/rev netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 3 revs, 0.000296 s, 0.000241 s, -0.000055 s, × 0.8142, 80 µs/rev netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 9 revs, 0.001124 s, 0.000729 s, -0.000395 s, × 0.6486, 81 µs/rev netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 1421 revs, 0.013060 s, 0.010198 s, -0.002862 s, × 0.7809, 7 µs/rev netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 1533 revs, 0.017112 s, 0.015312 s, -0.001800 s, × 0.8948, 9 µs/rev netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 5750 revs, 0.660350 s, 0.060517 s, -0.599833 s, × 0.0916, 10 µs/rev netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 67005 revs, 10.032499 s, 0.611102 s, -9.421397 s, × 0.0609, 9 µs/rev mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 2 revs, 0.000189 s, 0.000164 s, -0.000025 s, × 0.8677, 82 µs/rev mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 8 revs, 0.000462 s, 0.000334 s, -0.000128 s, × 0.7229, 41 µs/rev mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 9 revs, 0.000270 s, 0.000463 s, +0.000193 s, × 1.7148, 51 µs/rev mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 7 revs, 0.001474 s, 0.000730 s, -0.000744 s, × 0.4953, 104 µs/rev mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 3 revs, 0.004806 s, 0.003522 s, -0.001284 s, × 0.7328, 1174 µs/rev mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.085150 s, 0.072518 s, -0.012632 s, × 0.8517, 12086 µs/rev mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.007064 s, 0.005760 s, -0.001304 s, × 0.8154, 3 µs/rev mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.004741 s, 0.005720 s, +0.000979 s, × 1.2065, 0 µs/rev mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 7839 revs, 0.190133 s, 0.063310 s, -0.126823 s, × 0.3330, 8 µs/rev mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 0.035651 s, 0.043608 s, +0.007957 s, × 1.2232, 0 µs/rev mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 30263 revs, 0.440694 s, 0.204831 s, -0.235863 s, × 0.4648, 6 µs/rev mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 153721 revs, 18.454163 s, 2.161906 s, -16.292257 s, × 0.1172, 14 µs/rev mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 210546 revs, 31.562719 s, 3.291831 s, -28.270888 s, × 0.1043, 15 µs/rev mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 2 revs, 0.001189 s, 0.001213 s, +0.000024 s, × 1.0202, 606 µs/rev mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 2 revs, 0.001204 s, 0.001225 s, +0.000021 s, × 1.0174, 612 µs/rev mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 4 revs, 0.000586 s, 0.000564 s, -0.000022 s, × 0.9625, 141 µs/rev mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 2 revs, 0.001845 s, 0.001549 s, -0.000296 s, × 0.8396, 774 µs/rev mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1 revs, 0.063822 s, 0.035918 s, -0.027904 s, × 0.5628, 35918 µs/rev mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 0.088038 s, 0.073788 s, -0.014250 s, × 0.8381, 12298 µs/rev mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.007389 s, 0.006151 s, -0.001238 s, × 0.8325, 3 µs/rev mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.004868 s, 0.006165 s, +0.001297 s, × 1.2664, 0 µs/rev mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 6657 revs, 0.222450 s, 0.065421 s, -0.157029 s, × 0.2941, 9 µs/rev mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 40314 revs, 0.370675 s, 0.313749 s, -0.056926 s, × 0.8464, 7 µs/rev mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 38690 revs, 0.358020 s, 0.297867 s, -0.060153 s, × 0.8320, 7 µs/rev mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 54487 revs, 0.145235 s, 0.111300 s, -0.033935 s, × 0.7663, 2 µs/rev mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 0.037606 s, 0.046202 s, +0.008596 s, × 1.2286, 1 µs/rev mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 97052 revs, 7.382439 s, 1.999640 s, -5.382799 s, × 0.2709, 20 µs/rev mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 52031 revs, 7.273506 s, 0.809134 s, -6.464372 s, × 0.1112, 15 µs/rev mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 363753 revs, killed , 47.406785 s, , , 130 µs/rev mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 444327 revs, 1.074593 s, 0.996219 s, -0.078374 s, × 0.9271, 2 µs/rev mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 362229 revs, killed , 47.273399 s, , , 130 µs/rev mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 359344 revs, killed , 47.419099 s, , , 131 µs/rev mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 192665 revs, 27.746195 s, 3.512653 s, -24.233542 s, × 0.1266, 18 µs/rev mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 237259 revs, killed , 44.459049 s, , , 187 µs/rev mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 391148 revs, killed , 52.837926 s, , , 135 µs/rev This revision compared to the filelog algorithm: ================================================ Repo Case Source-Rev Dest-Rev # of revisions filelog sidedata Difference Factor time per rev -------------------------------------------------------------------------------------------------------------------------------------------------------------- mercurial x_revs_x_added_0_copies ad6b123de1c7 39cfcef4f463 : 1 revs, 0.000906 s, 0.000049 s, -0.000857 s, × 0.0540, 48 µs/rev mercurial x_revs_x_added_x_copies 2b1c78674230 0c1d10351869 : 6 revs, 0.001844 s, 0.000114 s, -0.001730 s, × 0.0618, 18 µs/rev mercurial x000_revs_x000_added_x_copies 81f8ff2a9bf2 dd3267698d84 : 1032 revs, 0.018577 s, 0.004223 s, -0.014354 s, × 0.2273, 4 µs/rev pypy x_revs_x_added_0_copies aed021ee8ae8 099ed31b181b : 9 revs, 0.005009 s, 0.000305 s, -0.004704 s, × 0.0608, 33 µs/rev pypy x_revs_x000_added_0_copies 4aa4e1f8e19a 359343b9ac0e : 1 revs, 0.209606 s, 0.000060 s, -0.209546 s, × 0.0002, 59 µs/rev pypy x_revs_x_added_x_copies ac52eb7bbbb0 72e022663155 : 7 revs, 0.017008 s, 0.000173 s, -0.016835 s, × 0.0101, 24 µs/rev pypy x_revs_x00_added_x_copies c3b14617fbd7 ace7255d9a26 : 1 revs, 0.019227 s, 0.000446 s, -0.018781 s, × 0.0231, 445 µs/rev pypy x_revs_x000_added_x000_copies df6f7a526b60 a83dc6a2d56f : 6 revs, 0.765782 s, 0.010360 s, -0.755422 s, × 0.0135, 1726 µs/rev pypy x000_revs_xx00_added_0_copies 89a76aede314 2f22446ff07e : 4785 revs, 1.186068 s, 0.048002 s, -1.138066 s, × 0.0404, 10 µs/rev pypy x000_revs_x000_added_x_copies 8a3b5bfd266e 2c68e87c3efe : 6780 revs, 1.266745 s, 0.075705 s, -1.191040 s, × 0.0597, 11 µs/rev pypy x000_revs_x000_added_x000_copies 89a76aede314 7b3dda341c84 : 5441 revs, 1.666389 s, 0.056705 s, -1.609684 s, × 0.0340, 10 µs/rev pypy x0000_revs_x_added_0_copies d1defd0dc478 c9cb1334cc78 : 43646 revs, 0.001070 s, 0.794685 s, +0.793615 s, × 742.69, 18 µs/rev pypy x0000_revs_xx000_added_0_copies bf2c629d0071 4ffed77c095c : 26389 revs, 1.076269 s, 0.020209 s, -1.056060 s, × 0.0187, 0 µs/rev pypy x0000_revs_xx000_added_x000_copies 08ea3258278e d9fa043f30c0 : 11316 revs, 1.355085 s, 0.122475 s, -1.232610 s, × 0.0903, 10 µs/rev netbeans x_revs_x_added_0_copies fb0955ffcbcd a01e9239f9e7 : 2 revs, 0.028551 s, 0.000142 s, -0.028409 s, × 0.0049, 70 µs/rev netbeans x_revs_x000_added_0_copies 6f360122949f 20eb231cc7d0 : 2 revs, 0.157319 s, 0.000113 s, -0.157206 s, × 0.0007, 56 µs/rev netbeans x_revs_x_added_x_copies 1ada3faf6fb6 5a39d12eecf4 : 3 revs, 0.025722 s, 0.000241 s, -0.025481 s, × 0.0093, 80 µs/rev netbeans x_revs_x00_added_x_copies 35be93ba1e2c 9eec5e90c05f : 9 revs, 0.053374 s, 0.000729 s, -0.052645 s, × 0.0136, 80 µs/rev netbeans x000_revs_xx00_added_0_copies eac3045b4fdd 51d4ae7f1290 : 1421 revs, 0.038146 s, 0.010198 s, -0.027948 s, × 0.2673, 7 µs/rev netbeans x000_revs_x000_added_x_copies e2063d266acd 6081d72689dc : 1533 revs, 0.229215 s, 0.015312 s, -0.213903 s, × 0.0668, 9 µs/rev netbeans x000_revs_x000_added_x000_copies ff453e9fee32 411350406ec2 : 5750 revs, 0.974484 s, 0.060517 s, -0.913967 s, × 0.0621, 10 µs/rev netbeans x0000_revs_xx000_added_x000_copies 588c2d1ced70 1aad62e59ddd : 67005 revs, 3.924308 s, 0.611102 s, -3.313206 s, × 0.1557, 9 µs/rev mozilla-central x_revs_x_added_0_copies 3697f962bb7b 7015fcdd43a2 : 2 revs, 0.035563 s, 0.000164 s, -0.035399 s, × 0.0046, 81 µs/rev mozilla-central x_revs_x000_added_0_copies dd390860c6c9 40d0c5bed75d : 8 revs, 0.145766 s, 0.000334 s, -0.145432 s, × 0.0022, 41 µs/rev mozilla-central x_revs_x_added_x_copies 8d198483ae3b 14207ffc2b2f : 9 revs, 0.026283 s, 0.000463 s, -0.025820 s, × 0.0176, 51 µs/rev mozilla-central x_revs_x00_added_x_copies 98cbc58cc6bc 446a150332c3 : 7 revs, 0.087403 s, 0.000730 s, -0.086673 s, × 0.0083, 104 µs/rev mozilla-central x_revs_x000_added_x000_copies 3c684b4b8f68 0a5e72d1b479 : 3 revs, 0.209484 s, 0.003522 s, -0.205962 s, × 0.0168, 1173 µs/rev mozilla-central x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 2.197867 s, 0.072518 s, -2.125349 s, × 0.0329, 12084 µs/rev mozilla-central x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.090142 s, 0.005760 s, -0.084382 s, × 0.0638, 3 µs/rev mozilla-central x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.742658 s, 0.005720 s, -0.736938 s, × 0.0077, 0 µs/rev mozilla-central x000_revs_x000_added_x000_copies 7c97034feb78 4407bd0c6330 : 7839 revs, 1.166159 s, 0.063310 s, -1.102849 s, × 0.0542, 8 µs/rev mozilla-central x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 6.721719 s, 0.043608 s, -6.678111 s, × 0.0064, 0 µs/rev mozilla-central x0000_revs_xx000_added_x000_copies f78c615a656c 96a38b690156 : 30263 revs, 3.356523 s, 0.204831 s, -3.151692 s, × 0.0610, 6 µs/rev mozilla-central x00000_revs_x0000_added_x0000_copies 6832ae71433c 4c222a1d9a00 : 153721 revs, 15.880822 s, 2.161906 s, -13.718916 s, × 0.1361, 14 µs/rev mozilla-central x00000_revs_x00000_added_x000_copies 76caed42cf7c 1daa622bbe42 : 210546 revs, 20.781275 s, 3.291831 s, -17.489444 s, × 0.1584, 15 µs/rev mozilla-try x_revs_x_added_0_copies aaf6dde0deb8 9790f499805a : 2 revs, 0.084165 s, 0.001213 s, -0.082952 s, × 0.0144, 606 µs/rev mozilla-try x_revs_x000_added_0_copies d8d0222927b4 5bb8ce8c7450 : 2 revs, 0.503744 s, 0.001225 s, -0.502519 s, × 0.0024, 612 µs/rev mozilla-try x_revs_x_added_x_copies 092fcca11bdb 936255a0384a : 4 revs, 0.021545 s, 0.000564 s, -0.020981 s, × 0.0261, 140 µs/rev mozilla-try x_revs_x00_added_x_copies b53d2fadbdb5 017afae788ec : 2 revs, 0.240699 s, 0.001549 s, -0.239150 s, × 0.0064, 774 µs/rev mozilla-try x_revs_x000_added_x000_copies 20408ad61ce5 6f0ee96e21ad : 1 revs, 1.100682 s, 0.035918 s, -1.064764 s, × 0.0326, 35882 µs/rev mozilla-try x_revs_x0000_added_x0000_copies effb563bb7e5 c07a39dc4e80 : 6 revs, 2.234809 s, 0.073788 s, -2.161021 s, × 0.0330, 12295 µs/rev mozilla-try x000_revs_xx00_added_0_copies 6100d773079a 04a55431795e : 1593 revs, 0.091222 s, 0.006151 s, -0.085071 s, × 0.0674, 3 µs/rev mozilla-try x000_revs_x000_added_x_copies 9f17a6fc04f9 2d37b966abed : 8315 revs, 0.764722 s, 0.006165 s, -0.758557 s, × 0.0080, 0 µs/rev mozilla-try x000_revs_x000_added_x000_copies 1346fd0130e4 4c65cbdabc1f : 6657 revs, 1.185655 s, 0.065421 s, -1.120234 s, × 0.0551, 9 µs/rev mozilla-try x0000_revs_x_added_0_copies 63519bfd42ee a36a2a865d92 : 40314 revs, 0.089736 s, 0.313749 s, +0.224013 s, × 3.4963, 7 µs/rev mozilla-try x0000_revs_x_added_x_copies 9fe69ff0762d bcabf2a78927 : 38690 revs, 0.084132 s, 0.297867 s, +0.213735 s, × 3.5404, 7 µs/rev mozilla-try x0000_revs_xx000_added_x_copies 156f6e2674f2 4d0f2c178e66 : 54487 revs, 7.581932 s, 0.111300 s, -7.470632 s, × 0.0146, 2 µs/rev mozilla-try x0000_revs_xx000_added_0_copies 9eec5917337d 67118cc6dcad : 45299 revs, 6.671144 s, 0.046202 s, -6.624942 s, × 0.0069, 1 µs/rev mozilla-try x0000_revs_xx000_added_x000_copies 89294cd501d9 7ccb2fc7ccb5 : 97052 revs, 7.674771 s, 1.999640 s, -5.675131 s, × 0.2605, 20 µs/rev mozilla-try x0000_revs_x0000_added_x0000_copies e928c65095ed e951f4ad123a : 52031 revs, 9.870343 s, 0.809134 s, -9.061209 s, × 0.0819, 15 µs/rev mozilla-try x00000_revs_x_added_0_copies 6a320851d377 1ebb79acd503 : 363753 revs, 0.094781 s, 47.406785 s, +47.312004 s, × 500.17, 130 µs/rev mozilla-try x00000_revs_x00000_added_0_copies dc8a3ca7010e d16fde900c9c : 444327 revs, 26.690029 s, 0.996219 s, -25.693810 s, × 0.0373, 2 µs/rev mozilla-try x00000_revs_x_added_x_copies 5173c4b6f97c 95d83ee7242d : 362229 revs, 0.094941 s, 47.273399 s, +47.178458 s, × 497.92, 130 µs/rev mozilla-try x00000_revs_x000_added_x_copies 9126823d0e9c ca82787bb23c : 359344 revs, 0.233811 s, 47.419099 s, +47.185288 s, × 202.80, 131 µs/rev mozilla-try x00000_revs_x0000_added_x0000_copies 8d3fafa80d4b eb884023b810 : 192665 revs, 19.321750 s, 3.512653 s, -15.809097 s, × 0.1817, 18 µs/rev mozilla-try x00000_revs_x00000_added_x0000_copies 1b661134e2ca 1ae03d022d6d : 237259 revs, 21.358350 s, 44.459049 s, +23.100699 s, × 2.0815, 187 µs/rev mozilla-try x00000_revs_x00000_added_x000_copies 9b2a99adc05e 8e29777b48e6 : 391148 revs, 25.328737 s, 52.837926 s, +27.509189 s, × 2.0860, 135 µs/rev Differential Revision: https://phab.mercurial-scm.org/D9307
Tue, 01 Dec 2020 22:37:34 +0100 upgrade: start moving the "to be happening" data in a dedicated object
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 22:37:34 +0100] rev 46060
upgrade: start moving the "to be happening" data in a dedicated object The upgrade code has a lot of logic to determine which action needs to be performed depending of various element (sometimes depending from each other). It would be nice to have a consistent object representing this. That could be cleanly passed and avoid some logic duplication. So we create this object as a start. Differential Revision: https://phab.mercurial-scm.org/D9487
Sun, 06 Dec 2020 20:38:01 -0500 hg: add user-site to `sys.path` on Windows to allow pip-installed extensions
Matt Harbison <matt_harbison@yahoo.com> [Sun, 06 Dec 2020 20:38:01 -0500] rev 46059
hg: add user-site to `sys.path` on Windows to allow pip-installed extensions This has been in the TortoiseHg builds for several cycles now on Windows, and even longer on macOS. It allows an extension to be configured with `ext =` syntax, instead of requiring the full path to be specified. It's confusing for a user to be hit with messages about not being able to load extensions, based solely on which `hg.exe` is being run. This only applies to py2exe binaries, since wrapper.exe already sees into the user site area. There are no frozen binaries on other platforms (that I'm aware of), and an equivalent change will need to be made to `dispatch.py` in order to work with PyOxidizer, since it bypasses this module completely. (It also has the ability to use the `site` module, so it will look completely different.) Differential Revision: https://phab.mercurial-scm.org/D9531
Mon, 30 Nov 2020 17:13:07 +0100 rust: use crossbeam-channel crate directly
Simon Sapin <simon-commits@exyr.org> [Mon, 30 Nov 2020 17:13:07 +0100] rev 46058
rust: use crossbeam-channel crate directly … instead of its reexport in the crossbeam crate. This removes two crates from the dependency graph. Differential Revision: https://phab.mercurial-scm.org/D9521
Fri, 04 Dec 2020 12:42:23 +0100 wireprotov2: re-add tuple around `bundle2` check
Raphaël Gomès <rgomes@octobus.net> [Fri, 04 Dec 2020 12:42:23 +0100] rev 46057
wireprotov2: re-add tuple around `bundle2` check I stumbled upon this while looking for the current (v1) `capable` method. It looks like 9c2c77c73f23 accidentally removed the comma, turning the tuple into a simple parenthesis expression. This has not been detected since wireproto2 is not in use AFAIK. Differential Revision: https://phab.mercurial-scm.org/D9518
Tue, 01 Dec 2020 20:35:19 +0100 upgrade: gather code about requirement checking together
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 20:35:19 +0100] rev 46056
upgrade: gather code about requirement checking together They just moved in the same file, now they are grouped together and documented. Differential Revision: https://phab.mercurial-scm.org/D9486
Tue, 01 Dec 2020 20:24:38 +0100 upgrade: extract the checking of target requirements change
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 20:24:38 +0100] rev 46055
upgrade: extract the checking of target requirements change This logic is fairly independant, lets move it out of the main function. Differential Revision: https://phab.mercurial-scm.org/D9485
Tue, 01 Dec 2020 15:50:12 +0100 upgrade: drop an outdated comment
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 15:50:12 +0100] rev 46054
upgrade: drop an outdated comment We can control the added/removed requirement through config for multiple years. Differential Revision: https://phab.mercurial-scm.org/D9484
Tue, 01 Dec 2020 15:54:38 +0100 upgrade: gather code about source checking together
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 15:54:38 +0100] rev 46053
upgrade: gather code about source checking together They just moved in the same file, now they are grouped together and documented. Differential Revision: https://phab.mercurial-scm.org/D9483
Tue, 01 Dec 2020 15:45:23 +0100 upgrade: move requirements checking in a dedicated function
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 15:45:23 +0100] rev 46052
upgrade: move requirements checking in a dedicated function This is a simple an isolated check that can go next to the associated code. Differential Revision: https://phab.mercurial-scm.org/D9482
Tue, 01 Dec 2020 15:11:06 +0100 upgrade: split definition and management of the actions from the main code
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 15:11:06 +0100] rev 46051
upgrade: split definition and management of the actions from the main code This is a second step to clarify and clean up this code. The code responsible for definition which action exist, are possible and their compatibility if moved into a sub module. This clarify the main code and prepare further cleanup. Differential Revision: https://phab.mercurial-scm.org/D9477
Tue, 01 Dec 2020 09:13:08 +0100 upgrade: split actual upgrade code away from the main module
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 01 Dec 2020 09:13:08 +0100] rev 46050
upgrade: split actual upgrade code away from the main module The main module is getting big and hard to follow. So we are splitting all the logic to actually run an upgrade in a sub module. It nicely highlight that there are very few actual call point to the code we just moved. Differential Revision: https://phab.mercurial-scm.org/D9476
Sat, 05 Dec 2020 23:11:49 +0100 phab-refresh: add an explanatory message
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 05 Dec 2020 23:11:49 +0100] rev 46049
phab-refresh: add an explanatory message This serve two purposes: - clarify why a bot just touched this diff, - explicit the fact the tests have been run, and are passing on this version. Differential Revision: https://phab.mercurial-scm.org/D9527
Sat, 05 Dec 2020 23:32:11 +0100 phab-refresh: allow passing additional argument to the phabsend
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 05 Dec 2020 23:32:11 +0100] rev 46048
phab-refresh: allow passing additional argument to the phabsend This will be useful to pass a custom message. Differential Revision: https://phab.mercurial-scm.org/D9526
Sat, 05 Dec 2020 23:27:57 +0100 phab-refresh: do not pick draft changeset from the bare "default" branch
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 05 Dec 2020 23:27:57 +0100] rev 46047
phab-refresh: do not pick draft changeset from the bare "default" branch My initial test overlooked a common case: draft changeset on the default branch. So right now, heptapod is doing a final refresh of the patch with the landed version. This is not a bit problem except for the extra noise. However we would be better without the noise. Differential Revision: https://phab.mercurial-scm.org/D9522
Tue, 01 Dec 2020 20:22:24 +0900 log: do not accept string-matcher pattern as -u/-b/-B parameter
Yuya Nishihara <yuya@tcha.org> [Tue, 01 Dec 2020 20:22:24 +0900] rev 46046
log: do not accept string-matcher pattern as -u/-b/-B parameter I'm pretty sure this is a bug introduced after we've switched the filtering backend to revset matcher.
Tue, 01 Dec 2020 19:32:36 +0900 log: do not override other filtering and sorting options by --bookmark
Yuya Nishihara <yuya@tcha.org> [Tue, 01 Dec 2020 19:32:36 +0900] rev 46045
log: do not override other filtering and sorting options by --bookmark This basically reimplements 0aa118f18d4b 'log: add bookmark option to "hg log"'. Before, any other filtering options but --rev were ignored. -G didn't work either since the ordering constraint wasn't enforced.
Tue, 01 Dec 2020 19:23:23 +0900 scmutil: extract function that builds revset expr to select bookmark branch
Yuya Nishihara <yuya@tcha.org> [Tue, 01 Dec 2020 19:23:23 +0900] rev 46044
scmutil: extract function that builds revset expr to select bookmark branch This is needed to process "log -B" option properly. "log" options have to be translated to a revset expression, not to an evaluated set.
Tue, 01 Dec 2020 19:46:01 +0900 scmutil: document that bookmarkrevs() ignores non-head bookmark branch
Yuya Nishihara <yuya@tcha.org> [Tue, 01 Dec 2020 19:46:01 +0900] rev 46043
scmutil: document that bookmarkrevs() ignores non-head bookmark branch "- ancestors(head() and not bookmark(%s))" excludes the bookmarked branch itself if bookmark(%s) is not a head. I'm a bit surprised by this behavior while writing "log -B" tests, so let's document it.
Sat, 07 Nov 2020 16:28:30 -0800 cext: add .pyi files for C extensions
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Nov 2020 16:28:30 -0800] rev 46042
cext: add .pyi files for C extensions I'm unsure if all the annotations are completely accurate. But having these helps type checkers reason about our C extensions. Differential Revision: https://phab.mercurial-scm.org/D9281
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 46041
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 46040
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 46039
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 46038
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 46037
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 46036
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 46035
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 46034
merge with stable
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 46033
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 46032
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 46031
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 46030
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 46029
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 46028
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 46027
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 46026
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 46025
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 46024
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 46023
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 46022
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 46021
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 46020
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 46019
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 46018
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 46017
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 46016
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 46015
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 46014
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 46013
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 46012
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 46011
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 46010
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 46009
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 46008
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 46007
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 46006
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 46005
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 46004
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 46003
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 46002
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 46001
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 46000
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 45999
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 45998
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 45997
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 45996
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 45995
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 45994
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 45993
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 45992
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 45991
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 45990
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 45989
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 45988
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 45987
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 45986
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 45985
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 45984
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 45983
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 45982
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 45981
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 45980
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 45979
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 45978
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 45977
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 45976
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 45975
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 45974
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 45973
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 45972
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 45971
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 45970
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 45969
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 45968
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 45967
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 45966
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 45965
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 45964
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 45963
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 45962
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 45961
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 45960
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 45959
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 45958
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 45957
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 45956
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 45955
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 45954
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 45953
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 45952
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 45951
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 45950
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 45949
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 45948
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 45947
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 45946
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 45945
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 45944
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 45943
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 45942
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 45941
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 45940
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 45939
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 45938
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 45937
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 45936
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 45935
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 45934
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 45933
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 45932
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 45931
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 45930
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 45929
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 45928
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 45927
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 45926
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 45925
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 45924
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 45923
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 45922
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 45921
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 45920
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 45919
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 45918
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 45917
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 45916
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 45915
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 45914
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 45913
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 45912
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 45911
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 45910
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 45909
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 45908
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 45907
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 45906
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 45905
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 45904
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 45903
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 45902
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 45901
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 45900
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 45899
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 45898
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 45897
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 45896
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 45895
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 45894
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 45893
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 45892
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 45891
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 45890
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 45889
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 45888
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 45887
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 45886
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 45885
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 45884
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 45883
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 45882
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 45881
help: document the new [command-templates] config section Differential Revision: https://phab.mercurial-scm.org/D9265
(0) -30000 -10000 -3000 -1000 -240 +240 +1000 +3000 tip