Wed, 17 Aug 2022 10:17:15 -0400 shelve: in test for trailing whitespace, strip commit (issue6735)
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)
Mon, 15 Aug 2022 10:26:01 -0400 shelve: demonstrate that the state is different across platforms (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)
Tue, 16 Aug 2022 20:09:31 +0200 phase: rename the requirement for internal-phase (BC)
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.
Tue, 16 Aug 2022 19:04:23 +0200 phase: introduce a dedicated requirement for the `archived` phase
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.
Tue, 16 Aug 2022 18:20:42 +0200 phase: introduce a dedicated function to check for the archived phase
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.
Wed, 20 Apr 2022 19:24:39 +0200 rebase: add boolean config item rebase.store-source
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.
Thu, 25 Aug 2022 16:53:56 +0100 tests: remove flakiness in a time-dependent test stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 25 Aug 2022 16:53:56 +0100] rev 49448
tests: remove flakiness in a time-dependent test
Mon, 25 Jul 2022 05:30:06 +0200 sort-revset: introduce a `random` variant
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`.
Fri, 26 Aug 2022 11:36:20 +0100 tests: remove flakiness in test-nointerrupt.t stable
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.
Thu, 25 Aug 2022 05:12:25 +0200 perf: properly process formatter option in perf::unbundle
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.
Thu, 25 Aug 2022 05:11:48 +0200 perf: quiet stdout output in perf::unbundle
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.
Thu, 25 Aug 2022 05:10:55 +0200 perf: quiet stderr output in perf::unbundle
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.
Tue, 23 Aug 2022 17:31:27 -0400 bisect: avoid adding irrelevant revisions to bisect state
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
Tue, 23 Aug 2022 17:31:19 -0400 bisect: limit ancestors to revs topologically between good and bad revs
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.
Tue, 23 Aug 2022 17:31:13 -0400 bisect: bypass changectx when translating revs to nodes
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.
Wed, 24 Aug 2022 16:38:13 +0100 rhg: make [rhg status -v] work when it needs no extra output
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)
Thu, 28 Jul 2022 16:25:21 +0200 perf: introduce a benchmark for delta-find
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.
Tue, 19 Jul 2022 18:32:40 -0700 automation: set PATH when building on Windows stable
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`.
Sun, 17 Jul 2022 15:37:34 -0700 contrib: update Mercurial install in bootstrap environment stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jul 2022 15:37:34 -0700] rev 49436
contrib: update Mercurial install in bootstrap environment
Sat, 04 Jun 2022 11:18:32 -0700 automation: transition to Windows Server 2022 stable
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
Fri, 03 Jun 2022 20:25:06 -0700 automation: refresh requirements stable
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
Thu, 28 Jul 2022 15:41:45 +0200 debug-delta-find: introduce a quiet mode
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.
Wed, 17 Aug 2022 12:03:55 -0400 phase-shelve: also capture the state of shelve prior to unshelve
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
Wed, 10 Aug 2022 15:31:39 -0400 phase-shelve: Add test for shelve technique config
Jason R. Coombs <jaraco@jaraco.com> [Wed, 10 Aug 2022 15:31:39 -0400] rev 49431
phase-shelve: Add test for shelve technique config
Wed, 10 Aug 2022 14:39:28 -0400 phase-shelve: Implement a 'shelve.store' experimental 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.
Wed, 10 Aug 2022 14:16:55 -0400 phase-shelve: Extract function for _target_phase
Jason R. Coombs <jaraco@jaraco.com> [Wed, 10 Aug 2022 14:16:55 -0400] rev 49429
phase-shelve: Extract function for _target_phase
Tue, 02 Aug 2022 10:29:05 -0400 phase-shelve: expand the tests to capture use-cases supported
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
Thu, 28 Jul 2022 13:17:36 -0400 phase-shelve: honor and prefer obs shelves for existence and modified time
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
Thu, 28 Jul 2022 12:53:11 -0400 phase-shelve: read patch details from a (possibly internal) node in the repo
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
Mon, 08 Aug 2022 13:40:08 -0400 phase-shelve: Extract function for _optimized_match for re-use
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
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip