branching: merge stable into default for 6.9 cycle

Added signature for changeset 11f41248595b

Added tag 6.8 for changeset 11f41248595b

relnotes: add 6.8

test-check: don't report distutils as a local import On python 3.12 this is wrongly reported as a local import. So we adjust the checker to avoid it.

Backed out changeset f28c52a9f7b4 This backout and the previous are due to a large performance regression detected in repositories with a lot of obsmarkers when performing a clone. A better fix will come along at the start of the next cycle.

Backed out changeset ff523675cd69

rust: use `cpython` 0.7.2 crate to add support for Python 3.12 This will give us more headroom until we can migrate to PyO3 some day.

revbranchcache: disable mmap access by default The revbranchcache can be truncated (if some part of it is detected as invalid). Using mmap on file we truncate is not an option at access to truncated part would result in a SIGBUS signal. So we disable the mmap by default until we fix this issue.

portability: fix build on Solaris-derived systemd Current Illumos and older Solaris require _XOPEN_SOURCE for msg_control. O_DIRECTORY doesn't exist on older systems either, so fallback to O_RDONLY. It's good enough as a repository will require both R and X permission anyway.

mmap: only use mmap to read revlog persistent nodemap if it is safe Cf `is_mmap_safe` docstring.

mmap: fix another instance of reverse mmap logic in persistent nodemap This fix the same kind of issue as 85d96517e650

mmap: only use mmap to read rev-branch-cache data if it is safe Cf `is_mmap_safe` docstring.

mmap: only use mmap to read revlog index if it is safe Cf `is_mmap_safe` docstring.

mmap: add a `is_mmap_safe` method to vfs This will be useful to safeguard mmap usage to void SIGBUS when repositories lives on a NFS drive.

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.