Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 16 Aug 2022 18:20:42 +0200] rev 49474
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 49473
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Jul 2022 05:30:06 +0200] rev 49472
sort-revset: introduce a `random` variant
This new `sort` variant allows to shuffle any revset. It also allow for
randomly picking element using `first`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Aug 2022 05:12:25 +0200] rev 49471
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 49470
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 49469
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 49468
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