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".

branching: merge stable into default

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.

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

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.

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.