Jason R. Coombs <jaraco@jaraco.com> [Wed, 17 Aug 2022 10:17:15 -0400] rev 49454
shelve: in test for trailing whitespace, strip commit (
issue6735)
Jason R. Coombs <jaraco@jaraco.com> [Mon, 15 Aug 2022 10:26:01 -0400] rev 49453
shelve: demonstrate that the state is different across platforms (
issue6735)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 20:09:31 +0200] rev 49452
phase: rename the requirement for internal-phase (BC)
The previous requirements covers both `internal` and `archived` phase. However,
the `archived` phase is not ready for usage (while the internal one is mostly
ready for years). So we split the archived on in a dedicated requirements (see
previous changeset for details) and rename the one for internal-phase. This will
avoid older client trying to use the archived phase on `internal` only
repositories.
Since the requirements stayed experimental since its introduction. It seems
fine to drop the previous version.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 19:04:23 +0200] rev 49451
phase: introduce a dedicated requirement for the `archived` phase
See inline documentation for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 18:20:42 +0200] rev 49450
phase: introduce a dedicated function to check for the archived phase
The internal-phase is "ready to use" since its introduce. However, some
question remains around the `archived` phase. So it seem safer to move them to
separated configuration and requirements. This changeset is a first of a small
series doing this.
C. Masloch <pushbx@ulukai.org> [Wed, 20 Apr 2022 19:24:39 +0200] rev 49449
rebase: add boolean config item rebase.store-source
This allows to use rebase without recording a rebase_source extra
field. This is useful for example to build a mirror converted from
another SCM (such as svn) by converting only new revisions, and
then incrementally add them to the destination by pulling from the
newly converted (unrelated) repo and rebasing the new revisions
onto the last old already stored changeset. Without this patch the
rebased changesets would always receive some rebase_source that
would depend on the particular history of the conversion process,
instead of only depending on the original source revisions.
This is used to implement a hg mirror repo of SvarDOS (a partially
nonfree but completely redistributable DOS distribution) in the
scripts at https://hg.pushbx.org/ecm/svardos.scr/
In particular, cre.sh creates an svn mirror, upd.sh recreates an
entire hg repo from the svn mirror (which takes too long to do in a
regular job), and akt.sh uses hg convert with the config item
convert.svn.startrev to incrementally convert only the two most
recent revisions already found in the mirror destination plus any
possible new revisions. If any are found, the temporary repo's
changesets are pulled into the destination (as changesets from an
unrelated repository). Then the changesets corresponding to the new
revisions are rebased onto the prior final changeset. (Finally, the
two remaining duplicates of the prior head and its parent are
stripped from the destination repository.)
Without this patch, the particular rebase_source extra field would
depend on the order and times at which akt.sh was used, instead of
only depending on the source repository. In other words, whatever
sequence of upd.sh and akt.sh is used at whatever times, it is
desired that the final output repositories always match each other
exactly.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 25 Aug 2022 16:53:56 +0100] rev 49448
tests: remove flakiness in a time-dependent test
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Jul 2022 05:30:06 +0200] rev 49447
sort-revset: introduce a `random` variant
This new `sort` variant allows to shuffle any revset. It also allow for
randomly picking element using `first`.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Aug 2022 11:36:20 +0100] rev 49446
tests: remove flakiness in test-nointerrupt.t
The problem was that the reaction to the signal was racing against
the completion of the command.
Since reaction to the signal is to print a line of warning,
we can fix this by waiting for that warning to appear before
allowing the command to complete.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Aug 2022 05:12:25 +0200] rev 49445
perf: properly process formatter option in perf::unbundle
Otherwise, the options are not understood.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Aug 2022 05:11:48 +0200] rev 49444
perf: quiet stdout output in perf::unbundle
There a lot of repetitive bundle application message we do not care about.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Aug 2022 05:10:55 +0200] rev 49443
perf: quiet stderr output in perf::unbundle
There a lot of repetitive transaction message we do not care about.
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Tue, 23 Aug 2022 17:31:27 -0400] rev 49442
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
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Tue, 23 Aug 2022 17:31:19 -0400] rev 49441
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.
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Tue, 23 Aug 2022 17:31:13 -0400] rev 49440
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.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Wed, 24 Aug 2022 16:38:13 +0100] rev 49439
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)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Jul 2022 16:25:21 +0200] rev 49438
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.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 19 Jul 2022 18:32:40 -0700] rev 49437
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`.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2022 15:37:34 -0700] rev 49436
contrib: update Mercurial install in bootstrap environment
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 04 Jun 2022 11:18:32 -0700] rev 49435
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
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 03 Jun 2022 20:25:06 -0700] rev 49434
automation: refresh requirements
I'm hitting errors installing the old version of cffi due to an
apparent issue where older versions of cffi aren't compatible with
the modern Clang I'm using. So let's upgrade packages to unbreak
things and to keep things modern.
Differential Revision: https://phab.mercurial-scm.org/D12629
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Jul 2022 15:41:45 +0200] rev 49433
debug-delta-find: introduce a quiet mode
In quiet mode, we only print the summary of the search and skip the individual
steps.
Jason R. Coombs <jaraco@jaraco.com> [Wed, 17 Aug 2022 12:03:55 -0400] rev 49432
phase-shelve: also capture the state of shelve prior to unshelve
Jason R. Coombs <jaraco@jaraco.com> [Wed, 10 Aug 2022 15:31:39 -0400] rev 49431
phase-shelve: Add test for shelve technique config
Jason R. Coombs <jaraco@jaraco.com> [Wed, 10 Aug 2022 14:39:28 -0400] rev 49430
phase-shelve: Implement a 'shelve.store' experimental config
Accepts "internal" or "strip", indicating how the shelved changes are stored. Defaults to "internal", retaining compatibility for repos with "internal-phase" already enabled.
Jason R. Coombs <jaraco@jaraco.com> [Wed, 10 Aug 2022 14:16:55 -0400] rev 49429
phase-shelve: Extract function for _target_phase
Jason R. Coombs <jaraco@jaraco.com> [Tue, 02 Aug 2022 10:29:05 -0400] rev 49428
phase-shelve: expand the tests to capture use-cases supported
Jason R. Coombs <jaraco@jaraco.com> [Thu, 28 Jul 2022 13:17:36 -0400] rev 49427
phase-shelve: honor and prefer obs shelves for existence and modified time
Jason R. Coombs <jaraco@jaraco.com> [Thu, 28 Jul 2022 12:53:11 -0400] rev 49426
phase-shelve: read patch details from a (possibly internal) node in the repo
Jason R. Coombs <jaraco@jaraco.com> [Mon, 08 Aug 2022 13:40:08 -0400] rev 49425
phase-shelve: Extract function for _optimized_match for re-use