branching: merge stable into default

Added signature for changeset 6454c117c6a4

Added tag 6.8rc0 for changeset 6454c117c6a4

branching: merge default into stable for 6.8rc0

relnotes: add 6.8rc0

branch3: use an explicitely experimental name for files Since this format is still experimental, we don't want to have to side-step the `branch3` name in case people do start using it before it's stable.

obsolete: simplify relevantmarker Drop duplicate assignment from a merge failure. Save one loop iteration by exploiting that pendingnodes will be seennodes after the first round anyway, so just pre-initialize the set accordingly. From Anton Shestakov's review on !867. Performance difference for my test case is in the noise.

exchange: improve computation of relevant markers for large repos Find the candidates for nodes with relevant markers by going over all markers instead of iterating over all nodes. Most nodes will not have markers anyway. Further optimize the code by allowing revsets as well, which reduces the materialization cost.

test: better glob some timing related line to avoid flakiness If we go over 10 seconds, the number of white space changes.

branching: merge stable into default

Added signature for changeset a1a011d4b148

Added tag 6.7.4 for changeset a1a011d4b148

relnotes: add 6.7.4 and warn about 6.7.{1,2,3}

inline-changelog: fix pending transaction visibility when splitting We move the name back to the expected name of `changelog.i.a`.

inline-changelog: fix a critical bug in write_pending that delete data Since a93e52f0b6ff we no longer use inline-revlog for the changelog. The goal there was to solve the lack of testing for the two variants (inline vs split) and reduce the complexity of the interaction with "diverted-write" on the changelog level. However many existing repository still have inline-changelog and we automatically move them to normal revlog as soon as we have the chances. Unfortunately This conversion is buggy and can result in the destruction of the changelog.i if hook triggers the "write pending" mechanism. The bugs comes from the "revlog splitting" logic and the "write_pending" logic stepping over each other. Ironically the change in a93e52f0b6ff aims at no longer having this kind of problem. This changesets fix this issue and add associated tests. Fixing this reveal that the transaction hooks end up not seeing the pending transaction content, because the name is not right ("changelog.i.s.a" instead of "changelog.i.s") we fix this in the next changeset.

bookmark: fix remote bookmark deletion when the push is raced Before this patch, running `hg push -B book` to push the `book` bookmark sideway at the same time as a commit making it moving forward might result in the removal of the bookmark remotely. After this changeset, the push can still be raced, but to remove deletion happens. This is progress.

hooks: add a prewlock and a prelock hooks This is useful for testing.

exchange: fix locking to actually be scoped The previous code was taking locks before entering with statements, so exception before the with statement would not release the lock (except for garbage collection). We need to move to a try except here because the logic is more complicated.

exchange: fix locking to actually be scoped The previous code was taking locks before entering with statements, so exception before the with statement would not release the lock (except for garbage collection).

narrow: add a test for linkrev computation done during widen This new tests show that the linkrev computed and sent by the server might end up being wrong during a widen operation.

obsolete: quote the feature name This makes it at least somewhat clearer that hg is talking about some specific feature and not just outdated code.

branching: merge stable into default

rust-status: sort the failed matches when printing them This was making the tests flaky after the recent patch¹ that opened up more of the code to the Rust-augmented status. [1] 865efc020c3355dca1cbaa35db80600009c01dd5

clonebundles: add missing newline to legacy response This seems to have been removed in 6.5 (likely by 60f9602b413e).

chistedit: change action for the correct item We have an experimental config histedit.later-commits-first from c820866c52f9, and when it's true, the order of commits in histedit UI is reversed, both in text mode and in curses mode. But before this patch key presses in curses mode would change histedit actions in the same old order, i.e. trying to edit the latest commit (which would be first now) would put "edit" action on the last commit in the list. This wasn't a cosmetic issue, histedit would actually proceed to edit the first commit in the list. Let's map rules to display items (hopefully now correctly).

dirstate: remove the python-side whitelist of allowed matchers This whitelist is too permissive because it allows matchers that contain disallowed ones deep inside, for example through `intersectionmatcher`. It is also too restrictive because it doesn't pass through some of the matchers we support, such as `patternmatcher`. It's also unnecessary because unsupported matchers raise `FallbackError` and we fall back anyway. Making this change makes more of the tests use rust code path, and therefore subtly change behavior. For example, rust status in largefiles repos seems to have strange behavior.

match: make `was_tampered_with` work recursively This is useful if we are to use it outside of Rust, when deciding whether or not to do some fast-path operation with a given matcher.

largefiles: mark more matchers as having been tampered with These happened to slip through the cracks earlier because they weren't caught by tests. Now that we're enabling rust fast path more widely these start breaking.

branching: merge stable into default

Added signature for changeset 028dc3f92dbd

Added tag 6.7.3 for changeset 028dc3f92dbd

relnotes: add 6.7.3

rust: blanket implementation of Graph for Graph references The need comes from the fact that `AncestorsIterator` and many Graph-related algorithms take ownership of the `Graph` they work with. This, in turn is due to them needing to accept the `Index` instances that are provided by the Python layers (that neither rhg nor `RHGitaly` use, of course): the fact that nowadays the Python layer holds an object that is itself implemented in Rust does not change the core problem that they cannot be tracked by the borrow checker. Even though it looks like cloning `Changelog` would be cheap, it seems hard to guarantee that on the long run. The object is already too rich for us to be comfortable with it, when using references is the most natural and guaranteed way of proceeding. The added test seems a bit superfleous, but it will act as a reminder that this feature is really useful until something in the Mercurial code base actually uses it.

rust-cpython: don't swallow the dirstate error message In case we do get a dirstate error, we want to get the full error message and not just an opaque `Dirstate error`.

dirstate-v2: check that root nodes are at the root before writing More explanations in the previous changeset.

dirstate-v2: add check of parent/child nodes being related when writing This stems from a corruption seen in a private repository. We're not sure of the source of the corruption, and it's very possible that we're seeing compounded effects of multiple writes on a corrupted dirstate. Adding this check is not expensive in itself and large writes of the dirstate are not common. This change does not catch this problem at the root node, the next one will.

admin-verify: expect a number of errors to be returned It's the responsibility of the check to handle errors, we only care about the total count to sum up the check's work. We use `admin::verify -c dirstate` to test this path at least somewhat.

admin-verify: fix error message handling `dirstate.verify` used to return tuples but does not anymore, it returns the pre-formatted error message, which is a nicer interface anyway.

admin-verify: pass p1 down to the dirstate function This was forgotten and can break with certain kinds of corruption.

Backed out changeset 3e0f86f09f26

Backed out changeset fc317bd5b637

re2: make errors quiet By default, the re2 library will output error on its own instead of keeping the error in an exception. This make re2 printing spurious error before fallback to the stdlib remodule that may accept the pattern or also fails to parse it and raise a proper error that will be handled by Mercurial. So we also pass an Option object that changes this default.

fold-or-prune-me: update proposal This does the same things but with a narrower wrapping.

subrepo: propagate non-default path on outgoing There was already a fix made in 5dbff89cf107 for pull and push commands. I did the same for the outgoing command. The problem I identified is that when the parent repository has multiple paths, the outgoing command was not respecting the parent path used and was always using the default path for subrepositories.

hgrc: search XDG_CONFIG_HOME on mac Searching for hgrc was special cased not to look through ~/.config/hg on Mac, but that’s unnecessary: Macs support it as do other unix based systems. There are plenty tools that use it there, e.g. git, and people expect it to work, e.g. "https://stackoverflow.com/questions/72499837/mercurial-on-macos-doesnt-read-config-hg-hgrc". Initial code introduced in 354020079723.

base-revsets: use an author that actually exercises a lot of changesets This was caught in my big find-and-replace: d4ba4d51f85f. The point of `base-revsets` is to give revsets that will give a good coverage of the repository. Using Pierre-Yves as the second largest committer (in terms of number of changesets) seems like a good idea.

match: simplify the rust-side file pattern kind parsing There's no need to add the ':' characters if we're simply pattern matching against constants next.

match: share code between includematcher and patternmatcher No need to have this duplication.

matchers: support patternmatcher in rust

match: avoid rust fast path if the matcher was tampered with Otherwise the fast path does not respect the modifications made by the extension (concretely largefiles, but other extensions can start using that too)

largefiles: track if a matcher was tampered with This is used to make sure rust fast path is not taken for the modified matchers.

branching: merge stable into default

tags-cache: directly perform a monimal walk for hgtagsfnodescache warming We do something narrower than the path retrieving data. So lets use dedicated code instead. This provides further useful speedup: ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.debug.debug-update-cache # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.pre-state = warm before-this-series: 19.947581 skip-fnode-filter: 18.916804 (-5.17%, -1.03) use-rev-num: 17.493725 (-12.30%, -2.45) this-changesets: 15.919466 (-20.19%, -4.03)

tags-cache: directly operate on rev-num warming hgtagsfnodescache Not having to goes through nodeid speed up things notably. ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.debug.debug-update-cache # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.pre-state = warm before-this-series: 19.947581 before-this-changes: 18.916804 (-5.17%, -1.03) this-changesets: 17.493725 (-12.30%, -2.45)

tags-cache: skip the filternode step if we are not going to use it When warming the hgtagsfnodescache, we don't need the actual result, so we can simply skip the part that "filter" fnode we read from the cache. So provide a quite visible speed up to the top level `hg debugupdatecache` function. ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.debug.debug-update-cache # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.pre-state = warm before: 19.947581 after: 18.916804 (-5.17%, -1.03)

tags-cache: add a dedicated warm cache function to hgtagsfnodescache Having a dedicated API point will help to optimize that specific usage. Right doing a full phases weam takes a long time, even when the cache is already filled.

outgoing: add a simple fastpath when there is no common This further speed up case like `hg bundle --all` for larger repository. ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.command.bundle # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.revs = all # benchmark.variants.type = none-streamv2 before: 316.749699 after: 311.165461 (-1.76%, -5.58) There is further work to be done in this area like not doing any outgoing computation in the stream case for example. however the recent changes already gives use a large win for a small amount of local work. ### benchmark.name = hg.command.bundle # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.revs = all # benchmark.variants.type = none-streamv2 ## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog pre-%ln-change: 1.263859 the-%ln-change: 0.700229 (-44.60%, -0.56) prev-changeset: 0.496050 (-60.75%, -0.77) this-changeset: 0.495243 (-60.81%, -0.77) ## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog pre-%ln-change: 2.975765 the-%ln-change: 1.870798 (-37.13%, -1.10) prev-changeset: 1.461583 (-50.88%, -1.51) this-changeset: 1.469185 (-50.63%, -1.51) ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog pre-%ln-change: 4.540080 the-%ln-change: 3.401700 (-25.07%, -1.14) prev-changeset: 2.915810 (-35.78%, -1.62) this-changeset: 2.911643 (-35.87%, -1.63) ## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog pre-%ln-change: 10.138396 the-%ln-change: 7.750458 (-23.55%, -2.39) prev-changeset: 6.665565 (-34.25%, -3.47) this-changeset: 6.672078 (-34.19%, -3.47) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog pre-%ln-change: 399.484481 the-%ln-change: 346.508952 (-13.26%, -52.98) prev-changeset: 316.749699 (-20.71%, -82.73) this-changeset: 311.165461 (-22.11%, -88.32)

outgoing: rework the handling of the `missingroots` case to be faster The previous implementation was slow, to the point it was taking a significant amount of `hg bundle --type none-streamv2` call. We rework the code to compute the same value much faster, making the operation disappear from the `hg bundle --type none-streamv2` profile. Someone would remark that producing a streamclone does not requires an `outgoing` object. However that is a matter for another day. There is other user of `missingroots` (non stream `hg bundle` call for example), and they will also benefit from this rework. We implement an old TODO in the process, directly computing the missing and common attribute as we have most element at hand already. ### benchmark.name = hg.command.bundle # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.revs = all # benchmark.variants.type = none-streamv2 ## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog before: 7.750458 after: 6.665565 (-14.00%, -1.08) ## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog before: 0.700229 after: 0.496050 (-29.16%, -0.20) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog before: 346.508952 after: 316.749699 (-8.59%, -29.76) ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog before: 3.401700 after: 2.915810 (-14.28%, -0.49) ## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog before: 1.870798 after: 1.461583 (-21.87%, -0.41) note: this whole `missingroots` of outgoing has a limited number of callers and could likely be replace by something simpler (like taking an explicit "missing_revs" set for example). However this is a wider change and we focus on a small impact, quick rework that does not change the API for now.

proxy-vfs: also proxy the `audit` attribute In the previous changeset, we had to do a little dance to access the useful `audit` attribute. We now provide a proper accessors to it. We don't update the code in `perf.py` because it has to remain compatible with older version of Mercurial. This will just be nicer in the future.

perf: clear vfs audit_cache before each run When generating a stream clone, we spend a large amount of time auditing path. Before this changes, the first run was warming the vfs cache for the other runs, leading to a large runtime difference and a "faulty" reported timing for the operation. We now clear this important cache between run to get a more realistic timing. Below are some example of median time change when clearing these cases. The maximum time for a run did not changed significantly. ### data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog # benchmark.name = hg.perf.exchange.stream.generate # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.version = latest no-clearing: 17.289905 cache-clearing: 21.587965 (+24.86%, +4.30) ## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog no-clearing: 32.670748 cache-clearing: 40.467095 (+23.86%, +7.80) ## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog no-clearing: 37.838858 cache-clearing: 46.072749 (+21.76%, +8.23) ## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog no-clearing: 32.969395 cache-clearing: 39.646209 (+20.25%, +6.68) In addition, this significantly reduce the timing difference between the performance command, from the perf extensions and a `real `hg bundle` call producing a stream bundle. Some significant differences remain especially on the "mozilla-try" repositories, but they are now smaller. Note that some of that difference will actually not be attributable to the stream generation (like maybe phases or branch map computation). Below are some benchmarks done on a currently draft changeset fixing some unrelated slowness in `hg bundle` (34a78972af409d1ff37c29e60f6ca811ad1a457d) ### data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default hg.perf.exchange.stream.generate: 21.587965 hg.command.bundle: 24.301799 (+12.57%, +2.71) ## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog hg.perf.exchange.stream.generate: 40.467095 hg.command.bundle: 44.831317 (+10.78%, +4.36) ## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog hg.perf.exchange.stream.generate: 39.646209 hg.command.bundle: 45.395258 (+14.50%, +5.75) ## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog hg.perf.exchange.stream.generate: 46.072749 hg.command.bundle: 55.882608 (+21.29%, +9.81) ## data-env-vars.name = mozilla-try-2023-03-22-zlib-general-delta hg.perf.exchange.stream.generate: 334.716708 hg.command.bundle: 377.856767 (+12.89%, +43.14) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog hg.perf.exchange.stream.generate: 302.972301 hg.command.bundle: 326.098755 (+7.63%, +23.13)

perf: start recording total time after warming The warming might be costly and this should not affect the "time profile" of the actual collection.

perf: run the gc before each run The python garbage collector is a large source of performance troubles, we run it right before the timed section to reduce the change for the gc to add noise to the benchmark.

perf: allow profiling of more than one run By default, we still profile the first run only. However profiling more run help to understand side effect from one run to the other. So we add an option to be able to do so.

profiler: flush after writing the profiler output Otherwise, the profiler output might only partially appears until the next flush of the buffer. Since profiling often happens for long operation, the next flush can be a long time away.

stream-clone: disable gc for the entry listing section for the v2 format This is similar to the change we did for the v3 format in 6e4c8366c5ce. The benchmark bellow show this gives us a notable gains, especially on larger repositories. ### benchmark.name = hg.perf.stream-locked-section # benchmark.name = hg.perf.stream-locked-section # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.version = v2 ## data-env-vars.name = pypy-2018-08-01-zstd-sparse-revlog 5e931bf8707c: 0.503820 ~~~~~ 1106d1bf695e: 0.470078 (-6.70%, -0.03) ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog 5e931bf8707c: 0.535756 ~~~~~ 1106d1bf695e: 0.490249 (-8.49%, -0.05) ## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog 5e931bf8707c: 1.327041 ~~~~~ 1106d1bf695e: 1.174636 (-11.48%, -0.15) ## data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog 5e931bf8707c: 2.439158 ~~~~~ 1106d1bf695e: 2.220515 (-8.96%, -0.22) ## data-env-vars.name = netbeans-2019-11-07-zstd-sparse-revlog 5e931bf8707c: 2.630794 ~~~~~ 1106d1bf695e: 2.261473 (-14.04%, -0.37) ## data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog 5e931bf8707c: 5.769002 ~~~~~ 1106d1bf695e: 5.062000 (-12.26%, -0.71) ## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog 5e931bf8707c: 13.351750 ~~~~~ 1106d1bf695e: 12.346655 (-7.53%, -1.01) ## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog 5e931bf8707c: 10.772939 ~~~~~ 1106d1bf695e: 9.495407 (-11.86%, -1.28) ## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog 5e931bf8707c: 10.864297 ~~~~~ 1106d1bf695e: 9.475597 (-12.78%, -1.39) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog 5e931bf8707c: 17.448335 ~~~~~ 1106d1bf695e: 16.027474 (-8.14%, -1.42)

phases: rework the logic of _pushdiscoveryphase to bound complexity This rework the various graph traversal in _pushdiscoveryphase to keep the complexity in check. This is done though a couple of things: - first, limiting the space we have to explore, for example, if we are not in publishing push, we don't need to consider remote draft roots that are also draft locally, as there is nothing to be moved there. - avoid unbounded descendant computation, and use the faster "rev between" computation. This provide a massive boost to performance when exchanging with repository with a massive amount of draft, like mozilla-try: ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.command.push # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.explicit-rev = all-out-heads # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = default ## benchmark.variants.revs = any-1-extra-rev before: 20.346590 seconds after: 11.232059 seconds (-38.15%, -7.48 seconds) ## benchmark.variants.revs = any-100-extra-rev before: 24.752051 seconds after: 15.367412 seconds (-37.91%, -9.38 seconds) After this changes, the push operation is still quite too slow. Some of this can be attributed to general phases slowness (reading all the roots from disk for example) and other know slowness (not using persistent-nodemap, branchmap, tags, etc. We are also working on them, but with this series, phase discovery during push no longer showing up in profile and this is a pretty nice and bit low-hanging fruit out of the way. ### (same case as the above) # benchmark.variants.revs = any-1-extra-rev pre-%ln-change: 44.235070 this-changeset: 11.232059 seconds (-74.61%, -33.00 seconds) # benchmark.variants.revs = any-100-extra-rev pre-%ln-change: 49.234697 this-changeset: 15.367412 seconds (-68.79%, -33.87 seconds) Note that with this change, the `hg push` performance is now much closer to the `hg pull` performance, even it still lagging behind a bit. (and the overall performance are still too slow). ### data-env-vars.name = mozilla-try-2023-03-22-ds2-pnm # benchmark.variants.explicit-rev = all-out-heads # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.pulled-delta-reuse-policy = default # bin-env-vars.hg.flavor = rust ## benchmark.variants.revs = any-1-extra-rev hg.command.pull: 6.517450 hg.command.push: 11.219888 ## benchmark.variants.revs = any-100-extra-rev hg.command.pull: 10.160991 hg.command.push: 14.251107 ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # bin-env-vars.hg.py-re2-module = default # benchmark.variants.explicit-rev = all-out-heads # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.pulled-delta-reuse-policy = default ## bin-env-vars.hg.flavor = default ## benchmark.variants.revs = any-1-extra-rev hg.command.pull: 8.577772 hg.command.push: 11.232059 ## bin-env-vars.hg.flavor = default ## benchmark.variants.revs = any-100-extra-rev hg.command.pull: 13.152976 hg.command.push: 15.367412 ## bin-env-vars.hg.flavor = rust ## benchmark.variants.revs = any-1-extra-rev hg.command.pull: 8.731982 hg.command.push: 11.178751 ## bin-env-vars.hg.flavor = rust ## benchmark.variants.revs = any-100-extra-rev hg.command.pull: 13.184236 hg.command.push: 15.620843

phases: introduce a performant efficient way to access revision in a set This will be useful in the next changesets.

phases: use revision number in `_pushdiscoveryphase` We now reach our target checkpoint in terms of rev-num conversion. The `_pushdiscoveryphase` function is now performing graph computation based on revision number only. Avoiding repeated conversion from node-id to rev-num. See previous changeset updated `new_heads` for rationnal. Again, time saved in the 100 milliseconds order of magnitude for the mozilla-try benchmark I have been using. However, wow that the logic is done using revision number, we can look into having better logic in the next changesets, which will provide a much bigger speedup.

phases: move RemotePhasesSummary to revision number This continue our quest to align more logic on revision number instead of node-ids. The motivation is similar to the change to `new_heads` and `analyze_remote_phases` a few changeset earlier. Again, we take this as an opportunity to rename the class, and the attribute to the new naming scheme. This will highlight the need for code update for any code using it an expecting node-ids. Many of the rev-num → node-id conversion we had to introduce in the previous changesets can now be removed. More will be removed in the future as we continue to align code toward rev-num usage. time saved in the 100 milliseconds order of magnitude for the mozilla-try benchmark I have been using.

phases: stop using `repo.set` in `remotephasessummary` The `repository.set` create changectx on the fly, an expensive operation. Using `repo.revs` and a direct rev-num → node-id translation will be significantly faster. This is especially true as we prepare ourself to no longer do the rev-num → node-id transalation there. The speedup is a bit lost in the overall noisyness of the slow phase discovery algorithm, but it save a small amount of time in my benchmark.

phases: use revision number in analyze_remote_phases Same logic as the previous change to `new_heads`, see rationnal there. This avoids a small number of `nodes -> revs` conversion speeding thing up in the 100 milliseconds order of magnitude for the worses cases. However, the rest of the logic is noisy enough that it hardly matters for now.

phases: use revision number in new_heads All graph operations will be done using revision numbers, so passing nodes only means they will eventually get converted to revision numbers internally. As part of an effort to align the code on using revision number we make the `phases.newheads` function operated on revision number, taking them as input and using them in returns, instead of the node-id it used to consume and produce. This is part of multiple changesets effort to translate more part of the logic, but is done step by step to facilitate the identification of issue that might arise in mercurial core and extensions. To make the change simpler to handle for third party extensions, we also rename the function, using a more modern form. This will help detecting the different between the node-id version and the rev-num version. I also take this as an opportunity to add some comment about possible performance improvement for the future. They don't matter too much now, but they are worse exploring in a while.

phases: convert remote phase root to node while reading them This is currently a bit silly as we will convert them back to node right after, but that is an intermediate step before doing more disruptive changes.

phases: more compact error handling in analyzeremotephases using an intermediate variable result in more readable code, so let us use it.

push: rework the computation of fallbackheads to be correct The previous computation tried to be smart but ended up being wrong. This was caught by phase movement test while reworking the phase discovery logic to be faster. The previous logic was failing to catch case where the pushed set was not based on a common heads (i.e. when the discovery seemed to have "over discovered" content, outside the pushed set) In the following graph, `e` is a common head and we `hg push -r f`. We need to detect `c` as a fallback heads and we previous failed to do so:: e | d f |/ c | b | a The performance impact of the change seems minimal. On the most impacted repository at hand (mozilla-try), the slowdown seems mostly mixed in the overall noise `hg push` but seems to be in the hundred of milliseconds order of magnitude. When using rust, we seems to be a bit faster, probably because we leverage more accelaratd internals. I added a couple of performance related common for further investigation later on.

revset: stop serializing node when using "%ln" Turning hundred of thousand of node from node to hex and back can be slow… what about we stop doing it? In many case were we are using node id we should be using revision id. However this is not a good reason to have a stupidly slow implementation of "%ln". This caught my attention again because the phase discovery during push make an extensive use of "%ln" or huge set. In absolute, that phase discovery probably should use "%ld" and need to improves its algorithmic complexity, but improving "%ln" seems simple and long overdue. This greatly speeds up `hg push` on repository with many drafts. Here are some relevant poulpe benchmarks: ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.command.push # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.explicit-rev = all-out-heads # benchmark.variants.issue6528 = disabled # benchmark.variants.protocol = ssh # benchmark.variants.reuse-external-delta-parent = default ## benchmark.variants.revs = any-1-extra-rev before: 44.235070 after: 20.416329 (-53.85%, -23.82) ## benchmark.variants.revs = any-100-extra-rev before: 49.234697 after: 26.519829 (-46.14%, -22.71) ### benchmark.name = hg.command.bundle # bin-env-vars.hg.flavor = default # bin-env-vars.hg.py-re2-module = default # benchmark.variants.revs = all # benchmark.variants.type = none-streamv2 ## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog before: 10.138396 after: 7.750458 (-23.55%, -2.39) ## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog before: 1.263859 after: 0.700229 (-44.60%, -0.56) ## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog before: 399.484481 after: 346.5089 (-13.26%, -52.98) ## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog before: 4.540080 after: 3.401700 (-25.07%, -1.14) ## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog before: 2.975765 after: 1.870798 (-37.13%, -1.10)

bundlespec: drop unused _bundlespecvariants dictionary Why do we have a `_bundlespecvariants`?

bundlespec: type the _bundlespeccontentopts dictionary If only we had a tool to detect the kind of stupid error we just fixed… ho wait.

bundlespec: fix the "streamv2" and "streamv3-exp" variant In c4aab3661f25, we broken this feature by adding unicode instead of bytes to the dictionary. On the other hand, this feature was never tested, so augment the tests to tests this.

wireprotoserver: ensure that output stream gets flushed on exception Previously flush was happening due to Python finalizer being run on `BufferedWriter`. With upgrade to Python 3.11 this started randomly failing. My guess is that the finalizer on the raw `FileIO` object may be running before the finalizer of `BufferedWriter` has a chance to run. At any rate, since we're not relying on finalizers in the happy case we should also not rely on them in case of exception.

match: strengthen visit_children_set invariant, Recursive means "all files" My previous interpretation of "Recursive" was too relaxed: I thought it instructed the caller to do something like this: > you can stop calling `visit_children_set` because you'll need to descend into > every directory recursively, but you should still check every file if it > matches or not Whereas the real instruction seems to be: > I guarantee that everything in this subtree matches, you can stop > querying the matcher for all files and dirs altogether. The evidence to support this: - the test actually passes with the stronger invariant, revealing no exceptions from this rule - the implementation of `visit_children_set` for `DifferenceMatcher` clearly relies on this requirement, so it must hold for that not to lead to bugs.

match: fix the rust-side bug in visit_children_set for rootfilesin matchers The fix is checked by `test_pattern_matcher_visit_children_set` test, which is what caught the bug in the first place, but also by an end-to-end test that I made for this purpose. Accept the new results of Cargo tests Many of these were already annotated with "FIXME", which is a good sign.

match: fix the "visitdir" method on "rootfilesin" matchers This fixes just the Python side, the fix for the rust side will follow shortly.

match: rename RootFiles to RootFilesIn for more consistency

match: small tweak to PatternMatcher.visit_children_set This makes it a bit more efficient (avoid a computation in case of early return), and in my opinion clearer.

matchers: fix the bug in rust PatternMatcher that made it cut off early This brings the rust output in line with the Python output.

tests: add an end-to-end test to show a bug in `visit_children_set` Concretely, `rootfilesin` is completely broken with respect to `visit_children_set` optimization.

tests: add tests and document expectations from visit_children_set in rust The tests this patch are adding have the form of formal spec in invariants::visit_children_set::holds, and then a series of checks that all examples must satisfy this formal spec. I tried to make the spec consistent with how this function is used and how it was originally conceived. This is in conflict with how it's documented in Rust. Some of the implementations also fail to implement this spec, which leads to bugs, in particular when complicated patterns are used with `hg status`.

tests: add a test that demonstrates a bug in rhg status pattern handling The bug is in [visit_children_set], will be elaborated on in follow-up changes.

bundle-spec: properly parse boolean configuration as boolean Before this changesets "v2;revbranchcache=no" would actually request the addition for a revbranchcache part as the non-empty string `"0"` is `True`

bundle-spec: properly identify changegroup-less bundle It is possible to produce a bundle without changegroup. For example if we want to only send phases or obsolescence information. However that lead to crash for command that identifies bundle content. So we fix that. The test will come in the next changesets, when we fix another bug preventing to generate such bundle by hand.

perf: create the temporary target next to the source in stream-consume See inline comment for rational.

setup: display return code information about failed `hg` call This help to understand what is going wrong when things goes wrong.

bundlespec: rationalize the way we specify stream bundle version Instead of having weird dedicated option for each version (v2, v3, etc) we reuse the same "stream" parameters. This is consistent with the ability to request a stream clone using "none-v2;stream=v2". This changeset introduce no user visible change, this is pure internal cleaning.

bundle: do no check the changegroup version if no changegroup is included We don't need to check the compatibility of something we will not use. In practice this was getting in the was of `streamv2` bundles on a narrow repository as the 'cg.version=02' value was rejected by this checks.

perf-stream-consume: use the source repository config when applying This might contains critical configuration for the benchmark, like enabling of extensions like narrow.

unbundle: move most of the logic on cmdutil to help debug::unbundle reuse This make sure `hg debug::unbundle` focus on the core logic.

postincoming: move to cmdutil This looks like a good place for it to live.

postincoming: avoid computing branchhead if no report will be posted This otherwise defeat some of the branch v3 optimization.

streamclone: stop listing files for entries that have no volatile files This will save a lot of python related time. This significantly boost performance. The following number comes from a large private repository using perf::stream-locked-section: base-line: 35.04 seconds prev-change: 24.51 seconds (-30%) prev-change: 20.88 seconds (-40%) prev-change: 14.22 seconds (-60%) this-change: 11.58 seconds (-67% from baseline; -18% from prev)

stream-clone: disable gc for the initial section for the v3 format The number of small container created turn Python in a gc-frenzy that seriously impact performance. This significantly boost performance. The following number comes from a large private repository using perf::stream-locked-section: base-line: 35.04 seconds prev-change: 24.51 seconds (-30%) prev-change: 20.88 seconds (-40%) this-change: 14.22 seconds (-60% from baseline; -31% from prev)

stream-clone: disable gc for `_entries_walk` duration The number of small container created turn Python in a gc-frenzy that seriously impact performance. This significantly boost performance. The following number comes from a large private repository using perf::stream-locked-section: base-line: 35.04 seconds prev-change: 24.51 seconds (-30%) this-change: 20.88 seconds (-40% from baseline; -15% from previous changes)

nocg: make the utility work are both a decorator and context manager In some case, the context manager version will be simpler.

stream-clone: stop getting the file size of all file in v3 The point of v3 is to do less work in the locked section. It was currently not the case. This significantly boost performance. The following number comes from a large private repository using perf::stream-locked-section: base-line: 35.03 seconds this-change: 24.50 seconds (-30%)

stream: in v3, skip the "size" fast path if the entries as some unknown size We are about to prefetch size during the lock less in the v3 case. So we need to avoid trying to use that prefetched size when it is not available. See next changeset for the motivation.

perf-stream-locked-section: advertise the right version key in the help As the v3 format is still experimental, its key is "v3-exp". The help text was not pointing that out. (we also fix `perf::stream-generate` in the process)

perf-stream-locked-section: fix the call to the v3 generator That generator simply return chunks so we should not assign the return to a tuple.

perf-stream-locked-section: actually use v1 generation when requested We were fetching a v1 generator but actually using the v2 function…

branching: merge stable into default

Added signature for changeset 803e61387e86

Added tag 6.7.2 for changeset 803e61387e86

relnotes: add 6.7.2

bundle2: make the "hgtagsfnodes" part advisory This bundle2 part is about helping the client to warms its cache. There is no reason for it to be mandatory. So we mark it advisory.

branching: merge stable into default

branchcache: allow to detect "pure topological case" for branchmap We don't rum this detection every time we run the branchcache, that would be costly. However we now do it when running `hg debugupdatecache`. This will help existing repository to benefit from the fastpath when possible.

branchcache: add a "pure topological head" fast path In a narrow but actually quick common case, all topological heads are all on the same branch and all open. In this case, computing the branch map is very simple. We can quickly detect situation where this situation will not change. So we update the V3 format to be able to express this situation and upgrade the update code to detect we remains in that mode. The branch cache is populated with the actual value when the branch map is accessed, but the update_disk method can do the update without needing to populate it.

branchcache: move the processing of the new data in a dedicated method In a future changeset, this will allow the V3 of the branch cache to use a fast path when possible.

branchcache: gather newly closed head in a dedicated set This is part of a series to more clearly split the update in two step. This will allow us to introduce a fast path during update in a future changeset.

branchcache: gather new obsolete revision in a set This is part of a series to more clearly split the update in two step. This will allow us to introduce a fast path during update in a future changeset.

branchcache: filter obsolete revisions sooner Since we won't do anything with the obsolete revisions, we can just ignore them sooner.

branchcache: skip entries that are topological heads in the on disk file In the majority of cases, topological heads are also branch heads. We have efficient way to get the topological heads and efficient way to retrieve their branch information. So there is little value in putting them in the branch cache file explicitly. On the contrary, writing them explicitly tend to create very large cache file that are inefficient to read and update. So the branch cache v3 format is no longer including them. This changeset focus on the format aspect and have no focus on the performance aspect. We will cover that later.

branchcache: simplify the branch rev cache test We don't need that many content dump and this gets in the way in change in access pattern (e.g. accessing revision in a different order change the order of branches in the "names" file). So we simplify this test in advance.

branchcache: store filtered hash and obsolete hash independently for V3 This will avoid the bug covered in tests/test-branches-obsolete.t when we stop storing all heads explicitly in V3.

branchcache: show the cache file content in test-branches-obsoletes.t This help to track the changes in format between v2 and v3.

branchcache: rework the `filteredhash` logic to be more generic We now have a more flexible `key_hashes` tuple. We duplicated various logic in the V2 and V3 version of the cache as the goal is to start changing the logic for V3 in the next few changesets.

filteredhash: rename the filteredhash function The new name is less ambiguous, as we are about to introduce an alternative function it seems like a good idea to have clearer name to distinct the two.

filteredhash: split the computation of revision sets The branch2's filteredhash combines the filtered revisions and the obsolete ones, this will creates issue for implicit reference to heads we want to introduce for the v3 of the branch cache format. So we isolate this logic for alternative use.

filteredhash: move the hashing in its own function This will help us to reuse this logic in variants of the hashes used for branch cache validation.

branchcache: cleanup the final key generation after update A lot of duplicated work seemed to be done, as we already update the tiprev and tipnode when needed right before. So we simplify that part to focus on the filtered hash. See inline comment for details.

branchcache: add more test for the logic around obsolescence and branch heads While working on branch-cache-v3, we noticed some ambiguity in the filtered+obsolete hash. However this was only caught by a rebase test by chance. It seems important to explicitly tests these cases.

branchcache-v3: use more explicit header line The key-value approach is clearer and gives more rooms to have the format evolve in a clear way. It also provides extension (like topic) simpler way to extend the validation scheme. This is just a small evolution, the V3 format is still a work in progress.

branchcache-v3: introduce a v3 format For now the format is the very same, however we will start changing it in future changesets.

branchcache: use an explicit class for the v2 version This prepare the introduction of an experimental v3 format version. In the process, we move the description of the format in that new class.

branchcache: add some blank line in a test This helps each section to stand out.

phases: update the phase set as we go during retract boundary Apparently iterating over the `changed_revs` dictionary is very expensive. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds prev-changeset: 30.0 seconds this-changeset: 4.6 seconds So, the performance regression is gone. Once again: thanks to marvelous Python!

phases: avoid a potentially costly dictionary interation in some case If we retract for the draft phase, there is not non-public item to be retracted and we can skip this part. This part is was apparently super costly thanks to Python. On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets bundle gives give use the following timing. e57d4b868a3e: 4.6 seconds ac1c75188440: 102.5 seconds this-changeset: 30.0 seconds So we recovered about ⅔ of the regression, the next changeset will give us the rest back.

branching: merge stable into default

Added signature for changeset 2e6fde2ed01e

Added tag 6.7.1 for changeset 2e6fde2ed01e

relnotes: add 6.7.1

subrepo: fix normalizing paths with scheme After revision 0afe96e374a7, subrepo paths were normalized using posixpath.normpath and that resulted in ssh paths being wrongly converted from ssh://host/path to ssh:/host/path This fix applies the same logic used in urlutil.url to split the path scheme from the rest and only use posixpath.normpath to the string after scheme://

sshpeer: fix path when handling invalid url exception In 73ed1d13c0bf the code was refactored but the error handling seems to have been missed (or maybe the object shoud have implemented __bytes__)

delta-search: fix crash caused by unbound variable This code path was apparently not tested. This fixes a crash when cloning the Tryton repo.

branching: merge stable into default

Added signature for changeset c9ceb4f60256

Added tag 6.7 for changeset c9ceb4f60256

phases: avoid N² behavior in `advanceboundary` We allowed duplicated entries in the deque, which each entry could potentially insert all its ancestors. So advancing boundary for the full repository would mean each revision would walk all its ancestors, resulting in O(N²) iteration. For repository of any decent size, N² is quickly insane. We introduce a simple set to avoid this and get back to reasonable performance.

relnotes: add 6.7

admin-commands: move the chainsaw extension to the admin commands module Activating an extension is always a little bit of a chore and the long name, options and "chainsaw" bits are deterrent enough. This also allows us to help the discoverability for people looking for repo "administration" tools, with the widest semantic of "administration".

obsutil: sort metadata before comparing in geteffectflag() This is probably less important now that we dropped Python 2. We do still support Python 3.6 though, and the dictionaries aren't ordered there either (that was a big change that came with 3.7). Still, maybe it's a good idea to sort metadata explicitly.

tests: disable revlog compression in test-generaldelta.t (issue6867) The revlog compression makes a lot of numbers unstable. Since checking revlog compression is not the goal of this test, we disable the compression to get stable numbers. This should avoid wasting more time on this kind of changes in the future.

test-general-delta: actually test optimize-delta-parent-choice=no Since the configuration was not explicit, the case stopped testing what it intended to test when the default value changed.

test-chg: stabilize the log checking The "worker process exited" line have been making the CI flaky for a long time. Lets sort this out.

tests: fix test-patchbomb-tls.t instability The flakiness on chg is caused by a client that exit faster than the server output log. So actively wait for the server to issue the expected output (with a small timeout)

test-lock: use synchronisation file instead of sleep This will prevent the test to be flaky on load.

branchcache: use update_disk to refresh 'served' and 'served.hidden' The `update_disk` method is dedicated to this kind of usecase. Now that the writting patterns are more consistent, we can use it to warm these two important cache. I am dropping the first comment about "refreshing all the others" because it is false. If a branchmap already exist for "served", none of the subset will be updated.

branchcache: explictly update disk state only if no transaction exist If a transaction exist the `write_dirty` call will eventually be done and the state will be synched on disk. It is better to no interfer with that.

branchcache: do not use `__getitem__` in updatecache The `update_disk` method uses `updatecache` and the point of `update_disk` is to be able to do alternative processing to the one we do in `__getitem__`. So we calling `__getitem__` in `updatecache` defeat this purpose. Instead we do the equivalent explicitly to preserve the spirit of `update_disk` (that we will actually put to use soon, I promise)

branchcache: explicitly track inheritence "state" We move from a binary "dirty" flag to a three value "state": "clean", "inherited", "dirty". The "inherited" means that the branch cache is not only "clean", but it is a duplicate of its parent filter. If a branch cache is "inherited", we can non only skip writing its value on disk, but it is a good idea to delete any stale value on disk, as those will just waste time (and possibly induce bug) in the future. We only do this in the update related to transaction or explicit cache update (e.g `hg debugupdatecache`). Deleting the file when we simply detected a stall cache during a read only operation seems more dangerous. We rename `copy` to `inherit_for` to clarify we associate a stronger semantic to the operation.

branchcache: stop writing more branchcache file on disk than needed Before this change, we were unconditionally writing a branchmap file for the filter level passed to `update_disk`. This is actually counter productive if no update were needed for this filter level. In many case, the branch cache for a filter level is identical to its parent "subset" and it is better to simply keep the subset update and reuse it every time instead of having to do identical work for similar subset. So we change the `update_disk` method to only write a file when that filter level differ from its parent. This removes many cases where identical files were written, requiring multiple boring update in the test suite. The only notable changes is the change to `test-strip-branch-cache.t`, this case was checking a scenario that no longer reproduce the bug as writing less branchmap file result in less stalled cache on disk. Strictly speaking, we could create a more convoluted scenario that create a similar issue. However the next changeset would also cover that scenario so we directly updated that test case to a "no longer buggy" state.

branchcache: do not copy the `_dirty` flag If the inherited branch cache is dirty, it will be written on disk, and the super-set did not need to modify it, the on disk value for the subset will be re-useable as is. So the super set does not needs to write the very same content itself.

branchcache: explicitly assert that copy is always about inheritance This would catch cases where copy is used for something else if any existed.

branchcache: stop using `copy(…)` in `replace(…)` The `copy` method is mostly used for a filter level to inherit the branchmap from a subset. So we stop using (abusing) it in "replace" to ensure `copy` is used only for inheritance purposes. Since `replace` is a method of the BranchMapCache, it seems fine to do lower level operation there.

branchcache: change the _delayed flag to an explicit `_dirty` flag This is more consistent with the logic we use for other object and it open the way to a clearer management of the cache state. Now, cache are created clean, cache update mark them dirty, writing them on disk mark them clean again.

branchcache: write branchmap in subset inheritance order This way, we can guarantee a valid subset has been written before touching the branchmap of another filter. This is especially useful as we are bout to start deleting outdated branchmap file.

branchcache: do not accept "empty update" This currently does not happens and it will be simpler that is remains that way. If all update do something, we will be able to simply declare, in a later changesets, that all update to result in a dirty branchcache.

branchcache: avoid created a `None` filter repoview when writing The repoview class is not intended to be used for unfiltered repository.

stream-clone-tests: stop filtering non existent warning This filtering was introduced in 74c004a515bc, however there is already no warning in that changeset. So I guess the warnings existed when we the patch was created but the problem was solved in another changeset that 74c004a515bc, rebased on.

stream-clone-test: simplify case testing obsolescence There is only two important things in this test: - the number of file we send, to show we picked the obsstore. - the resulting state, to show we did alter things in the process. The rest are of the number are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.

stream-clone-test: simplify the case testing phases There is only two important things in this test: - the number of file we send, to show we picked the phase roots. - the resulting phases, to show we did not modified them. The rest are of the number are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.

stream-clone-test: simplify bookmark clone The important things to test here is the number of file included (to catch that the bookmark file was sent). So we keep that part non glob'ed but glob the rest. The glob'ed numbers are very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.

stream-clone-test: add a verify call to the "clone while changing" case It seems useful to very that the clone did not result in a corrupted copy.

stream-clone-test: add title to various test cases These case are fine as is, but as we are adding title to all the other as we simplify them, lets add title for all cases.

stream-clone-test: simplify testing of secret cloning restriction Here, we just want to check if the streaming clone is allowed and used or not. We do not care about the details of the clone itself.

stream-clone-test: simplify the background file closing test Here we just care about the fact the background file closing logic actually ran. We don't need to check the details of the cloning. The details of the output is very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol. So we filter it out.

stream-clone-test: simplify the --uncompressed alias check To check that --uncompressed is an alias we just need to check it trigger a stream clone, we don't need to check anything else.

stream-clone-test: drop an automatic pattern replacement That pattern is nice, but it prevent us to glob the number of bytes when we don't care about them. We don't care about them more often that what we currently checks so dropping this pattern will help use to simplify various tests.

stream-clone-test: simplify the test for getbundle with stream=1 The core of this tests is about checking we receive a stream bundle with such request. We don't need to look at too much of the details of the stream itself. Since the content of the stream if shifting overtime, Such check is very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol. So we reduce the size of what we check to focus on "is this a stream clone" question.

stream-clone-test: factor some piece of basic clone test out Multiple parts of this case (listing cache, checking error) are common to all cases and don't need to be in the conditionnal block. This simplify the test update.

stream-clone-test: simplify the case where server disabled it We have an option to disable it, we don't need to test it with all protocol variants. In addition there is little value in looking at the bytes to bytes details of the reply. Such check is very fragile and consume a lot of time for little value when adjusting formats, caches, and protocol.

rust-matchers: raw regular expression builder Extracting this `re_builder()` from `re_matcher()` makes it reusable in more general cases than matching `HgPath` instances and would help reducing code duplication in RHGitaly.

rust-filepatterns: export glob_to_re function Making this function public should not risk freezing the internal API, and it can be useful for all downstream code that needs to perform glob matching against byte strings, such as RHGitaly where it will be useful to match on branches and tags.

repoview: prevent `None` to be passed as the filtername We let such instantiation slip in a previous commit, so we add an explicit check to prevent it to happen in the future.

branchcache: avoid created a `None` filter repoview when writing The repoview class is not intended to be used for unfiltered repository.

rust-index: don't use mutable borrow to computed filtered heads This does not need to mutate the index. This is the prime suspect for some RuntimeError raised during some pushes.

rust-index: don't use mutable borrow for head-diff computation It does not needs to mutate the index. This is one of the two suspects of RuntimeError being thrown during push.

branchcache: move head writing in a `_write_headers` method Same rational: this will help having format variants.

branchcache: move head writing in a `_write_heads` method Same rational: this will help having format variants.

branchcache: move the header loading in a `_load_header` class method This will help changing header parsing in format variants.

branchcache: simplify a long line Gratuitous change to help code readability.

branchcache: rename `load` to `_load_heads` We are about to have more similar function, we rename the existing one to a more meaningful name and mark it private in the process.

branchcache: move the filename to a class attribute This prepare the introduction of more variant of cache.

test-clonebundles: simplify matching to be less flavor depends We keep the files and bytes output for the first call, but then we mostly check that we are being served a stream-clone bundle, not the actual content and size of the bundle. That aspect being tested by the stream clone test themselves.

repoview: fix changelog.__contains__ method This have been around for ten years, so we can safely that this method have few callers. However I am about to add one.

branchcache: unconditionally write delayed branchmap

branchcache: drop the unused `_verifyclosed` This code appears dead since its introduction about 5 years ago in this three consecutive commits: - 6578654916ae → introduce the method with two calls - 7c9d4cf23adf → remove first call - be5eeaf5c24a → remove second call o changeset: be5eeaf5c24a | user: Pulkit Goyal <pulkit@yandex-team.ru> | date: Fri Apr 05 15:57:09 2019 +0300 | summary: branchcache: don't verify closed nodes in _branchtip() | o changeset: 7c9d4cf23adf | user: Pulkit Goyal <pulkit@yandex-team.ru> | date: Fri Apr 05 15:56:33 2019 +0300 | summary: branchcache: don't verify closed nodes in iteropen() | o changeset: 6578654916ae | user: Pulkit Goyal <pulkit@yandex-team.ru> ~ date: Mon Apr 01 13:56:47 2019 +0300 summary: branchcache: lazily validate nodes from the branchmap

branchcache: dispatch the code into the dedicated subclass The code useful only to the local brancache have now been moved into the dedicated subclass. This will help improving the branchcache code without subtle breaking the remote variants.

branchcache: introduce a base class for branchmap This will help define a clear boundary between the two.

branchcache: fix the copy code We copy some internal attribute along too. This should prevent inconsistency in the resulting branchmap.

branchcache: pass a "verify_node" attribut to __init__ instead of hasnode The hasnode callback cannot be inherited and is dropped on copy, which seems like a bad idea. Instead we pass the actual semantic as a parameter and let the internal logic deal with it.

branchcache: stop storing a repository instance on the cache altogether We did not really needed it and we do not needs it anymore at all. So lets make things simpler for consistency and garbage collecting and stop storing it altogether.

branchcache: pass the target repository when copying Branchmap are usually copied to be used on a different repoview using a different filter level. Passing the repository around means the repository in `branchcache._repo` will drift from the actual branchmap filter. This is currently "fine" because the repo is only used to retrieve the `nullid` value. However, this is a fairly big trap for any extension or future code using the `_repo` attribute. The replace logic is now using a copy to ensure the right repository view is used to initialized the cached value. We add a couple of assert for make sure this inconsistency does not sneak back.

branchcache: have an explicit method to update the on disk cache Explicit is better and will give use more flexibility for future evolution of the storage.

crecord: drop calls to `curses.endwin()` We got a bug report where `curses.endwin()` failed with `_curses.error: endwin() returned ERR`. Looking at e306d552dfb12, it seems like we should be able to just remove these calls.

config: move the option to mmap rev branch cache in the storage section See previous commit for rational.

config: document the storage and format sections This should help people to put configuration in the right section.

rust-index: drop offset_override The inline `offsets` value diverge from the one on disk for added value, so the offset_override tricks is not going to work well once we start having the full revlog logic in Rust. We remove it beforehand and align the Rust logic to the Python one (adjusting the segment offset at read time for inline revlog).

rust-index: stop calling `with_offset` in the tests We are not adding any data, so why are we setting any offset?

branching: merge stable into default

Added signature for changeset d1d48d18db37

Added tag 6.7rc0 for changeset d1d48d18db37

relnotes: add 6.7rc0

relnotes: remove outdated message from `next`

branching: merge default into stable for 6.7rc0

branching: merge stable into default

perf: add a --as-push option to perf::unbundle This turned out to make a quite significant difference.

chainsaw-update: exit early if one of the intermediate command fails That will prevent the user to be presented with a start that pretend to be consistent with the request, but is not.

chainsaw-update: lock the repository for the duration of the operation This should prevent and catch some misusage where something else try to touch the repository.

chainsaw-update: taking care of initial cloning Perhaps we should go just a bit lower level than this `instance()`, since the main added value in our use-case is full path resolution, that we need to do anyway for the rmtree cleanup.

chainsaw-update: use a graph with branching in graph This will be relevant for the next improvement of `chainsaw-update`.

chainsaw-update: log actual locks breaking Previously, the command would simply state that it was about to break locks, not if there was actually some to break. This version is race-free. It would be also possible to display the content of the lock before hand (not race-free but informative in almost all cases).

vfs: have tryunlink tell what it did It is useful in certain circumstances to know whether vfs.tryunlink() actually removed something or not, be it for logging purposes.

chainsaw: new extension for dangerous operations The first provided command is `chainsaw-update`, whose one and single job is to make sure that it will pull, update and purge the target repository, no matter what may be in the way (locks, notably), see docstring for rationale.

rust: disable the RustIndex without persistent nodemap See rational inline.

rust: stop claiming the C index is compatible with the rust code This is no longer the case since the introduction of the pure Rust Index, and was probably not the case since the MixedIndex itself. So we fix the dedicated attribute value.

rust-index: remove one collect when converting back Turns out this is slightly faster. Sending the results back to Python is still the most costly (like 75% of the time) of the whole method, but it's about as fast as it can be now. hg perf::phases on mozilla-try-2023-03-22 before: 0.267114 after: 0.247101

rust-index: improve phase computation speed While less memory efficient, using an array is *much* faster than using a HashMap, especially with the default hasher. It even makes the code simpler, so I'm not really sure what I was thinking in the first place, maybe it's more obvious now. This fix a significant performance regression when using the rust version of the code. (however, the C code still outperform rust on this operation) hg perf::phases on mozilla-try-2023-03-22 - 6.6.3: 0.451239 seconds - before: 0.982495 seconds - after: 0.265347 seconds - C code: 0.183241 second

phases: directly update the phase sets in advanceboundary This is similar to what we do in retractboundary. There is no need to invalidate the cache if we have everything at hand to update it.

phases: large rework of advance boundary In a similar spirit as the rework of retractboundary, the new algorithm is doing an amount of work in the order of magnitude of the amount of changeset that changes phases. (except to find new roots in impacted higher phases if any may exists). This result in a very significant speedup for repository with many old draft like mozilla try. runtime of perf:unbundle for a bundle constaining a single changeset (C code): before 6.7 phase work: 14.497 seconds before this change: 6.311 seconds (-55%) with this change: 2.240 seconds (-85%) Combined with the other patches that fixes the phases computation in the Rust index, the rust code with a persistent nodemap get back to quite interresting performances with 2.026 seconds for the same operation, about 10% faster than the C code.

phases: apply similar early filtering to advanceboundary advanceboundary is called the push's unbundle (but not the other unbundle) so advanceboundary did not show up the profile I looked at so far. We start with simple pre-filtering to avoid doing any work if we don't needs too.

phases: filter revision that are already in the right phase No need to compute new roots if everything is already in order.

phases: invalidate the phases set less often on retract boundary We already have the information to update the phase set, so we do so directly instead of invalidating the cache. This show a sizeable speedup in our `perf::unbundle` benchmark on the many-draft mozilla-try repository. ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.perf.perf-unbundle # bin-env-vars.hg.flavor = no-rust # bin-env-vars.hg.py-re2-module = default # benchmark.variants.issue6528 = disabled # benchmark.variants.revs = last-10 before: 2.055259 seconds after: 1.887064 seconds (-8.18%) # benchmark.variants.revs = last-100 before: 2.409239 seconds after: 2.222429 seconds (-7.75%) # benchmark.variants.revs = last-1000 before: 3.945648 seconds after: 3.762480 seconds (-4.64%)

phases: incrementally update the phase sets when reasonable When the amount of manual walking is small, we update the phases set manually instead of computing them from scratch. This should help small update. The next changesets will make this used more often by reducing the amount of full invalidation we do on roots upgrade. The criteria for using an incremental upgrade are arbitrary, however, it "should never hurt".

phasees: properly shallow caopy the phase sets dictionary We are about to increments the set more incrementally in some case, so we need to make a proper shallow copy of it.

phases: pass an unfiltered repository to _ensure_phase_sets It seems better for such a low level function to be able to assume it operate on a real repository.

phases: drop set building in `hasnonpublicphases` We don't actually use the set, so why do we ensure they are built? (we should also clean up the use of repository argument but that's a quest for later).

phases: gather the logic for phasesets update in a single method This logic is duplicated around for no good reason, we gather it in a single place. The conditional is the new function are a bit weird as we about going to extend it soon.

phases: change the way we warm the phasecache in repocache Same logic as for the previous chngeset. We are about to rename and change the method used here.

phases: use a more generic way to trigger a phases computation for perf Querying the tip most revision will require the cache to warm the same as calling the dedicated method. This avoid using a method that is mostly meant for internal use and will be renamed in a coming changesets.

phases: fix an overzealous invalidation of the phase sets If `len(cl) == self._loadedrevslen` the cache is up to date.

phases: type annotation for `_phasesets` Does not hurt.

phases: leverage the collected information to record phase update Since the lower level function already gather this information, we can directly use it. This comes with a small change to the test that are actually fixing them. The previous version over-reported some phase change that did not exists. In both case, we are force revision `1` to be secret and `0` remains draft`, the previous code wrongly reported `0` as moving to secret while it properly remained draft in the repository.

phases: large rewrite on retract boundary The new code is still pure Python, so we still have room to going significantly faster. However its complexity of the complex part is `O(|[min_new_draft, tip]|)` instead of `O(|[min_draft, tip]|` which should help tremendously one repository with old draft (like mercurial-devel or mozilla-try). This is especially useful as the most common "retract boundary" operation happens when we commit/rewrite new drafts or when we push new draft to a non-publishing server. In this case, the smallest new_revs is very close to the tip and there is very few work to do. A few smaller optimisation could be done for these cases and will be introduced in later changesets. We still have iterate over large sets of roots, but this is already a great improvement for a very small amount of work. We gather information on the affected changeset as we go as we can put it to use in the next changesets. This extra data collection might slowdown the `register_new` case a bit, however for register_new, it should not really matters. The set of new nodes is either small, so the impact is negligible, or the set of new nodes is large, and the amount of work to do to had them will dominate the overhead the collecting information in `changed_revs`. As this new code compute the changes on the fly, it unlock other interesting improvement to be done in later changeset.

phases: fast path public phase advance when everything is public Everything is already public, so we have nothing to do here.

phases: fast path retract of public phase There are no boundary to retract, so lets do nothing.

phases: keep internal state as rev-num instead of node-id Node-id are expensive to work with, dealing with revision is much simple and faster. The fact we still used node-id here shows how few effort have been put into making the phase logic fast. We tend to no longer use node-id internally for about ten years. This has a large impact of repository with many draft roots. For example this Mozilla-try copy have ½ Million draft roots and `perf::unbundle` see a significant improvement. ### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog # benchmark.name = hg.perf.perf-unbundle # bin-env-vars.hg.flavor = no-rust # bin-env-vars.hg.py-re2-module = default # benchmark.variants.issue6528 = disabled # benchmark.variants.revs = last-1 before:: 1.746791 seconds after:: 1.278379 seconds (-26.82%) # benchmark.variants.revs = last-10 before:: 3.145774 seconds after:: 2.103735 seconds (-33.13%) # benchmark.variants.revs = last-100 before:: 3.487635 seconds after:: 2.446749 seconds (-29.85%) # benchmark.variants.revs = last-1000 before:: 5.007568 seconds after:: 3.989923 seconds (-20.32%)

phases: do filtering at read time This remove the need for the `filterunknown` method at all.

phases: always write with a repo In the future change that move the internal representation of phase-roots from node-id to rev-num, we will use a repository to translate revision numbers back to node at write time. Since that future change is quite complicated already, we do this small API change beforehand.

phases: mark `phasecache.phaseroots` private We are about to change its content from nodeid to revnum. So anyone directly using the content might be in unexpected troubles. We start by making it private to explicitly break any such user (and discourage them to do so).

phases: check secret presence the right way during discovery There is an official function for this, lets use it. This will prevent the code to break in the future while we refactor the phase code.

phases: explicitly filter stripped revision at strip time Explicit is better than implicit. The current logic is bit subtle and fragile. It also get in the way of using something else than node-id as internal storage. We replace it with a more explicit filtering while striping.

debug: add a debug::unbundle command that simulate the unbundle from a push The code have different behavior when the unbundle comes from a push, so we introduce a command that can simulate such unbundle. For our copy of mozilla-try-2023-03-22, this make the unbundle jump from 2.5 seconds (with `hg unbundle`) to 15 seconds (with `hg debug::unbundle`). That 15 seconds timings is consistent with the issue seen in production.

perf: support --template on perf::phases

annotate: limit output to range of lines

revlog: add a Rust implementation of `headrevsdiff` Python implementation of `headrevsdiff` can be very slow in the worst case compared with the `heads` computation it replaces, since the latter is done in Rust. Even the average case of this Python implementation is still noticeable in the profiles. This patch makes the computation much much faster by doing it in Rust.

revlog: add a C implementation of `headrevsdiff` Python implementation of `headrevsdiff` can be very slow in the worst case compared with the `heads` computation it replaces, since the latter is done in C. Even the average case of this Python implementation is still noticeable in the profiles. This patch makes the computation much much faster by doing it in C.

unbundle: faster computation of changed heads To compute the set of changed heads it's sufficient to look at the recent commits, instead of looking at all heads currently in existence.

branching: merge stable into default

hg-core: separate timestamp and extra methods

debugformat: fix formatting for compression level `bytes(<int>)` gives a very different result as `str(<int>)` and the display of `hg debugformat` have been broken for a while as a result.

hg-core: implement timestamp line parsing

doc: document that labels must have a dot in them to have an effect I noticed that the `hg topics` template has a bare `topic` label with no dot, and that makes it useless, as such a label will never receive any effect by the colour extension. This dot has been required for a long time, at least since 2011, but we never formally documented it!

tests: tweak chg test to make it fail less often the test apparently sometimes prints the word "start" as a part of profile, so let's no longer match "start": CHGHG=/*/install/bin/hg (glob) + \x1b[90m | 50.0% 0.01s profiling.py: __enter__ line 196: self.start()\x1b[0m (esc) + \x1b[90m | 50.0% 0.01s profiling.py: start line 261: self._profiler.__enter__()\x1b[0m (esc) + \x1b[90m | 50.0% 0.01s profiling.py: statprofile line 125: statprof.start(mechanism=b'...\x1b[0m (esc) + \x1b[90m | 50.0% 0.01s statprof.py: start line 356: state.thread.start()\x1b[0m (esc) + \x1b[90m | 50.0% 0.01s threading.py: start line 852: self._started.wait()\x1b[0m (esc)

cext: fix potential memory leaks of list items appended with PyList_Append Also reduce the duplication in the tricky code that uses PyList_Append by extracting it into a function `pylist_append_owned`.

crecord: enable search hotkeys (issue6834) The keys I chose here should be similar to less/vim keybindings, which should fit the overall keybinding theme of crecord.

crecord: add handle(next|prev)search functions These are now just simple wrappers around `searchdirection`

crecord: add a searchdirection function If a regex has already been previously set, this function handles the UI elements of searching again forward or backward.

crecord: add a handlesearch function This function sets up some of the UI, such as getting the search string from the user and displaying results or their absence.

crecord: add a showsearch function This function takes a regex and searches either forward or backward, moving the current item to the found item, if any, and unfolding the relevant context.

crecord: add a default regex to curseschunkselector Whether there is a regex to search or not will affect if we can find the next or the previous search hit.

crecord: add `content` properties to all nodes In order to have a unified API of what can be searched, let's provide a `content` property to each node type. This way we can search filenames, context headers (e.g. containing function names, if deducible from patch context) or changed lines themselves.

crecord: update uiheader docstring There's no need to move anything to patch.py. The uiheader class only has methods relevant to crecord and overrides __getattr__ in order to use `patch.header` objects as a sort of mixin.

crecord: add skipfolded param to previtem This just simplifies the API a bit so it matches `nextitem` and I can handle both nextitem and previtem symmetrically.

dispatch: don't attempt to import debugger as bytestring The __import__ thingie needs a string, not a bytestring. Guess I'm the only one who uses this once in a while and noticed it was broken.

debugsetparents: fix Marmoutian docstring Just some light proofreading.

docs: fix broken `make` in `docs/` We had some wrapped lines without blank lines between, which made the runrst script think the list was not a list and it got confused about the indentation. I added blank lines, and also some other minor styling for consistency with the rest of the file.

branchmap: use mmap for faster revbranchcache loading A typical revbranchmap usage is: - load the entire revbranchmap file into memory - maybe do a few lookups - add a few bytes to it - write the addition to disk There's no reason to load the entire revbranchmap into memory. We can split it into a large immutable prefix and a mutable suffix, and then memorymap the prefix, thus saving all the useless loading. Benchmarking on some real-world pushes suggests that out of ~100s server-side push handling revbranchcache handling is responsible for: * ~7s with no change * ~1.3s with the change, without mmap * 0.04s with the change, with mmap

hghave: add py312 and py313 While not required in the core test suite in the moment, these could be useful in the future or for extensions. For example, Python 3.12 removed distutils and it might make sense to differentiate based on that.

hghave: use strings instead of floats for version numbers passed to checkvers I think it’s a really bad idea to use floats for version numbers. One problem is that 3.10 is the same as 3.1.

py3: fully port doctest to py3

import-checker: make stdlib path detection work in virtual environments The previous logic tried to find the directory containing BaseHTTPServer, which didn’t work as indended because it was only present on Python 2. Instead, the argparse module is used now.

cleanup: remove unnecessary list constructor calls around list comprehensions

branching: merge stable into default

Added signature for changeset 3fd1efb3ad12

Added tag 6.6.3 for changeset 3fd1efb3ad12

relnotes: add 6.6.3

tests: fix nondeterministic test failure in test-contrib-perf.t It turns out (not too shockingly!) the kernel sometimes has some work to do, perhaps at the very least context-switching, so asserting the system time is 0.000000 doesn't work.

grep: restore usage of --include/--exclude options The refactor in 4a73df6eb67d accidentally forgot to transform the opts argument for walkopts into a byteskwargs. This resulted in its options being ignored. In particular, the -X/-I pair of options was missing. A simple fix restores its usage. Tests included, of course.

rust-changelog: don't panic on empty file lists

tests: use sha256line.py instead of /dev/random in test-censor.t (issue6858) Sometimes the systems that run our test suite don't have enough entropy and they cannot produce target file of the expected size using /dev/random, which results in test failures. Switching to /dev/urandom would give us way more available data at the cost of it being less "random", but we don't really need to use entropy for this task at all, since we only care if the file size after compression is big enough to not be stored inline in the revlog. So let's use something that we already have used to generate this kind of data in other tests.

tests: make sha256line.py available for all tests This was previously only used in test-revlog-delta-find.t, but it will be useful (and used) in other tests that might need to generate poorly-compressible files.

delta-find: pass the full deltainfo to the _DeltaSearch class Having more information is better, so we pass it directly.

delta-find: move sparse-revlog pre-filtering in the associated class Lets move the specialized code in the specialized class.

delta-find: move sparse-revlog delta checks in the associated class Lets move the specialized code in the specialized class.

delta-find: split the _DeltaSearch class in two We now have things sliced small enough to have two class that use different `_iter_groups` implementation to encode their different logic. The filtering code remains to be moved, but I would rather keep this changeset simple and move them in the next.

delta-find: finish reworking the snapshot logic and drop more layer The refining logic only applies to the snapshot logic, and this is now all contained in a dedicated method. Along the way, we drop the refined_groups // raw_groups layer as they no longer make sense. The result is a more explicit `iter_groups` method. This conclude the splitting and simplification of the groups generation. We are now ready to dispatch this in more diverse classes.

delta-find: move the base of the delta search in its own function That logic is complicated enough that is is worth puting in its own function. Another method will be introduced in the next changeset to deal with the actual refining.

delta-find: move the emotion of prev in a dedicated method After splitting the filtering, and with the `_candidate_groups` layer removed, we can start splitting the group generation too. This helps to organize this code and make it easier to modifying the future.

delta-find: move the emotion of parents in a dedicated method After splitting the filtering, and with the `_candidate_groups` layer removed, we can start splitting the group generation too. This helps to organize this code and make it easier to modifying the future.

delta-find: explicitly deal with usage of the cached revision We can remove this from the general logic path and directly deal with this corner case early. This result in a small change in test-generaldelta.t as it turns out that: - at commit time we (sometimes) precompute a delta against p1 and pass it as the cached delta. - since cached delta where going through the same filtering as everything, we could "optimize" the base if it applied to an empty delta, resulting in not using the pre-computed delta. The simpler logic fix the second item, making the cached delta base always actually tested when requested. Note that the computation of a fast delta against p1 only is questionable, but looking into that is out of scope for this series.

delta-find: remove the "candidate groups" layer We have enough pieces to remove this generator and directly bear it load using the underlying object.

delta-find: stop using heuristic to determine if we are creating a snapshot This avoid assuming a changeset is a snapshot when it is actually something simpler.

delta-find: explicitly track stage of the search Being more explicit about what we are doing is going to be useful. We actually start making use of it in later changesets.

delta-find: drop some dead debug code Seems like it was never put to use, so lets simply remove it for now.

delta-find: introduce and use specialized _DeltaSearch class For now, we introduce some very simple variant, but they are still useful to display how having the class can helps keeping the simple case simple and their special case out of more advanced logic.

delta-find: introduce a base class for _DeltaSearch This prepare the introduction of specialized the class in the next changesets.

delta-find: simplify the delta checking function for snapshot Since the function is all about snapshot, we can safely use an early return and make the result simpler.

delta-find: move good delta code earlier in the class Nothing change except the code location. This greatly helps readability of the next future diff,

delta-find: split is_good_delta_info into more thematic function Same logic as for candidate filtering, we group code into related sub method. This will help clarifying later patches as some logic is pre-splitted

delta-find: clarify some comment and code in is_good_delta_info We move the comment closer to the code it describ and we compute an intermediate value without using the `textlen` variable, as it will stop being defined in a future patch. This will clarify future patches.

delta-find: move delta size check earlier in is_good_delta_info This will clarify future patches by regrouping related logic before larger movement.

delta-find: split the delta-chain part of `_pre_filter_rev` in a method Since `_pre_filter_rev` contains logic from various sources of constraint, we start splitting is in subfunction to clarify and document the grouping.

delta-find: split the "sparse" part of `_pre_filter_rev` in a method Since `_pre_filter_rev` contains logic from various sources of constraint, we start splitting is in subfunction to clarify and document the grouping.

delta-find: split the generic part of `_pre_filter_rev` in a method Since `_pre_filter_rev` contains logic from various sources of constraint, we start splitting is in subfunction to clarify and document the grouping.

delta-find: drop the temporary indent Now that the complicated change is made, we can do the noisy one.

delta-find: move pre-filtering of individual revision in its own function This goes one step further than the previous change by making the pre-filtering of individual candicates revision in its own function. This will allow subclass to easily configure this filtering with their own constrains. The `if True:` part help the readability of this diff a lot and will be drop in to the next changesets.

delta-find: move pre-filtering of candidates in its own function This organise the code further and open the way to specialization via sub-classing. Something important for the coming changes.

delta-find: move away from the generator API for _DeltaSearch We use more explicit function call. This make operations more explicit and will make future refactoring simpler.

delta-find: use "-1" as depth snapshot-dept for non snapshot in debug This will help do distinct full snapshot (level 0) and normal delta (not a snapshot, no snapshot level)

delta-find: fix the computation of the `prev` value The previous computation was "wrong" it always used the tiprev, even when computing a delta in a non-append case (mostly benchmark). This never produced wrong delta on disk, but would misled debug or performance command. Since it does not have any actual user impact, I did not put this on stable. With the code fixed we can now use revisions in some search and it makes the test display more interesting behavior since the algorithm has more to work with.

delta-find: move is_good_delta_info on the _DeltaSearch class There is a lot of format specific code in `is_good_delta_info`, moving it on _DeltaSearch will allow to split this into subclass soon.

delta-find: feed revinfo to _DeltaSearch The revinfo has more information and will allow for even more function to be turned into method.

delta-find: clarify that revisioninfo.p1/p2 constains nodeid This clarify the content of these attributes.

delta-find: move filing of some debug data in `_one_dbg_data` Since the `_one_dbg_data` method is meant to create a valid debug dictionnary. We can as well prefill the relevant value to reduce the amount of debug code in the main code.

delta-find: add more explanation to the the deltas_limit < length check More explanations is always good.

delta-find: move tested in the _DeltaSearch.__init__ Now that we have an object we can initialize that attribute at initialization time. This will make it available for more method in the future, allowing to split the code.

delta-find: check DELTA_BASE_REUSE_FORCE in the _DeltaSearch.__init__ Now that we have an object we can check that DELTA_BASE_REUSE_FORCE cases does not reach this code at in a more suitable location.

delta-find: move target_rev in the _DeltaSearch.__init__ Now that we have an object we can initialize that attribute at initialization time.

delta-find: move snapshot_cache in the _DeltaSearch.__init__ Now that we have an object we can initialize that attribute at initialization time.

delta-find: move `_rawgroups` on the `_DeltaSearch` object Moving more code before doing more logic changes.

delta-find: move `_refinedgroups` on the `_DeltaSearch` object Moving more code before doing more logic changes.

delta-find: introduce a _DeltaSearch object That object represent the search of a good delta for one revision. It will replace the interleaved generator currently in use. It will make the logic more explicit and easier to split into different subclass for the algorithm variant. We will move content gradually before doing deeper rework. For now, we only move the `_candidategroups` function here. More will follow in the same series.

delta-find: add a small docstring to deltacomputer As we are about to introduce another object related to finding delta. So lets have a minimal docstring to the existing one.

revlog: stop using `atomictmp` for the split revlog Since we already manually deal with writing on the side and delaying visibily, we no longer need this.

changelog: drop the side_write argument to revlog splitting The only user is now gone.

changelog: stop useless enforcing split at the end of transaction Changelogs are no longer created inline, and existing changelogs are automatically split. Since we now enforce splitting at the start of any write, we don't need to enforce splitting at the end of the transaction. This has the nice side effect of killing the only user of "side_write".

tests: don't use "status" operand of dd in test-censor.t (issue6858) Some implementations don't have this operand, let's just direct stderr into /dev/null, that's pretty cross-platform. Also specify bs=512 (the default for me), because the default might be different on different systems. Other uses of dd in the tests do specify it, so this is more consistent.

branching: merge stable into default

Added signature for changeset 136902b3a95d

Added tag 6.6.2 for changeset 136902b3a95d

relnotes: add 6.6.2

pycompat: fix bytestr(bytes) in Python 3.11 In Python 3.10, the `bytes` type itself does not have a `__bytes__` attribute, but it does in 3.11. Yet `bytes(bytes)` does not give the wished output, so we have to add an exceptional case. The added case in the doctest reproduces the problem with Python 3.11. Impact: error treatment in expressions such as `repo[b'invalid']` gets broken.

narrow: prevent removal of ACL-defined excludes

narrow: add test demonstrating bug in acl exclusion enforcement

contrib: add a set of scripts to run pytype in Docker Having a simple way to run pytype for developers can massively shorten development cycle. Using the same Docker image and scripts that we use on our CI guarantees that the result achieved locally will be very similar to (if not the same as) the output of our CI runners. Things to note: the Dockerfile needs to do a little dance around user permissions inside /home/ci-runner/ because: - on one hand, creating new files on the host (e.g. .pyi files inside .pytype/) should use host user's uid and gid - on the other hand, when we run the image as uid:gid of host user, it needs to be able to read/execute files inside the image that are owned by ci-runner Since local user's uid might be different from ci-runner's uid, we execute this very broad chmod command inside /home/ci-runner/, but then run the image as the host user's uid:gid. There might be a better way to do this.

pytype: use "$(hg root)" instead of `hg root` to make shellcheck happier

pytype: update check-pytype.sh to select target automatically We have python3.11 on CI, so we can run pytype targeting that version. On the other hand, we don't have python3.7 on CI anymore, so we can't run pytype for 3.7 anymore (interpreter not found). I think it's fine to make pytype select the appropriate target depending on the version of the interpreter it's running under.

git-hgext: adjust to the lack of `changelog.heads` method We don't have a `heads` method returning nodeid, but this is very easy to get the same result. This was flagged by pytype. We can note that the fact this code did not break is probably a good sign that it is dead code. However this is a question outside of the scop of this series.

remotefilelog: drop dead code As pytype flagged bug in this method it highlighted that this methode being never called anywhere.

pytype: use the right signature for the `__delitem__` It is not because it is NotImplemented that it should use a bad signature. Fix it to please pytype.

pytype: use the right signature for the `__setitem__` It is not because it is NotImplemented that it should use a bad signature. Fix it to please pytype.

sparse: use with statement for wlock This will avoid pytype complaining about the try/except range.

remotefilelog: adjust the signature of basepack.createindex pytype point that the subclass signature have been updated.

pytype: add the couple annotations for pytype to understands the lrunode After loosing 2d6 SAN, I eventually understood that pytype was confused by method return type. Pytype is now happy.

pytype: ignore some signature mismatch in registrar pytype is grumpy about a sub method having a different signature than the one we use here. pytype error: internalmerge: Overriding method signature mismatch [signature-mismatch] Base signature: 'def _funcregistrarbase._extrasetup(self, name, func) -> Any'. Subclass signature: 'def internalmerge._extrasetup(self, name, func, mergetype, onfailure = None, precheck = None, binary = False, symlink = False) -> Any'. Parameter 'mergetype' must have a default value.

hgweb: update _runwsgi try/except range to be valid The `tmpl` variable is used in the `except` and `finally`, so we need it created before the `try` is open.

pytype: add type information for `annotateresult.lines` This seems to appease a confused pytype.

pytype: ignore attribute error for time.clock This seems to be a Windows only attribute.

pytype: ignore certifi import error This is an optional import so we should not complains about it.

pytype: ignore some signature mismatch in configitems pytype is grumpy about the dict.update having a more complex signature than the one we use here. pytype error: itemregister: Overriding method signature mismatch [signature-mismatch] Base signature: 'def builtins.dict.update(self) -> None'. Subclass signature: 'def itemregister.update(self, other) -> Any'. Parameter 'other' must have a default value.

pytype: only output the "pytype crashed" message on error If pytype did not crash while generating stub, that message is kind of confusing. It seems simple enough to avoid it in this case.

pytype: drop the now useless assert As the imported types are now used by type annotation, these ugly assert are no longer needed.

pytype: drop the last inline type comment We can't assign type to the "for" variant on the fly, so we type the variable and method used instead.

pytype: convert type comment for inline variable too Same logic as for the previous changeset, but for "type comment" annotating variables, not function/method. As for the previous changeset, we had to adjust for of the types to actually match what was happening.

pytype: move some type comment to proper annotation We support direct type annotations now, while pytype is starting to complains about them.

lock: properly convert error to bytes Flagged by pytype when a later changeset is applied moving typing comment to annotation. We fix this ahead of the annotation change to make sure pytype remains happy after the change. We have to do fairly crazy dance for pytype to be happy. This probably comes from the fact IOError.filename probably claims to be `str` while it is actually `bytes` if the filename raising that `IOError` is bytes. At the same time, `IOError.strerror` is consistently `str` and should be passed as `str` everywhere.

pytype: import typing directly First we no longer needs the pycompat layer, second having the types imported in all case will allow to use them more directly in type annotation, something important to upgrade the old "type comment" to proper type annotation. A lot a stupid assert are needed to keep pyflakes happy. We should be able to remove most of them once the type comment have been upgraded.

usage: configure uncompressed chunk cache through resource configuration Let's use this new concept for what it is meant for. This provides a sizable speed up for reading multiple revision for some complexe repositories. ### data-env-vars.name = pypy-2018-08-01-zstd-sparse-revlog # benchmark.name = hg.perf.read-revisions # benchmark.variants.order = reverse memory-medium: 1.892400 memory-high: 1.722934 (-8.61%) # benchmark.variants.order = default memory-medium: 1.751542 memory-high: 1.589340 (-9.49%)

usage: add configuration option to adjust resources usage They currently do nothing, but this open the way to actually use them.

usage: add a `usage.repository-role` config This config will be used for behavior and performance adjustment depending of the repository role.

common-pattern: cover "elapsed time" line These are perfect targets for the common-pattern matching.

bundle: do not detect --base argument that match nothing as lack of argument With the previous version of the code, if --base did not match anything, it will be handled as if no --base was provided and will fallback to using discovery with the default path. This has two issues : - The resulting bundle won't match what the user requested, - if not default path is configured, it will crash. We now properly distinct between the two cases and if the --base query does not find any changeset, we will assume that everything under --rev needs to be sent.

bundle: highlight misbehavior when --base does not match any revision See next changeset for fix and details.

branching: merge with stable I need the fix to `generate-churning-bundle.py`.

generate-churning-bundle: fix script for python3 This script has apparently not run for a long time.

narrow: strip trailing `/` from manifest dir before matching it Commit 17a822d7943e broke some of our internal tests at Google because the `dir` variable contains a trailing slash since that commit. Let's restore the old behavior by stripping that trailing slash.

tests: demonstrate error when narrowing with `rootfilesin:` pattern This demonstrates a bug introduced in 17a822d7943e.

matchers: use correct method for finding index in vector The path matcher has an optimization for when all paths are `rootfilesin:`. This optimization exists in both Python and Rust. However, the Rust implementation currently has a bug that makes it fail in most cases. The bug is that it `rfind()` where it was clearly intended to use `rposition()`. This patch fixes that and adds a test.

dirstate: make the `transaction` argument of `setbranch` mandatory This is deprecated since 6.4. We should drop it now.

rust-clippy: apply some more trivial fixes All of these were hinted at by clippy and make the code simpler.

rust-clippy: simplify `match` to `if let` This was hinted at by clippy, and makes it more obvious that nothing is happening in the `None` case.

censor: accept multiple revision in a single call This is useful when dealing with corruption, as all the corrupted revision can be dealt with in one go.

censor: be more verbose about the other steps too If we informs the user about head checking, we should tell him when the other operation happens too. Otherwise the user can imagine to still be in the head checking part.

censor: add a command flag to skip the head checks In some case we spend hours of time checking the heads to censors a simple file is not a good behavior. Especially when censors is used to removed corrupted content.

censor: inform the user that we are spending time checking heads The time this can consume can be a surprise to the user, lets be explicit about it.

censor: mention that we check the heads in the help And add a message to will explain the possibly long time spent doing this.

persistent-nodemap: respect the mmap setting when refreshing data After writing updated data, we reload the in-memory data. However, that logic was… wrong. We were doing file read when mmap was requested and when the configuration was requesting to not use mmap… we were using it. This should now be fine.

rust-index: only access offsets if revlog is inline Accessing the `RwLock` ended up showing up in profiles even with no contention. Offsets only exist for inline revlogs, so gate everything behind an inline check.

rust-index: cache the head nodeids python list Same optimization as before, but for the nodeids this time.

rust-index: add fast-path for getting a list of all heads as nodes This avoids a lot of back-and-forth between Python and Rust. We forgo adding a fast-path in the `filteredchangelog` case yet. If it shows up in profiling, we might add the variant with a filter.

rust-index-cpython: cache the heads' PyList representation This is the same optimization that the C index does, we just have more separation of the Python and native sides.

rust-index: use a `BitVec` instead of plain `Vec` for heads computation The `Vec` method uses one byte per revision, this uses 1 per 8 revisions, which improves our memory footprint. For large graphs (10+ millions), this can make a measurable difference server-side. I have seen no measurable impact on execution speed.

rust-index: implement faster retain heads using a vec instead of a hashset This is the same optimization that the C index does, we're only catching up now because this showed up as slow in benchmarking.

rust-index: allow inlining VCSGraph parents across crates

rust-index: allow inlining `parents` across crates

rust-index: allow inlining `check_revision` across crates

rust-index: document safety invariants being upheld for every `unsafe` block We've added a lot of `unsafe` code that shares Rust structs with Python. While this is unfortunate, it is also unavoidable, so let's at least systematically explain why each call to `unsafe` is sound. If any of the unsafe code ends up being wrong (because everyone screws up at some point), this change at least continues the unspoken rule of always explaining the need for `unsafe`, so we at least get a chance to think.

rust-index: renamed `MixedIndex` as `Index` It is simply not mixed any more, hence the name had become a future source of confusion.

rust-index: stop instantiating a C Index The only missing piece was the `cache` to be returned from `revlog.parse_index_v1_mixed`, and it really seems that it is essentially repetition of the input, if `inline` is `True`. Not worth a Rust implementation (C implementation is probably there for historical reasons).

rust-revlog: using the ad-hoc `NodeTree` in scmutil Now that we have an independent `NodeTree` class able to work natively on the pure Rust index, we use it in `mercurial.scmutil`, with automatic invalidation after mutation of the index. This code path is tested by `test-revisions.t` and `test-template-functions.t`

rust-revlog: add invalidation detection to `NodeTree` class This will be useful for callers, such as `scmutil` who reuse a `NodeTree` instance as a cache. They would otherwise get hard errors if any mutation of the index occurred since instantiation. This is something the C index does not provide.

rust-index: add support for `del index[r]` Only the `del index[r:]` syntax was supported, but the comment said otherwise. It's not actually used in core code, but the C index supports it.

rust-revlog: bare minimal NodeTree exposition The independent `NodeTree` instances needs to be associated to an index (for forward-checks of candidates) but do not need to encompass all revisions from that index. This is exactly how it is used in `scmutil.shortesthenodeidprefix` and we restrict the implementation to the bare minimum needed there and to write convincing tests. It would of course be fairly trivial to add more.

rust-index: a property to identify the Rust index as such Will be useful soon in `mercurial.scmutil` and potentially elsewhere

rust-cpython-revlog: renamed NodeTree import as CoreNodeTree We're about to introduce a `NodeTree` Python class (hence also a Rust struct) and it would be a collision with the import

rust-index: stop using C index We still keep its wrapper implementation in `hg-cpython::cindex`, because we might want to recreate ancestors handling objects using it for the case of REVLOGV2. Also, we still instantiate it (from Python code) and store it as attribute, for the likes of `get_cindex` and the caller that relies on it, but that is soon to be removed, too.

rust-index: using `hg::index::Index` in discovery At this point the C index is not used any more: we had to remove `pyindex_to_graph()` to avoid the dead code warning.

rust-python-testing: separated base test classes This will allow, e.g., to change `test-rust-discovery.py` simply by adding the appropriate base class.

rust-discovery: encapsulated conversions to vec for instance methods This new `pyiter_to_vec` is pretty trivial, and only mildly reduces code duplication. The main advantage is that it encapsulates access to the `index` attribute, which will be changed when we replace the C index by the Rust index, given as `PySharedRef`.

rust-discovery: moving most of hg-cpython methods to regular code blocks The chosen methods are those with conversion of an incoming Python iterable, as they will be changed the most when we will remove the C index, and `takefullsample` for consistency with `takequicksample`.

rust-index: using `hg::index::Index` in `hg-cpython::dagops` Hooking `headrevs` to the Rust index is straightforward as long as we go the `PySharedRef` way. Direct attempts of obtaining a reference to the inner `hg::index::Index` fail for lifetime reasons: the reference is bound to the GIL, yet the `as_set` local variable is considered to be static (the borrow checker clearly does not realize or care that this set only stores `Revision` values). In `rank()`, the chosen solution is the simplest as far as `hg-cpython` is concerned, but it has the defect of removing an implementation that would be easily adaptable if the core index did implement `RankedGraph` (returning the same error as long as only `REVLOGV1` is supported), but that would introduce a direct dependency of `hg-core` on the ``vcsgraph` crate.

rust-index: using `hg::index::Index` in MissingAncestors With this, the whole `hg-cpython::ancestors` module can now work without the C index.

rust-index: using the `hg::index::Index` in ancestors iterator and lazy set Since there is no Rust implementation for REVLOGV2/CHANGELOGv2, we declare them to be incompatible with Rust, hence indexes in these formats will use the implementations from Python `mercurial.ancestor`. If this is an unacceptable performance hit for current users of these formats, we can later on add Rust implementations based on the C index for them or implement these formats for the Rust indexes. Among the challenges that we had to meet, we wanted to avoid taking the GIL each time the inner (vcsgraph) iterator has to call the parents function. This would probably still be acceptable in terms of performance with `AncestorsIterator`, but not with `LazyAncestors` nor for the upcoming change in `MissingAncestors`. Hence we enclose the reference to the index in a `PySharedRef`, leading to more rigourous checking of mutations, which does pass now that there no logically immutable methods of `hg::index::Index` that take a mutable reference as input.

revlog: always use a Rust index for REVLOGv1 if rustext is present We are about to change classes such as `rustext.AncestorsIterator` to take a Rust index, hence we cannot have the option not to use the Rust index. Note: this can be refined depending on whether we want to keep this option or not. We will have to make two versions of `AncestorsIterator` and its sibling to support REVLOGV2 and CHANGELOGv2 anyway. Meanwhile, this is the simplest change to make the tests pass.

rust-index: disabling flagprocessor tests The list of flags supported by the Rust index is not dynamic, hence flagprocessor has no chance to work.

rust-index: support `unionrepo`'s compressed length hack Explanations inline.

rust-index: honour incoming using_general_delta in `deltachain` It looks to be a leftover from some past, but the C index considers only the value passed from Python whereas up to now the Rust index was using the value of its attribute. As a middle ground, we make this argument of `deltachain` optional from the Python side, with the Rust implementation only defaulting to its attribute. This way, we reduce false leads when a difference in results is spotted.

rust-index: use interior mutability in head revs and caches For upcoming changes in `hg-cpython` switching to the `hg-core` index in ancestors iterators, we will need to avoid excessive mutability, restricting the use of mutable references on `hg::index::Index` to methods that actually logically mutate it, whereas the maintenance of caches such as `head_revs` clearly does not. We illustrate that immediately by switching to immutable borrows in the corresponding methods of `hg-cpython::MixedIndex`

rust-index: add Sync bound to all relevant mmap-derived values All readonly mmaps are Sync as far as Rust is concerned. Integrity of the mmap'ed file is a concern separate to Rust's memory model, since it requires out-of-program handling via locks, etc. This will help when we start sharing the Rust Index with Python.

debugindexstats: handle the lack of Rust support better We don't have any stats in the Rust index. Currently it is not known which stats would be interesting to get, so if they end up being important, we can add them later.

rust-python-index: don't panic on a corrupted index when calling from Python This makes `test-verify.t` pass again. In an ideal world, we would find the exact commit where this test breaks and amend part of this change there, but this is a long enough series.

tests: ignore test-storage when using Rust This is only relevant for Python code and the SQLite backend, which is in a half-abandoned state.

rust-index: optimize find_gca_candidates() on less than 8 revisions This is expected to be by far the most common case, given that, e.g., merging involves using it on two revisions. Using a `u8` as support for the bitset obviously divides the amount of RAM needed by 8. To state the obvious, on a repository with 10 million changesets, this spares 70MB. It is also possible that it'd be slightly faster, because it is easier to allocate and provides better cache locality. It is possible that some exhaustive listing of the traits implemented by `u8` and `u64` would avoid the added duplication, but that can be done later and would need a replacement for the `MAX` consts.

rust-index: simplification in find_gca_candidates() `parent_seen` can be made a mutable ref, making this part more obvious, not needing to be commented so much. The micro-optimization of avoiding the union if `parent_seen` and `current_seen` agree is pushed down in the `union()` method of the fast, `u64` based bit set implementation (in case it matters).

rust-index: avoid double negation in find_gca_candidates()

rust-index: avoid some cloning in find_gca_candidates() Instead of keeping the information whether the current revision is poisoned on `current_seen`, we extract it as a boolean. This also allows us to simplify the explanation of `seen[r].is_poisoned()`, as the exceptional case where it is poisoned right after `r` has been determined to be a solution does no longer exist.

rust-index: implement common_ancestors_heads() and ancestors() The only differences betwwen `common_ancestors_heads()` and `find_gca_candidates()` seems to be that: - the former accepts "overlapping" input revisions (meaning with duplicates). - limitation to 24 inputs (in the C code), that we translate to using the arbitrary size bit sets in the Rust code because we cannot bail to Python. Given that the input is expected to be small in most cases, we take the heavy handed approach of going through a HashSet and wait for perfomance assessment In case this is used via `hg-cpython`, we can anyway absorb the overhead by having `commonancestorheads` build a vector of unique values directly, and introduce a thin wrapper over `find_gca_candidates`, to take care of bit set type dispatching only. As far as `ancestors` is concerneed, this is just chaining `common_ancestors_heads()` with `find_deepest_revs`.

rust-index: find_gca_candidates bit sets genericization This allows to use arbitratry size of inputs in `find_gca_candidates()`. We're genericizing so that the common case of up to 63 inputs can be treated with the efficient implementation backed by `u64`. Some complications with the borrow checker came, because arbitrary sized bit sets will not be `Copy`, hence mutating them keeps a mut ref on the `seen` vector. This is solved by some cloning, most of which can be avoided, preferably in a follow-up after proof that this works (hence after exposition to Python layer). As far as performance is concerned, calling `clone()` on a `Copy` object (good case when number of revs is less than 64) should end up just doing a copy, according to this excerpt of the `Clone` trait documentation: Types that are Copy should have a trivial implementation of Clone. More formally: if T: Copy, x: T, and y: &T, then let x = y.clone(); is equivalent to let x = *y;. Manual implementations should be careful to uphold this invariant; however, unsafe code must not rely on it to ensure memory safety. We kept the general structure, hence why there are some double negations. This also could be made nicer in a follow-up. The `NonStaticPoisonableBitSet` is included to ensure that the `PoisonableBitSet` trait is general enough (had to correct `vec_of_empty()` for instance). Moving the genericization one level to encompass the `seen` vector and not its elements would be better for performance, if worth it.

rust-index: core impl for find_gca_candidates and find_deepest This still follows closely the C original and not able to treat more than 63 input revisions (bitset backed by `u64` and one bit reserved for poisoning).

rust-index: add support for `reachableroots2` Exposition in `hg-cpython` done in regular impl block, again for rustfmt support etc.

hg-cpython: rev_pyiter_collect_or_else It will be useful to give callers the control on the generated errors

rust-index: add support for `computephasesmapsets` Exposition in `hg-cpython` done in the regular `impl` block to enjoy rustfmt and clearer compilartion errors.

rust-index: slicechunktodensity returns Rust result Ready for removal of the scaffolding. This time, we allow ourselves a minor optimization: we avoid allocating for each chunk. Instead, we reuse the same vector, and perform at most one allocation per chunk. The `PyList` constructor will copy the buffer anyway.

rust-index: add support for `_slicechunktodensity`

rust-index: headrevsfiltered() returning Rust result

rust-index: add support for `headrevsfiltered` The implementation is merged with that of `headrevs` also to make sure that caches are up to date.

rust-index: implement headrevs

rust-index: variant of assert_py_eq with normalizer expression The example given in doc-comment is the main use case: some methods may require ordering insensitive comparison. This is about to be used for `reachableroots2`

rust-index: add support for delta-chain computation

rust-index: add support for `find_snapshots`

rust-index: add `is_snapshot` method

rust-index: use the Rust index in `partialmatch`

rust-index: add missing special case for null rev This was an oversight, it was never a problem because we didn't use the index much for user-facing things in the past, which is the only real way of getting to this edge case.

rust-index: use the rust index in `shortest`

rust-index: add checks that `__contains__` is synchronized

rust-index: using the Rust index in nodemap updating methods

rust-index: implementation of __getitem__ Although the removed panic tends to prove if the full test suite did pass that the case when the input is a node id does not happen, it is best not to remove it right now. Raising IndexError is crucial for iteration on the index to stop, given the default CPython sequence iterator, see for instance https://github.com/zpoint/CPython-Internals/blobs/master/BasicObject/iter/iter.md This was spotted by `test-rust-ancestors.py`, which does simple interations on indexes (as preflight checks). In `revlog.c`, `index_getitem` defaults to `index_get` when called on revision numbers, which does raise `IndexError` with the same message as the one we are introducing here.

rust-index: optim note for post-scaffolding removal

rust-index: check that the entry bytes are the same in both indexes This is a temporary measure to show that both the Rust and C indexes are kept in sync. Comes with some related documentation precisions. For comparison of error cases, see `index_entry_binary()` in `revlog.c`.

rust-index: return variables systematic naming convention To help knowing at a glance when a method is ready, making us more comofortable when we are close to the final removal of scaffolding, we introduce the systematic variable names `rust_res` and `c_res`. The goal of this series is to always return the formet. We take again the case of `pack_header` as example. Our personal opinion is to usually avoid such poor semantics as `res`, but usually accept it when it close to the actual return, which will be the case in most methods of this series. Also, the name can simply be dropped when we remove the scaffolding. To follow on the example, the body of `pack_header()` should become this in the final version: ``` let index = self.index(py).borrow(); let packed = index.pack_header(args.get_item(py, 0).extract(py)?); Ok(PyBytes::new(py, &packed).into_object()); ``` in these cases it is close to the actual return and will be removed at the end entirely.

rust-index: results comparison helper with details This is a bit simpler to call and has the advantage of systematically log the encountered deviation. To avoid committing dead code, we apply it to the `pack_header` method, that was already returning the Rust result.

rust-index: helper for revision not in index not involving nodemap This is a good match for exceptions raised from the C implementation, when it is not about a nodemap inconsistency.

rust-index: renamed nodemap error function for rev not in index The function name was misleading, as the error wording mentions the nodemap, hence would not be appropriate for missing revisions not related to a nodemap lookup.

rust-index: add `pack_header` support

rust-index: support cache clearing I'm not 100% sure how useful it is outside of perf, but it's still worth implementing.

rust-index: check rindex and cindex return the same get_rev This is a temporary safeguard while we synchronize both indexes.

rust-index: synchronize remove to Rust index Future steps will bring the two indexes further together until we can rip the C index entirely when running Rust code.

rust-index: remove `__setitem__` method from the mixed index This is not defined on the Python or C one, and isn't used anywhere.

rust-index: check equality between rust and cindex for `__len__`

rust-index: synchronize append method We now append to the Rust index just as we do to the C index. Future steps will bring the two indexes further together until we can rip the C index entirely when running Rust code.

rust-revlog: teach the revlog opening code to read the repo options This will become necessary as we start writing revlog data from Rust.

rust-index: pass data down to the Rust index This will allow us to start keeping the Rust index synchronized with the cindex as we gradually implement more and more methods in Rust. This will eventually be removed.

rust-index: add append method This is the first time the Rust index has any notion of mutability. This will be used in a future patch from Python, to start synchronizing the Rust index and the C index.

rust-index: add an abstraction to support bytes added at runtimes In order to support appending data to the Rust index, we need to abstract data access away from the immutable (on-disk) bytes, to seemlessly fetch either from the preexisting data or from the newly added data.

rust-mixed-index: move the mmap keepalive into a function The same code will be used for keeping the new index mmap around.

rust-mixed-index: rename variable to make the next change clearer We're going to add another mmap reference holder, so let's rename this one first.

rust: fix cargo doc for hg-cpython

branching: merge with default We merge with the current children of the bad merge (37b52b938579)

branching: merge with stable This recreates `37b52b938579` right as a `hg branch --rev 5b186ba40001` screwed up the content.

changelog: disallow delayed write on inline changesets Since this will never happens, we can make the situation invalid and to stop to handling the associated the case. This simplify the random access file reading too.

changelog: never inline changelog The test suite mostly use small repositories, that implies that most changelog in the tests are inlined. As a result, non-inlined changelog are quite poorly tested. Since non-inline changelog are most common case for serious repositories, this lack of testing is a significant problem that results in high profile issue like the one recently fixed by 66417f55ea33 and 849745d7da89. Inlining the changelog does not bring much to the table, the number of total file saved is negligible, and the changelog will be read by most operation anyway. So this changeset is make it so we never inline the changelog, and de-inline the one that are still inlined whenever we touch them. By doing that, we remove the "dual code path" situation for writing new entry to the changelog and move to a "single code path" situation. Having a single code path simplify the code and make sure it is covered by test (if test cover that situation obviously) This impact all tests that care about the number of file and the exchange size, but there is nothing too complicated in them just a lot of churn. The churn is made "worse" by the fact rust will use the persistent nodemap on any changelog now. Which is overall a win as it means testing the persistent nodemap more and having less special cases. In short, having inline changelog is mostly useless and an endless source of pain. We get rid of it.

test-transaction-safety: glog out irrelevant flag The test is focussing on the inline flag, so we glob out the other to highlight that fact and prevent noise in the future.

test-transaction-safety: perform the test on a filelog This test previously checked the transaction safety of splitting the changelog. The changelog is a special case, with delayed/diverted writes and we will stop inlining it soon. So we keep testing that transaction is safe around inline on another revlog type : a filelog. Minor comestic adjustement will be done in the next changesets.

test: clarify test-parseindex offsets We will make this revlog non-inline, so we clarify the code to make sure it is simple to adjust the test later.

test: use more globing for perf timing Not sure why we kept the number here.

branching: merge with stable

persistent-nodemap: avoid writing nodemap for empty revlog The format cannot encode the lack of tip_rev. There is currently nothing known to write such empty nodemap right now, but the change we are preparing on default reveal this issue. So I had rather fix it on stable.

histedit: remove superfluous echo() and endwin() calls (issue6859) ncurses patchlevel 20231111 started returning an error from endwin() if called twice without a intervening screen update. Per Sven Joachim in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058041#17: "AFAICS, invoking curses.echo() and curses.endwin() is superfluous because curses.wrapper already does that for you, and calling curses.endwin() twice throws an error with the newer ncurses. Removing those two lines should fix the problem."

statprof: handle `lineno == None` in more cases This continues the work from 972f3e5c94b8. We saw a crash on line 956 but I updated lots of other places as well.

branching: merge stable into default