Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Apr 2023 17:17:31 +0200] rev 50356
delta-find: add a simple safeguard to prevent bad non-general-delta
This make it easier to catch request to build delta that does not make sense in
the general delta world.
It seems better to raise a programming error than to corrupt the repository.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Apr 2023 18:16:19 +0200] rev 50355
delta-find: never do anything fancy when general delta is off
Without general delta, the only option is to do a delta against the previous
revision in the revlog, or to do a full snapshot. So no need to dive into the
more complicated logic.
This prevent Mercurial to misbehave when applying remote deltas when
`pulled-delta-reuse-policy` was set to "try-base" or "forced" and would produce
and store invalid deltas.
We add an associated tests to make sure this scenario is covered by tests.
There are more code to cleanup after this, but I what to keep the fixing patch
simple.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Apr 2023 16:59:03 +0200] rev 50354
delta-find: assume the target-rev if not specified
This will be useful in the next patch, but I am putting it in its own commit to
make sure we can easily bisect any subtle side effect. (none are expected, but
still)
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Thu, 20 Apr 2023 09:23:58 -0400] rev 50353
chg: set CHGHG before connecting to command server
cf4d2f31 (!523) changed chg to set `CHGHG` itself when spawning a new command
server, in order to ensure that the path to the `hg` executable would be checked
during server validation. (This is useful when chg is built with `HGPATHREL`).
However, that change broke chg because it failed to set `CHGHG` before trying
to connect to an existing command server. This means that if `CHGHG` is not
present in the environment, chg will always spawn a new command server, entirely
negating the point of chg.
This breakage wasn't initially caught because of the difficulty of writing
automated tests with the `HGPATHREL` feature enabled, which meant the change
was only tested manually to make sure that it fixed the problem with `HGPATHREL`
that prompted the change.
In practice, this functionality is only really useful when chg is built with
`HGPATHREL`, so I considered wrapping it in an `#ifdef` to preserve the old
behavior by default. However, this makes it hard to write tests since one would
have to explicitly set `HGPATHREL=1` when running `run-tests.py` (which is why
the original change lacked tests). It would be great if there were a way of
testing features that are gated behind conditional compilation.
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Mon, 24 Apr 2023 10:30:08 -0400] rev 50352
chg: declare environ (
issue6812)
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Apr 2023 11:48:22 +0200] rev 50351
relnotes: add 6.4.2
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Apr 2023 11:41:03 +0200] rev 50350
Added signature for changeset
f952be90b051
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Apr 2023 11:40:57 +0200] rev 50349
Added tag 6.4.2 for changeset
f952be90b051
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Apr 2023 01:23:27 +0200] rev 50348
revlog-split: make sure the self._indexfile attribut is reset (
issue6811)
Before this change, after a transaction committing a file split, a revlog
object would have its `self._indexfile` attribute desynchronised from the
actual file storing the data. If that same object is reused (as we do for the
manifest during clone bundles), this lead to the data being writting in the
wrong location and the repository to go corrupt.
We not properly reset the attribut when applicable and everything is back in
working order.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Apr 2023 00:07:52 +0200] rev 50347
revlog-split: also check a case where bundle contains multiple changegroup
This case is not affected, we remains in the same transaction. However it seems
important to improve the test coverage around these "features". It also helped
to assert the scop of the critical bug.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Apr 2023 01:12:00 +0200] rev 50346
revlog-split: show manifest data loss situation when using clonebundle
After the commit of the transaction from applying the clone bundle, changes to
the manifest from the subsequent pull would write index data in the wrong file.
This lead to data being "lost" after the pull and the repository to be
corrupted. We add a test checking this specific scenario.
In practice, the issue only affects the manifest but we also test the issue with a file for future proofing things up.
See test documentation and failure for details.
Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:21:01 +0200] rev 50345
Added signature for changeset
83ea6ce48b4f
Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:21:00 +0200] rev 50344
Added tag 6.4.1 for changeset
83ea6ce48b4f
Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:20:26 +0200] rev 50343
relnotes: add 6.4.1
pacien <pacien.trangirard@pacien.net> [Wed, 12 Apr 2023 17:28:39 +0200] rev 50342
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 50341
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 50340
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 50339
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> [Sat, 01 Apr 2023 05:58:59 +0200] rev 50338
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 50337
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
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Mon, 27 Mar 2023 17:30:14 -0400] rev 50336
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 50335
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 50334
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.
Manuel Jacob <me@manueljacob.de> [Mon, 27 Mar 2023 06:24:44 +0200] rev 50333
commands: correct documentation of hg serve’s --ipv6 option
When the --ipv6 option is given, the server doesn’t listen to a IPv4 socket.
This can be verified by running two servers, one with and one
without the option, which works fine.
I think that listening to both a IPv4 and a IPv6 socket would be better,
but given that the Python standard library class underlying the
HTTP server supports only one socket, this is not trivial.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 24 Mar 2023 19:19:37 +0000] rev 50332
rhg: don't crash on empty directory names in path_encode, just in case
I don't expect that to be possible, but there's nothing in path_encode.rs
that prevents it, and the old code didn't crash in this case, so it's
better to be defensive.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 24 Mar 2023 19:02:46 +0000] rev 50331
rhg: fix a bug in path encoding, demonstrated in the parent commit
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 24 Mar 2023 19:01:03 +0000] rev 50330
rhg: show a bug in the rust implementation of path_encode introduced recently
In commit
96d31efd21f7 I did a refactoring where I dropped a chunk
of code by accident, thus introducing a bug.
This commit adds a test demonstrating that bug.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Mar 2023 02:22:12 -0400] rev 50329
typing: correct the signature of error.CommandError
There's a place in `mercurial.dispatch._parse()` that passes None if a parse
error happens before the command can be parsed out, and casting the error to
bytes works fine because the command and message fields are apparently ignored.
Likewise, TortoiseHg similarly passes None for the same reason.
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Mar 2023 00:11:38 +0100] rev 50328
Added signature for changeset
f14864fffdca
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Mar 2023 00:11:31 +0100] rev 50327
Added tag 6.4 for changeset
f14864fffdca
Raphaël Gomès <rgomes@octobus.net> [Thu, 23 Mar 2023 22:01:34 +0100] rev 50326
relnotes: do 6.4
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 23 Mar 2023 11:36:25 +0000] rev 50325
hooks: invalidate the repo after the hooks
Since the hooks may have changed the repository content it seems safer to
invalidate it. The invalidation is "soft", the data are kept around and few
work will be needed to restore them if nothing actually changed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Mar 2023 21:18:54 +0000] rev 50324
dirstate: try refreshing the changelog when parent are unknown
See inline comment for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 Mar 2023 21:18:14 +0000] rev 50323
localrepo: add a `currentlock` method
It mirrors he `currentwlock` function.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 23 Mar 2023 11:24:47 +0000] rev 50322
dirstate: add a test to highlight another changelog / dirstate race
Raphaël Gomès <rgomes@octobus.net> [Thu, 23 Mar 2023 19:10:15 +0100] rev 50321
rust: fix thread cap (for real this time)
Both
e2f8ed37201c and
c52435820bbd failed to put a *default* ceiling on
the number of threads used by Rayon to prevent a contention issue.
Calling `rayon::available_parallelism()` creates the global threadpool,
which made our whole dance useless last time.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Wed, 22 Mar 2023 17:18:32 +0000] rev 50320
tests: accept a test output change in [tests/test-serve.t]
This fixes a breakage introduced in
adecb1ab4a0d.
It was not caught by the CI probably because allows
binding to port 13.
Mads Kiilerich <mads@kiilerich.com> [Tue, 21 Mar 2023 17:07:22 +0100] rev 50319
py3: fix for Python 3.12 emitting SyntaxWarning on invalid escape sequences
Missed in
805d4a462abb:
$ python3.12 mercurial/store.py
mercurial/store.py:406: SyntaxWarning: invalid escape sequence '\.'
EXCLUDED = re.compile(b'.*undo\.[^/]+\.(nd?|i)$')
Julien Cristau <jcristau@mozilla.com> [Tue, 21 Mar 2023 15:27:03 +0100] rev 50318
url: don't ignore timeout for https connections
For http, we use the stdlib's HTTPConnection.connect which passes the
timeout down to socket.create_connection; for https, we override the
connect method but weren't handling the timeout, so connections could
hang for hours even with http.timeout set to low values.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Mar 2023 15:44:38 +0000] rev 50317
debugdeltachain: stop summing the same chain over and over
Before this patch, delta chain size was computed from scratch for each chain,
disregarding the fact very likely already computed the same of length-1 prefix
for another revisions.
We not cache delta chain size and shortcut the computation when we see them.
Just for my mercurial-devel clone, this move the computation from about 17.5
second to about 4.8 seconds.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:52:17 +0100] rev 50316
revlog: improve the robustness of the splitting process
The previous "in-place" splitting, preserving the splitting on transaction
failure had a couple of issue in case of transaction rollback:
- a race windows that could still lead to a crash and data loss
- it corrupted the `fncache`.
So instead, we use a new approach that we summarized as "we do a backup of the
inline revlog pre-split, and we restore this in case of failure".
To make readers live easier, we don't overwrite the inline index file until
transaction finalization. (once the transaction get into its finalization phase,
it is not expected to rollback, unless some crash happens).
To do so, we write the index of the split index in a temporary file that we use
until transaction finalization. We also keep a backup of the initial inline file
to be able to rollback the split if needed.
As a result, transaction rollback cancel the split and no longer corrupt
fncache. We also no longer have a small inconsistency windows where the
transaction could be unrecoverable.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:40:18 +0100] rev 50315
fncache: make it possible to ignore some file
In the next changeset, we need to able to ignore some temporary file. This
changeset teach the fncache about that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Mar 2023 11:09:03 +0100] rev 50314
revlog: test that pending hooks properly see the repository on split
This seems important to explicitly cover this case before changing the code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Mar 2023 02:46:51 +0100] rev 50313
revlog: test possible read race condition with splitting
This is currently working fine, but could break with another approach (for
example, with the one we are about to use in the next changesets…)
So we make sure the case is covered.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Mar 2023 21:04:52 +0100] rev 50312
revlog: add a failing variant of the the split + transaction test
We have another variant to tests, and it is crashing… So lets cover it with
tests.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Mar 2023 20:37:11 +0100] rev 50311
revlog: update the split + transaction test
We add section, increase the amount of comments and simplify some of the
constructs. We are about to build more on top this tests so lets do a small
cleanup first.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 14:29:37 +0100] rev 50310
transaction: allow to backup file that already have an offset
This will be useful in the next changeset to deal with rolling back the split of
inline revlog on transaction failure.
This involve deeper change to the transaction logic as we need to make sure we
restore the backup -before- the truncation step. Otherwise, the truncation
would act on the wrong file and be overwritten by the backup restoration later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 13:20:12 +0100] rev 50309
transaction: move the restoration of backup file in a small closure
We are about to use that logic in two different location, making is a small
reusable closure prepares that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 12:13:08 +0100] rev 50308
transaction: raise on backup restoration error
A few line above, similar errors in the truncation code result in raising the
associated exception. We should do the same here.
This means the transaction recover is more strict now, which might be a problem
when running `hg recover` in a share different from the one where the
transaction fails. However this has always been a problem and need to be be
addressed independently.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 12:08:05 +0100] rev 50307
transaction: add clarifying comment about why ignoring some error is fine
It is less scary when explained.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 11:18:24 +0100] rev 50306
transaction: properly clean up backup file outside of .hg/store/
Oops.
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 17:13:38 +0100] rev 50305
statprof: with Python 3.12, lineno is (more) often None
test-profile.t failed with errors like:
TypeError: %d format: a real number is required, not NoneType
statprof.py already handled None values as -1 in some cases. Do the same in
more cases.
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 16:45:54 +0100] rev 50304
py3: fix for Python 3.12 emitting SyntaxWarning on invalid escape sequences
Mercurial became very noisy after https://github.com/python/cpython/commit/
a60ddd31be7ff96a8189e7483bf1eb2071d2bddf ,
for example:
$ python3.12 mercurial/store.py
mercurial/store.py:406: SyntaxWarning: invalid escape sequence '\.'
EXCLUDED = re.compile(b'.*undo\.[^/]+\.(nd?|i)$')
This verbosity made some tests fail.
The problems were mostly insufficiently escaped regexps, relying on the Python
parser/scanner preserving invalid escape sequences.
Mads Kiilerich <mads@kiilerich.com> [Tue, 07 Mar 2023 16:25:51 +0100] rev 50303
cext: fix for PyLong refactoring in CPython 3.12
Compiling Mercurial with Python 3.12 a5 would fail with:
mercurial/cext/dirs.c: In function '_addpath':
mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit'
19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0]
| ^~
mercurial/cext/dirs.c:97:25: note: in expansion of macro 'PYLONG_VALUE'
97 | PYLONG_VALUE(val) += 1;
| ^~~~~~~~~~~~
mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit'
19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0]
| ^~
mercurial/cext/dirs.c:108:17: note: in expansion of macro 'PYLONG_VALUE'
108 | PYLONG_VALUE(val) = 1;
| ^~~~~~~~~~~~
mercurial/cext/dirs.c: In function '_delpath':
mercurial/cext/dirs.c:19:44: error: 'PyLongObject' {aka 'struct _longobject'} has no member named 'ob_digit'
19 | #define PYLONG_VALUE(o) ((PyLongObject *)o)->ob_digit[0]
| ^~
mercurial/cext/dirs.c:145:23: note: in expansion of macro 'PYLONG_VALUE'
145 | if (--PYLONG_VALUE(val) <= 0) {
| ^~~~~~~~~~~~
This was caused by
https://github.com/python/cpython/commit/
c1b1f51cd1632f0b77dacd43092fb44ed5e053a9 .
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 27 Oct 2022 17:34:02 -0400] rev 50302
histedit: fix diff colors
The problem here is that indexing a bytestring gives you integers, not
chars, so the comparison to b'+' ends up being wrong.
We don't really have a way to test curses output, so no tests to
verify the correctness of this behaviour.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Mar 2023 05:49:56 +0100] rev 50301
dirstate: fix a potential traceback when in `copy` and `rename`
Before this changes, calling `hg copy` or `hg rename` could trigger a traceback
about using an invalidated dirstate. This wasn't caught by the test as it needed
the blackbox extension to preload the dirstate first in a way "refresh"
invalidates it.
Changing the context creation patterns fixes it.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 14 Mar 2023 14:08:38 +0000] rev 50300
dirstate: fix the bug in [status] dealing with committed&ignored directories
In particular, these directories can "infect" their sibling directories with
ignored status due to using a shared memoization cell by accident.
This fixes bug #6795.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 14 Mar 2023 14:01:47 +0000] rev 50299
tests: demonstrate a bug with committed&ignored dirs
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Mar 2023 12:04:25 +0100] rev 50298
rust: remove out-of-date comment
We've migrated to a newer version of Rust, so it doesn't make sense anymore.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Mar 2023 12:00:25 +0100] rev 50297
rust: upgrade `rayon` dependency
This includes a potential soundness fix as well as some improvements to
performance which should be helpful.