Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:20:26 +0200] rev 50399
relnotes: add 6.4.1
pacien <pacien.trangirard@pacien.net> [Wed, 12 Apr 2023 17:28:39 +0200] rev 50398
sslutil: set context security level for legacy tls testing (issue6760)
Current versions of OpenSSL do not allow the use of TLS <1.2 when the
library's security level is >=1 (1 being the default on most distributions).
Setting the security level in addition to the minimum protocol is therefore
necessary for the legacy protocol tests.
This is done here ONLY when testing, when:
- explicitly setting the cipher string, or
- using the "--insecure" flag, or
- using the "devel.serverexactprotocol" testing option.
See: https://github.com/openssl/openssl/blob/master/NEWS.md#major-changes-between-openssl-30-and-openssl-310-14-mar-2023
pacien <pacien.trangirard@pacien.net> [Thu, 13 Apr 2023 11:28:48 +0200] rev 50397
configitems: make devel.serverexactprotocol look dangerous
Because it is.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Apr 2023 04:12:31 +0200] rev 50396
rebase: do not cleanup the working copy when --dry-run is used (issue6802)
Since we did not touch the working copy, we don't need to clean it up. This
will avoid wiping exiting changes out.
Raphaël Gomès <rgomes@octobus.net> [Tue, 11 Apr 2023 17:06:08 +0200] rev 50395
rebase: add a test showing that --dry-run wipes working copy changes
Eating people's data on --dry-run seems like a bad idea.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Apr 2023 00:57:01 +0200] rev 50394
tests: automatically glob the discovery timing information
Time is not stable in tests.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 06 Apr 2023 11:41:51 +0100] rev 50393
rhg: support `status --print0`
This seems very easy to support, and useful because it makes it possible
to parse the [hg status] output even if the user creates files
with '\n' characters by accident.
pacien <pacien.trangirard@pacien.net> [Thu, 30 Mar 2023 22:22:44 +0200] rev 50392
stabletailgraph: implement stable-tail sort
This adds the computation of the "stable-tail sort", an incremental node
sorting method. It is a stepping stone for the implementation of faster
label discovery (for example for obs markers) and more caching.
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Apr 2023 16:09:08 +0200] rev 50391
heptapod: add `.gitattributes` file to improve language detection
I am fully aware of the irony.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Apr 2023 05:58:59 +0200] rev 50390
match: match explicit file using a set
The matcher as all the logic to do quick comparison against explicit patterns,
however the pattern matcher was shadowing the code using that set and used the
compiled regex pattern in all cases, which is quite slow. We restore the usage
of the set based matching to boost performance.
Building the regexp is still consuming a large amount of time (actually, the
majority of the time), which is still silly. Maybe using re2 would help that,
but this is a quest for another adventure.
Another path to improve this is to have a pattern type dedicated to match the
exact path to a file only (not a directory). This pattern could use the set
matching only and be skipped in the regex all together.
Benchmarks
==========
In the following benchmark we are comparing the `hg cat` and `hg files` run
time when matching against all files in the repository. They are
run:
- without the rust extensions
- with the standard python engine (so without re2)
Performance improvement in this series
--------------------------------------
###### hg files ###############################################################
### mercurial-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 0.230092 seconds
prev-changeset: 0.230069 seconds
this-changeset: 0.211425 seconds (-8.36%)
### mercurial-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 0.234235 seconds
prev-changeset: 0.231165 seconds (-1.38%)
this-changeset: 0.212300 seconds (-9.43%)
### pypy-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 0.613567 seconds
prev-changeset: 0.616799 seconds
this-changeset: 0.510852 seconds (-16.82%)
### pypy-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 0.801880 seconds
prev-changeset: 0.616393 seconds (-23.22%)
this-changeset: 0.511903 seconds (-36.23%)
### netbeans-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 21.541828 seconds
prev-changeset: 21.586773 seconds
this-changeset: 13.648347 seconds (-36.76%)
### netbeans-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 172.759857 seconds
prev-changeset: 21.908197 seconds (-87.32%)
this-changeset: 13.945110 seconds (-91.93%)
### mozilla-central-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 62.474221 seconds
prev-changeset: 61.279490 seconds (-1.22%)
this-changeset: 29.529469 seconds (-52.40%)
### mozilla-central-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 1364.180218 seconds
prev-changeset: 62.473549 seconds (-95.40%)
this-changeset: 30.625249 seconds (-97.75%)
###### hg cat #################################################################
### mercurial-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 0.764407 seconds
prev-changeset: 0.763883 seconds
this-changeset: 0.737326 seconds (-3.68%)
### mercurial-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 0.768924 seconds
prev-changeset: 0.765848 seconds
this-changeset: 0.174d0b seconds (-4.44%)
### pypy-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 2.065220 seconds
prev-changeset: 2.070498 seconds
this-changeset: 1.939482 seconds (-6.08%)
### pypy-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 2.276388 seconds
prev-changeset: 2.069197 seconds (-9.15%)
this-changeset: 1.931746 seconds (-15.19%)
### netbeans-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 40.967983 seconds
prev-changeset: 41.392423 seconds
this-changeset: 32.181681 seconds (-22.20%)
### netbeans-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 216.388709 seconds
prev-changeset: 41.648689 seconds (-80.88%)
this-changeset: 32.580817 seconds (-85.04%)
### mozilla-central-2018-08-01-zstd-sparse-revlog ### sorted
base-changeset: 105.228510 seconds
prev-changeset: 103.315670 seconds (-1.23%)
this-changeset: 69.416118 seconds (-33.64%)
### mozilla-central-2018-08-01-zstd-sparse-revlog ### shuffled
base-changeset: 1448.722784 seconds
prev-changeset: 104.369358 seconds (-92.80%)
this-changeset: 70.554789 seconds (-95.13%)
Different way to list the same data with this revision
------------------------------------------------------
###### hg files ###############################################################
### mercurial-2018-08-01-zstd-sparse-revlog
root: 0.119182 seconds
glob: 0.120697 seconds (+1.27%)
sorted: 0.211425 seconds (+77.40%)
shuffled: 0.212300 seconds (+78.13%)
### pypy-2018-08-01-zstd-sparse-revlog
root: 0.121986 seconds
glob: 0.124822 seconds (+2.32%)
sorted: 0.510852 seconds (+318.78%)
shuffled: 0.511903 seconds (+319.64%)
### netbeans-2018-08-01-zstd-sparse-revlog
root: 0.173984 seconds
glob: 0.227203 seconds (+30.59%)
sorted: 13.648347 seconds (+7744.59%)
shuffled: 13.945110 seconds (+7915.16%)
### mozilla-central-2018-08-01-zstd-sparse-revlog
root: 0.366463 seconds
glob: 0.491030 seconds (+33.99%)
sorted: 29.529469 seconds (+7957.96%)
shuffled: 30.625249 seconds (+8256.97%)
###### hg cat #################################################################
### mercurial-2018-08-01-zstd-sparse-revlog
glob: 0.647471 seconds
root: 0.643120 seconds
shuffled: 0.174d0b seconds (+13.92%)
sorted: 0.737326 seconds (+13.88%)
### mozilla-central-2018-08-01-zstd-sparse-revlog
glob: 40.596983 seconds
root: 40.129136 seconds
shuffled: 70.554789 seconds (+73.79%)
sorted: 69.416118 seconds (+70.99%)
### netbeans-2018-08-01-zstd-sparse-revlog
glob: 18.777924 seconds
root: 18.613905 seconds
shuffled: 32.580817 seconds (+73.51%)
sorted: 32.181681 seconds (+71.38%)
### pypy-2018-08-01-zstd-sparse-revlog
glob: 1.555319 seconds
root: 1.536534 seconds
shuffled: 1.931746 seconds (+24.20%)
sorted: 1.939482 seconds (+24.70%)
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Apr 2023 05:57:09 +0200] rev 50389
match: sort patterns before compiling them into a regex
While investigating cripping performance for `hg cat` in some context, I
discovered that, for large inputs, building a regex from out of order patterns
result may result in a *much* slower regex and a much slower associated
matcher's performance.
So we are now sorting the patterns to help the regex engine.
There is more to the story as we rely on regexp more than we should. See the
next changeset for details.
Benchmarks
==========
In the following benchmark we are comparing the `hg cat` and `hg files` run
time when matching against the full list of files in the repository. They are
run:
- without the rust extensions
- with the standard python enfine (so without re2)
sort vs non-sorted - Before this changeset (3f5137543773)
---------------------------------------------------------
###### hg files ###############################################################
### mercurial-2018-08-01-zstd-sparse-revlog
sorted: 0.230092 seconds
shuffled: 0.234235 seconds (+1.80%)
### pypy-2018-08-01-zstd-sparse-revlog
sorted: 0.613567 seconds
shuffled: 0.801880 seconds (+30.69%)
### mozilla-central-2018-08-01-zstd-sparse-revlog
sorted: 62.474221 seconds
shuffled: 1364.180218 seconds (+2083.59%)
### netbeans-2018-08-01-zstd-sparse-revlog
sorted: 21.541828 seconds
shuffled: 172.759857 seconds (+701.97%)
###### hg cat #################################################################
### mercurial-2018-08-01-zstd-sparse-revlog
sorted: 0.764407 seconds
shuffled: 0.768924 seconds
### pypy-2018-08-01-zstd-sparse-revlog
sorted: 2.065220 seconds
shuffled: 2.276388 seconds (+10.22%)
### netbeans-2018-08-01-zstd-sparse-revlog
sorted: 40.967983 seconds
shuffled: 216.388709 seconds (+428.19%)
### mozilla-central-2018-08-01-zstd-sparse-revlog
sorted: 105.228510 seconds
shuffled: 1448.722784 seconds (+1276.74%)
sort vs non-sorted - With this changeset
----------------------------------------
###### hg files ###############################################################
### mercurial-2018-08-01-zstd-sparse-revlog
all-list-pattern-sorted: 0.230069
all-list-pattern-shuffled: 0.231165
### pypy-2018-08-01-zstd-sparse-revlog
all-list-pattern-sorted: 0.616799
all-list-pattern-shuffled: 0.616393
### netbeans-2018-08-01-zstd-sparse-revlog
all-list-pattern-sorted: 21.586773
all-list-pattern-shuffled: 21.908197
### mozilla-central-2018-08-01-zstd-sparse-revlog
all-list-pattern-sorted: 61.279490
all-list-pattern-shuffled: 62.473549
###### hg cat #################################################################
### mercurial-2018-08-01-zstd-sparse-revlog
sorted: 0.763883 seconds
shuffled: 0.765848 seconds
### pypy-2018-08-01-zstd-sparse-revlog
sorted: 2.070498 seconds
shuffled: 2.069197 seconds
### netbeans-2018-08-01-zstd-sparse-revlog
sorted: 41.392423 seconds
shuffled: 41.648689 seconds
### mozilla-central-2018-08-01-zstd-sparse-revlog
sorted: 103.315670 seconds
shuffled: 104.369358 seconds
Manuel Jacob <me@manueljacob.de> [Fri, 07 Apr 2023 15:42:49 +0200] rev 50388
peer: rename makepeer() → _make_peer()
In httppeer and sshpeer, there previously were makepeer() and make_peer(),
which was confusing. Therefore, this changeset renames one of the functions.
makepeer() was the internal function called by make_peer() and some debug
command. This function is renamed to _make_peer().
Georges Racinet <georges.racinet@octobus.net> [Tue, 04 Apr 2023 11:58:35 +0200] rev 50387
rust: configure MSRV in Clippy
This setting makes Clippy never apply lints that are meant for
later versions. In case the target precise toolchain is the one
running, it does not make a difference, but this gives us a
machine-parseable specification that is pretty standard.
The README and `hg help rust` are updated to state that `clippy.toml`
is the single source of truth about that, also lifting a minor ambiguity:
it is fine if the MSRV is lagging behind the version in Debian testing.
Georges Racinet <georges.racinet@octobus.net> [Tue, 04 Apr 2023 11:47:32 +0200] rev 50386
rust-readme: mentioned that format check is enforced by CI
Georges Racinet <georges.racinet@octobus.net> [Tue, 04 Apr 2023 11:46:26 +0200] rev 50385
rust-readme: mentioning clippy
especially since there is a CI check for it.
Georges Racinet <georges.racinet@octobus.net> [Tue, 04 Apr 2023 11:44:43 +0200] rev 50384
rust-readme: rst fixes
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Mon, 27 Mar 2023 17:30:14 -0400] rev 50383
chg: populate CHGHG if not set
Normally, chg determines which `hg` executable to use by first consulting the
`$CHGHG` and `$HG` environment variables, and if neither are present defaults
to the `hg` found in the user's `$PATH`. If built with the `HGPATHREL` compiler
flag, chg will instead assume that there exists an `hg` executable in the same
directory as the `chg` binary and attempt to use that.
This can cause problems in situations where there are multiple actively-used
Mercurial installations on the same system. When a `chg` client connects to a
running command server, the server process performs some basic validation to
determine whether a new command server needs to be spawned. These checks include
things like checking certain "sensitive" environment variables and config
sections, as well as checking whether the mtime of the extensions, hg's
`__version__.py` module, and the Python interpreter have changed.
Crucially, the command server doesn't explicitly check whether the executable it
is running from matches the executable that the `chg` client would have
otherwise invoked had there been no existing command server process. Without
`HGPATHREL`, this still gets implicitly checked during the validation step,
because the only way to specify an alternate hg executable (apart from `$PATH`)
is via the `$CHGHG` and `$HG` environment variables, both of which are checked.
With `HGPATHREL`, however, the command server has no way of knowing which hg
executable the client would have run. This means that a client located at
`/version_B/bin/chg` will happily connect to a command server running
`/version_A/bin/hg` instead of `/version_B/bin/hg` as expected. A simple
solution is to have the client set `$CHGHG` itself, which then allows the
command server's environment validation to work as intended.
I have tested this manually using two locally built hg installations and it
seems to work with no ill effects. That said, I'm not sure how to write an
automated test for this since the `chg` available to the tests isn't even built
with the `HGPATHREL` compiler flag to begin with.
pacien <pacien.trangirard@pacien.net> [Fri, 07 Apr 2023 12:11:44 +0200] rev 50382
run-tests: remove obsolete coverage check and packaging import (issue6805)
This removes an obsolete `coverage` version check (version from a decade ago).
This also conveniently removes the dependency over `packaging.version`,
which requires some additional installation since Python 3.10.
pacien <pacien.trangirard@pacien.net> [Wed, 05 Apr 2023 11:58:25 +0200] rev 50381
test-tx-rollback: more lenient glob for kill status (issue6807)
The "killed" message may have some prefix and/or suffix which differ
depending on the platform.
This makes the pinned test output more lenient to accept those.
Georges Racinet <georges.racinet@octobus.net> [Mon, 03 Apr 2023 16:29:30 +0200] rev 50380
rustdoc: nodemap doc refreshing
Not pretending to be comprehensive.
- correcting some inconsistencies
- adding a few missing doc-comments
- adding more cross references (in some cases it's right beside
the current documentation item, but it will nevertheless also
be useful, because `rustdoc` will warn us if inconsistencies
arise).
Georges Racinet <georges.racinet@octobus.net> [Mon, 03 Apr 2023 16:14:34 +0200] rev 50379
rustdoc: fixed or introduced crossrefs in nodemap.rs
Georges Racinet <georges.racinet@octobus.net> [Mon, 03 Apr 2023 16:03:41 +0200] rev 50378
rustdoc: summary line for hg_path_to_os_string
The main motivation of this change is to avoid the TODO being
the summary line, even though this leads to a pretty obvious summary.
Then doc-comments for the other functions are introduced for
consistency.
Georges Racinet <georges.racinet@octobus.net> [Mon, 03 Apr 2023 15:58:36 +0200] rev 50377
rustdoc: wording for checkexec
Notably separating the summary line for correct display
at module level.
Georges Racinet <georges.racinet@octobus.net> [Mon, 03 Apr 2023 15:32:39 +0200] rev 50376
rustdoc: fixed warnings about links
This is the minimal fix making those that actually were supposed
to be links to work (including in private items).
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:21:38 +0200] rev 50375
rust-changelog: introduce ChangelogEntry parent entries accessors
Straightforwards now that lifetimes are explicit in `RevlogEntry`
parent accessors.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:20:53 +0200] rev 50374
rust-revlog: fix lifetime problem for RevlogEntry parent entries accessors
Without this, the lifetime of the result is equated to the lifetime of the
`self` reference, preventing callers, e.g., to take a `RevlogEntry` and
return its `p1_entry()`, as it looks like returning something that does not
outlive the *reference to* the `RevlogEntry`.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 Mar 2023 12:14:57 +0200] rev 50373
rust-revlog: explicit naming for `RevlogEntry` lifetime
This matches what has been done in `revlog::changelog::ChangelogRevisionData`,
and has the advantage of making things clearer when we introduce other, shorter
lived lifetimes.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 Mar 2023 20:50:42 +0200] rev 50372
rust-changelog: introducing an intermediate `ChangelogEntry`
Before this change, client code needing to extract, e.g, the Node ID and the
description from a changeset had no other choice than calling both
`entry_for_rev()` and `data_for_rev()`. This duplicates some (limited) computation, and
more importantly imposes bad hygiene for client code: at some point of developement,
the client code would have to pass over both entry and data in its internal layers,
which at some point of development would raise the question whether they are consistent.
We introduce the intermediate `ChangelogEntry` from which both conversion to the generic
`RevlogEntry` and extraction of `ChangelogRevisionData` are possible.
It might grow some convenience methods in the future.
We keep the `data_for_rev()` method of `Changelog` for compatibility, pointing users at the more
powerful alternative.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 Mar 2023 21:03:39 +0200] rev 50371
rust-changelog: added a test for `NULL_REVISION` special case
The result is due to `Revlog.get_rev_data()` returning an empty
byte string for `NULL_REVISION`, followed by special case for
emtpty byte strings in `ChangelogRevisionData::new()`.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 Mar 2023 20:24:58 +0200] rev 50370
rust-changelog: made doc-comments more consistent
The most important is the one about `data_for_rev`, that looked like
a copy-paste leftover (got me confused first time I read this code, before
I actually learned there were both `Entry` and RevisionData`.
In the comment for the `struct`, "changelog" was probably more about
the format in general (as documented elsewhere) than as an identifier.
Some of the "Return something" had "of", half had "for".