cleanup: drop `path.pushloc` deprecated since 6.5 This was scheduled for removal, let us remove it.

cleanup: drop `dirstate.is_changing_parent` deprecated since 6.5 This was scheduled for removal, let us remove it.

cleanup: remove some code scheduled to be removed after 5.9 looks like we missed this when cleaning up previous code.

branching: merge stable into default

relnotes: add 6.6 There are no differences between the rc and the actual release.

Added signature for changeset 26c57e7a0890

Added tag 6.6 for changeset 26c57e7a0890

py3: pass unicode strings to hasattr() throughout I guess we missed these instances because they're not covered by tests.

Added signature for changeset 27055614b685

Added tag 6.6rc0 for changeset 27055614b685

relnotes: add 6.6rc0

branching: merge default into stable for 6.6rc0

unstable: do not consider internal phases when computing unstable The revisions that are not part of the "working" set by other means should not be considered for the evolution related computation. This impact the test introduced in 5f9af8422b31 as this is actually a more semantic fix of the issue.

unstable: use the `_mutablerevs` function when computing content divergent This is a useful function to get the revision relevant to these computation, lets make sure all code use it, so that we can improve that `_mutablerevs` function in a later changeset.

unstable: use the `_mutablerevs` function when computing phase divergent This is a useful function to get the revision relevant to these computation, lets make sure all code use it, so that we can improve that `_mutablerevs` function in a later changeset.

rust: add explicit resolver field to top-level cargo manifest file Since Rust 1.51.0, Cargo has support for a better dependency resolver. Workspace packages (like ours) need to explicitely set the field, so let's. https://doc.rust-lang.org/edition-guide/rust-2021/default-cargo-resolver.html

rust: run a clippy pass with the latest stable version Our current version of clippy is older than the latest stable. The newest version has new lints that are moslty good advice, so let's apply them ahead of time. This has the added benefit of reducing the noise for developpers like myself that use clippy as an IDE helper, as well as being more prepared for a future clippy upgrade.

rust-clippy: ignore clippy's recommendation for "useless" cast See explanation inline.

branching: merge stable into default

Added signature for changeset c083d9776cb2

Added tag 6.5.3 for changeset c083d9776cb2

relnotes: add 6.5.3

revlog: avoid opening and closing the file for each cloned revision The previous code was flushing files after each new revision, slowing things down. For exemple, with this change, the evolve repository can run `hg debugupgraderepo --run --optimize re-delta-parent` in about 3.4s instead of 4.5 seconds.

censor: accept censored revision during upgrade They can simply be passed by as censored.

censor: show that censored revision prevent repository upgrade This is not great.

smartset: don't ignore hidden revs when intersecting This fixes the bug I demonstrated in the previous commit, but I'm not sure at all if it's the right way of doing it.

tests: demonstrate crash in `unstable()` with internal-phase orphans

rust-matchers: fix quadratic complexity in `FileMatcher` Concretely, this command: ``` $ echo hg up -r <nodeid>; time hg revert dir1 dir2 -r <othernode> --debug hg up -r <nodeid> real 0m14.690s user 0m14.766s sys 0m5.430s ``` was much slower despite using 16 cores before this change. The approach taken here is the same one used in match.py, in exactmatcher. This changeset was originally written by Valentin Gatien-Baron in a private repository. I have redacted the commit message and did a minor clean up of the code.

revlog: add a small cache of unfiltered chunk This can provides a massive boost to the reading of multiple revision and the computation of a valid delta chain. This greatly help operation like `hg log --patch`, delta computation (helping pull/unbundle), linkrev adjustment (helping copy tracing). A first round of benchmark for `hg log --patch --limit 1000` shows improvement in the 10-20% range on "small" repository like pypy or mercurial and large improvements (about 33%) for more complex ones like netbeans and mozilla's. These speeds up are consistent with the improvement to `hg pull` (from a server sending poor deltas) I saw benchmarking this last year. Further benchmark will be run during the freeze. I added some configuration in the experimental space to be able to further test the effect of various tuning for now. This feature should fit well in the "usage/resource profile" configuration that we should land next cycle. When it does not provides a benefit the overhead of the cache seem to be around 2%, a small price for the big improvement. In addition I believe we could shave most of this overhead with a more efficent lru implementation.

revlog: minor refactor in the chunk gather process We will introduce some caching in this method in the next changeset, we make some of the most "disruptive" change first as touching this could break (and maybe did during the development process).