branching: merge stable into default

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

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.