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
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
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
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
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
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
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
Martin von Zweigbergk <martinvonz@google.com> [Sun, 13 Dec 2020 18:29:22 -0800] rev 46113
branching: merge with stable
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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.
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.
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
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
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
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
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
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
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
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
Augie Fackler <augie@google.com> [Thu, 03 Dec 2020 14:15:39 -0500] rev 46034
merge with stable
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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