Thu, 08 Jun 2023 02:35:03 +0200 delta-find: intrduce a `_one_dbg_data` method stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2023 02:35:03 +0200] rev 50380
delta-find: intrduce a `_one_dbg_data` method This helps with the initialisation of the expected debug information.
Thu, 08 Jun 2023 01:52:35 +0200 delta-find: move final debug processing in a `_dbg_process_data` method stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2023 01:52:35 +0200] rev 50379
delta-find: move final debug processing in a `_dbg_process_data` method This will help us making sure we can call the necessary debugging code in alternative codepath.
Thu, 08 Jun 2023 01:19:01 +0200 delta-fine: use the `_debug_search` attribute directly stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2023 01:19:01 +0200] rev 50378
delta-fine: use the `_debug_search` attribute directly By adjusting the value at creation time, we can avoid the need to use and intermediate variable.
Thu, 08 Jun 2023 01:11:47 +0200 delta-find: move the `gather_debug` logic in a property stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2023 01:11:47 +0200] rev 50377
delta-find: move the `gather_debug` logic in a property This will make it simpler to get be reused in multiple places.
Thu, 08 Jun 2023 01:07:00 +0200 tests: check `pulled-delta-reuse-policy=forced` without general delta stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Jun 2023 01:07:00 +0200] rev 50376
tests: check `pulled-delta-reuse-policy=forced` without general delta If general delta is not available, the amount of delta we can reuse at all will be more limited. We check that application still work and does not corrupt the repository.
Tue, 25 Apr 2023 15:28:40 +0200 bundles: clarify streaming v2 bundle usage stable
Mathias De Mare <mathias.de_mare@nokia.com> [Tue, 25 Apr 2023 15:28:40 +0200] rev 50375
bundles: clarify streaming v2 bundle usage This seems useful to clarify through the documentation (we were still using debugcreatestreamclonebundle, even though 'hg bundle' is already an option...).
Mon, 05 Jun 2023 11:07:08 +0200 revlog: fix a bug in revlog splitting stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Mon, 05 Jun 2023 11:07:08 +0200] rev 50374
revlog: fix a bug in revlog splitting Specifically, if the .i.s files are not added to the transaction, then a follow-up modification of such a file records it into transaction as non-empty, which is incorrect.
Thu, 01 Jun 2023 22:32:21 +0100 test: make test-contrib-perf.t more robust stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Jun 2023 22:32:21 +0100] rev 50373
test: make test-contrib-perf.t more robust Some code path are far too fast now. We raise de number to make sure the run keep to that floor.
Wed, 31 May 2023 22:36:50 +0200 doc: format argument for date uses strftime format string (issue6818) stable
Joerg Sonnenberger <joerg@bec.de> [Wed, 31 May 2023 22:36:50 +0200] rev 50372
doc: format argument for date uses strftime format string (issue6818)
Thu, 20 Apr 2023 11:23:45 +0200 clonebundles: filter out invalid schemes instead of failing on them stable
Mathias De Mare <mathias.de_mare@nokia.com> [Thu, 20 Apr 2023 11:23:45 +0200] rev 50371
clonebundles: filter out invalid schemes instead of failing on them Previously, an invalid clonebundle scheme would result in a failed clone. By specifying a list of schemes we support, we can make sure adding a new scheme (like the one for inline clonebundles) does not result in clones failing for older clients.
Thu, 20 Apr 2023 10:48:12 +0200 clonebundles: demonstrate bad behaviour when unknown scheme is present stable
Mathias De Mare <mathias.de_mare@nokia.com> [Thu, 20 Apr 2023 10:48:12 +0200] rev 50370
clonebundles: demonstrate bad behaviour when unknown scheme is present
Thu, 04 May 2023 14:17:28 +0200 Added signature for changeset fc445f8abcf9 stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 04 May 2023 14:17:28 +0200] rev 50369
Added signature for changeset fc445f8abcf9
Thu, 04 May 2023 14:17:19 +0200 Added tag 6.4.3 for changeset fc445f8abcf9 stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 04 May 2023 14:17:19 +0200] rev 50368
Added tag 6.4.3 for changeset fc445f8abcf9
Thu, 04 May 2023 14:16:07 +0200 relnotes: add 6.4.3 stable 6.4.3
Raphaël Gomès <rgomes@octobus.net> [Thu, 04 May 2023 14:16:07 +0200] rev 50367
relnotes: add 6.4.3
Wed, 03 May 2023 00:16:38 +0200 backup: fix issue when the backup end up in a different directory stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2023 00:16:38 +0200] rev 50366
backup: fix issue when the backup end up in a different directory Because of store encoding, we might end up with the backup in a different directory than the initial copy (for example if the backup path make it cross the 120 char limit). This can create crash, especially since 6.4 where backup are used during revlog split. Making sure the directory exists fixes these crash We added a test covering this case. Strictly speaking, this has always been broken, however the new code in 6.4 triggers it more easily.
Wed, 03 May 2023 00:12:34 +0200 vfsproxy: inherit the `createmode` attribute too stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 May 2023 00:12:34 +0200] rev 50365
vfsproxy: inherit the `createmode` attribute too It is an important part of the API when creating directory. We will need it in the next changeset.
Tue, 02 May 2023 21:43:45 +0200 revlog: test more complex file pattern for revlog split stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 May 2023 21:43:45 +0200] rev 50364
revlog: test more complex file pattern for revlog split There have been a report of failure while splitting revlog. The file name involved was important. The pattern involved here are not problematic, but it help to setup the machinery to test multiple files, the actual fix and problematic file will arrive in a later changeset.
Tue, 02 May 2023 15:40:13 +0200 repo-upgrade: write new requirement before upgrading the dirstate stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 02 May 2023 15:40:13 +0200] rev 50363
repo-upgrade: write new requirement before upgrading the dirstate This will prevent a small race condition where another hg process still believes the repo is dirstate-v1 during the upgrade process. This is good to have, but it is not a proper fix for the underlying problem. There is code that assumes a requirement means a usage, e.g. having the `generaldelta` requirement would imply *all* revlogs to use general delta, but it's not true, it simply means that the repository advertises to the client it needs to understand `generaldelta` in order to read the repo. In the case of the dirstate, having the requirement *technically* should always be the same as using dirstate-v2, since there is only one dirstate and requirements should be as minimal as possible. However, we should not assume this and make the code more robust in a future patch (series).
Wed, 26 Apr 2023 15:30:35 -0400 rhg: correctly relativize copy source path stable
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Wed, 26 Apr 2023 15:30:35 -0400] rev 50362
rhg: correctly relativize copy source path
Wed, 26 Apr 2023 15:31:02 -0400 rhg: don't print copy source when --no-status is passed stable
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Wed, 26 Apr 2023 15:31:02 -0400] rev 50361
rhg: don't print copy source when --no-status is passed
Wed, 26 Apr 2023 16:18:12 -0400 tests: add test for status copy source formatting stable
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Wed, 26 Apr 2023 16:18:12 -0400] rev 50360
tests: add test for status copy source formatting
Tue, 25 Apr 2023 17:49:35 -0400 fix: highlight the required configuration and behavior of the fixer tools stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 25 Apr 2023 17:49:35 -0400] rev 50359
fix: highlight the required configuration and behavior of the fixer tools The problem is that `hg help fix` didn't mention *how* to configure the tools, and while I knew that `{rootpath}` existed in the configuration, I missed that the tools require reading content from stdin. (I configured `gofmt` to use `{rootpath}`, and that had the effect of squashing all changes in a file at `.` into the first commit and emptying that content from its descendants.) Basically all this does is put a pointer in the default (command level) help to the extension level help that mentions the configuration, and moves the extension level help that documents reading from stdin and writing to stdout to the top to give it more prominence. The last sentence is adjusted a bit to reflect the new location.
Tue, 18 Apr 2023 15:26:55 +0200 debug-delta: add minimal documentation for `devel.bundle-delta` option stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 18 Apr 2023 15:26:55 +0200] rev 50358
debug-delta: add minimal documentation for `devel.bundle-delta` option So the next person won't have to grep the code to know what it is doing.
Wed, 19 Apr 2023 16:37:11 +0200 delta-find: simply code that is now never invoqued without general delta stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Apr 2023 16:37:11 +0200] rev 50357
delta-find: simply code that is now never invoqued without general delta Finish early in on-general delta case mean a lot of code can assume that general delta is not enabled.
Tue, 18 Apr 2023 17:17:31 +0200 delta-find: add a simple safeguard to prevent bad non-general-delta stable
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.
Wed, 19 Apr 2023 18:16:19 +0200 delta-find: never do anything fancy when general delta is off stable
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.
Wed, 19 Apr 2023 16:59:03 +0200 delta-find: assume the target-rev if not specified stable
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)
Thu, 20 Apr 2023 09:23:58 -0400 chg: set CHGHG before connecting to command server stable
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.
Mon, 24 Apr 2023 10:30:08 -0400 chg: declare environ (issue6812) stable
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Mon, 24 Apr 2023 10:30:08 -0400] rev 50352
chg: declare environ (issue6812)
Tue, 18 Apr 2023 11:48:22 +0200 relnotes: add 6.4.2 stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Apr 2023 11:48:22 +0200] rev 50351
relnotes: add 6.4.2
Tue, 18 Apr 2023 11:41:03 +0200 Added signature for changeset f952be90b051 stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 18 Apr 2023 11:41:03 +0200] rev 50350
Added signature for changeset f952be90b051
Tue, 18 Apr 2023 11:40:57 +0200 Added tag 6.4.2 for changeset f952be90b051 stable
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
Tue, 18 Apr 2023 01:23:27 +0200 revlog-split: make sure the self._indexfile attribut is reset (issue6811) stable 6.4.2
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.
Tue, 18 Apr 2023 00:07:52 +0200 revlog-split: also check a case where bundle contains multiple changegroup stable
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.
Tue, 18 Apr 2023 01:12:00 +0200 revlog-split: show manifest data loss situation when using clonebundle stable
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.
Thu, 13 Apr 2023 14:21:01 +0200 Added signature for changeset 83ea6ce48b4f stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:21:01 +0200] rev 50345
Added signature for changeset 83ea6ce48b4f
Thu, 13 Apr 2023 14:21:00 +0200 Added tag 6.4.1 for changeset 83ea6ce48b4f stable
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
Thu, 13 Apr 2023 14:20:26 +0200 relnotes: add 6.4.1 stable 6.4.1
Raphaël Gomès <rgomes@octobus.net> [Thu, 13 Apr 2023 14:20:26 +0200] rev 50343
relnotes: add 6.4.1
Wed, 12 Apr 2023 17:28:39 +0200 sslutil: set context security level for legacy tls testing (issue6760) stable
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
Thu, 13 Apr 2023 11:28:48 +0200 configitems: make devel.serverexactprotocol look dangerous stable
pacien <pacien.trangirard@pacien.net> [Thu, 13 Apr 2023 11:28:48 +0200] rev 50341
configitems: make devel.serverexactprotocol look dangerous Because it is.
Thu, 13 Apr 2023 04:12:31 +0200 rebase: do not cleanup the working copy when --dry-run is used (issue6802) stable
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.
Tue, 11 Apr 2023 17:06:08 +0200 rebase: add a test showing that --dry-run wipes working copy changes stable
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.
Sat, 01 Apr 2023 05:58:59 +0200 match: match explicit file using a set stable
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%)
Sat, 01 Apr 2023 05:57:09 +0200 match: sort patterns before compiling them into a regex stable
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
Mon, 27 Mar 2023 17:30:14 -0400 chg: populate CHGHG if not set stable
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.
Fri, 07 Apr 2023 12:11:44 +0200 run-tests: remove obsolete coverage check and packaging import (issue6805) stable
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.
Wed, 05 Apr 2023 11:58:25 +0200 test-tx-rollback: more lenient glob for kill status (issue6807) stable
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.
Mon, 27 Mar 2023 06:24:44 +0200 commands: correct documentation of hg serve’s --ipv6 option stable
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.
Fri, 24 Mar 2023 19:19:37 +0000 rhg: don't crash on empty directory names in path_encode, just in case stable
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.
Fri, 24 Mar 2023 19:02:46 +0000 rhg: fix a bug in path encoding, demonstrated in the parent commit stable
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
Fri, 24 Mar 2023 19:01:03 +0000 rhg: show a bug in the rust implementation of path_encode introduced recently stable
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.
Fri, 24 Mar 2023 02:22:12 -0400 typing: correct the signature of error.CommandError stable
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.
Fri, 24 Mar 2023 00:11:38 +0100 Added signature for changeset f14864fffdca stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Mar 2023 00:11:38 +0100] rev 50328
Added signature for changeset f14864fffdca
Fri, 24 Mar 2023 00:11:31 +0100 Added tag 6.4 for changeset f14864fffdca stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 24 Mar 2023 00:11:31 +0100] rev 50327
Added tag 6.4 for changeset f14864fffdca
Thu, 23 Mar 2023 22:01:34 +0100 relnotes: do 6.4 stable 6.4
Raphaël Gomès <rgomes@octobus.net> [Thu, 23 Mar 2023 22:01:34 +0100] rev 50326
relnotes: do 6.4
Thu, 23 Mar 2023 11:36:25 +0000 hooks: invalidate the repo after the hooks stable
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.
Thu, 23 Mar 2023 21:18:54 +0000 dirstate: try refreshing the changelog when parent are unknown stable
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.
Thu, 23 Mar 2023 21:18:14 +0000 localrepo: add a `currentlock` method stable
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.
Thu, 23 Mar 2023 11:24:47 +0000 dirstate: add a test to highlight another changelog / dirstate race stable
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
Thu, 23 Mar 2023 19:10:15 +0100 rust: fix thread cap (for real this time) stable
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.
Wed, 22 Mar 2023 17:18:32 +0000 tests: accept a test output change in [tests/test-serve.t] stable
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.
Tue, 21 Mar 2023 17:07:22 +0100 py3: fix for Python 3.12 emitting SyntaxWarning on invalid escape sequences stable
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)$')
Tue, 21 Mar 2023 15:27:03 +0100 url: don't ignore timeout for https connections stable
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.
Tue, 21 Mar 2023 15:44:38 +0000 debugdeltachain: stop summing the same chain over and over stable
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 tip