bisect: avoid adding irrelevant revisions to bisect state
When adding new revisions to the bisect state, it only makes sense to add
information about revisions that are under consideration (i.e., those that are
topologically between the known good and bad revisions). However, if the user
passes in a revset (e.g., '!merge()' to exclude merge commits), hg will resolve
the revset first and add all matching revisions to the bisect state (which in
this case would likely be the majority of revisions in the repo). To avoid this,
revisions should only be added to the bisect state if they are between the good
and bad revisions (and therefore relevant to the bisection).
--
Here are the results of some performance tests using the `mozilla-central` repo
(since it is one of the largest freely-available hg repositories in the wild).
These tests compare the performance of a locally-built `hg` before and after
application of this series. Note that `--noupdate` is passed to avoid including
update time (which should not vary across cases).
Setup (run between each test):
$ hg bisect --reset
$ hg bisect --noupdate --bad
56c3ad4bde5c70714b784ccf15d099e0df0f5bde
$ hg bisect --noupdate --good
57426696adaf08298af3027fa77486fee0633b13
Test using a revset that returns a very large number of revisions:
$ time hg bisect --noupdate --skip '!merge()' > /dev/null
Before:
real 0m9.398s
user 0m9.233s
sys 0m0.120s
After:
real 0m1.513s
user 0m1.425s
sys 0m0.052s
Test using a revset that is expensive to compute:
$ time hg bisect --noupdate --skip 'desc("Bug")' > /dev/null
Before:
real 0m49.853s
user 0m49.580s
sys 0m0.243s
After:
real 0m4.120s
user 0m4.036s
sys 0m0.048s
bisect: limit ancestors to revs topologically between good and bad revs
Previously, when constructing its dict of revisions to their ancestors, bisect
would populate the dict with ALL of the descendents of the good set, which is
a bit silly because it is impossible for a revision that is a descendent of the
minimum known bad revision to be the first bad rev. Instead it makes more sense
to limit the revisions to just those topologically between the good and bad.
bisect: bypass changectx when translating revs to nodes
When resolving the revset given by the user into node hashes, use the changelog
to perform the translation rather than the repo object. This avoids the overhead
of constructing a changectx which is immediately discarded.
rhg: make [rhg status -v] work when it needs no extra output
Add support for verbose [status] when no extra output is actually needed.
This makes it so that [rhg status] is actually useful when
[tweakdefaults] is true. (since tweakdefaults implies verbose status)
perf: introduce a benchmark for delta-find
That part is responsible of serious slowdown in some `hg pull/unbundle` case. So
lets add a way to benchmark it.
automation: set PATH when building on Windows
Sometime in the 6.2 release cycle the Windows building automation
broke. Building the wheel and even PyOxidizer based installers now fails
with:
```
Exception: PowerShell execution failed: error: subprocess-exited-with-error
Getting requirements to build wheel did not run successfully.
exit code: 1
[1 lines of output]
Unable to find a working hg binary to extract the version from the repository tags
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
```
I have a hunch this is a regression from upgrading pip in
1c00777702da,
but I haven't verified this. It may not be, as PyOxidizer has its own
bundled Python/pip. So maybe it is something in `setup.py`.
automation: transition to Windows Server 2022
Let's keep our Windows build environment modern by upgrading to the
latest OS.
As part of the upgrade, we pick up a migration to EC2Launch Version 2.
This has a different config mechanism. So we need to port how we manage
the administrator password.
As part of migrating to the new YAML/JSON config file mechanism, we move
the code to the powershell script that is run when the instance first
launches. This ensures that the config is retained during the reboot we
perform as part of building the Windows AMI.
The motivation for this is I'm currently unable to build the Windows
2019 AMI due to an issue installing OpenSSH. This _just works_ on
Windows Server 2022. I have no clue what the root cause is. I think
it might have something to do with Microsoft not publishing the files
in the right location.
Differential Revision: https://phab.mercurial-scm.org/D12630