Tue, 07 Nov 2023 16:59:37 +0100 Added signature for changeset 27055614b685 stable 6.6
Raphaël Gomès <rgomes@octobus.net> [Tue, 07 Nov 2023 16:59:37 +0100] rev 51128
Added signature for changeset 27055614b685
Tue, 07 Nov 2023 16:59:36 +0100 Added tag 6.6rc0 for changeset 27055614b685 stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 07 Nov 2023 16:59:36 +0100] rev 51127
Added tag 6.6rc0 for changeset 27055614b685
Tue, 07 Nov 2023 16:07:53 +0100 relnotes: add 6.6rc0 stable 6.6rc0
Raphaël Gomès <rgomes@octobus.net> [Tue, 07 Nov 2023 16:07:53 +0100] rev 51126
relnotes: add 6.6rc0
Tue, 07 Nov 2023 15:21:11 +0100 branching: merge default into stable for 6.6rc0 stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 07 Nov 2023 15:21:11 +0100] rev 51125
branching: merge default into stable for 6.6rc0
Mon, 06 Nov 2023 23:17:10 +0100 unstable: do not consider internal phases when computing unstable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Nov 2023 23:17:10 +0100] rev 51124
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.
Mon, 06 Nov 2023 23:15:58 +0100 unstable: use the `_mutablerevs` function when computing content divergent
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Nov 2023 23:15:58 +0100] rev 51123
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.
Mon, 06 Nov 2023 23:15:17 +0100 unstable: use the `_mutablerevs` function when computing phase divergent
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Nov 2023 23:15:17 +0100] rev 51122
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.
Mon, 06 Nov 2023 11:07:54 +0100 rust: add explicit resolver field to top-level cargo manifest file
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 11:07:54 +0100] rev 51121
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
Mon, 06 Nov 2023 11:06:08 +0100 rust: run a clippy pass with the latest stable version
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 11:06:08 +0100] rev 51120
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.
Mon, 06 Nov 2023 11:02:18 +0100 rust-clippy: ignore clippy's recommendation for "useless" cast
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 11:02:18 +0100] rev 51119
rust-clippy: ignore clippy's recommendation for "useless" cast See explanation inline.
Mon, 06 Nov 2023 17:12:04 +0100 branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 17:12:04 +0100] rev 51118
branching: merge stable into default
Mon, 06 Nov 2023 15:38:27 +0100 Added signature for changeset c083d9776cb2 stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 15:38:27 +0100] rev 51117
Added signature for changeset c083d9776cb2
Mon, 06 Nov 2023 15:38:15 +0100 Added tag 6.5.3 for changeset c083d9776cb2 stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 15:38:15 +0100] rev 51116
Added tag 6.5.3 for changeset c083d9776cb2
Mon, 06 Nov 2023 15:32:30 +0100 relnotes: add 6.5.3 stable 6.5.3
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 Nov 2023 15:32:30 +0100] rev 51115
relnotes: add 6.5.3
Sat, 14 Oct 2023 03:24:13 +0200 revlog: avoid opening and closing the file for each cloned revision stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 14 Oct 2023 03:24:13 +0200] rev 51114
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.
Fri, 13 Oct 2023 23:21:46 +0200 censor: accept censored revision during upgrade stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Oct 2023 23:21:46 +0200] rev 51113
censor: accept censored revision during upgrade They can simply be passed by as censored.
Fri, 13 Oct 2023 22:40:10 +0200 censor: show that censored revision prevent repository upgrade stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Oct 2023 22:40:10 +0200] rev 51112
censor: show that censored revision prevent repository upgrade This is not great.
Tue, 31 Oct 2023 22:42:46 -0700 smartset: don't ignore hidden revs when intersecting
Martin von Zweigbergk <martinvonz@google.com> [Tue, 31 Oct 2023 22:42:46 -0700] rev 51111
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.
Tue, 31 Oct 2023 22:33:45 -0700 tests: demonstrate crash in `unstable()` with internal-phase orphans
Martin von Zweigbergk <martinvonz@google.com> [Tue, 31 Oct 2023 22:33:45 -0700] rev 51110
tests: demonstrate crash in `unstable()` with internal-phase orphans
Wed, 18 Oct 2023 14:50:14 +0200 rust-matchers: fix quadratic complexity in `FileMatcher`
Raphaël Gomès <rgomes@octobus.net> [Wed, 18 Oct 2023 14:50:14 +0200] rev 51109
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.
Fri, 27 Oct 2023 08:54:41 +0200 revlog: add a small cache of unfiltered chunk
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 27 Oct 2023 08:54:41 +0200] rev 51108
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.
Fri, 27 Oct 2023 02:57:09 +0200 revlog: minor refactor in the chunk gather process
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 27 Oct 2023 02:57:09 +0200] rev 51107
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).
Tue, 24 Oct 2023 11:08:49 +0200 changelog-delay: move the delay/divert logic inside the (inner) revlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 24 Oct 2023 11:08:49 +0200] rev 51106
changelog-delay: move the delay/divert logic inside the (inner) revlog Instead of hacking throught the vfs/opener, we implement the delay/divert logic inside the `_InnerRevlog` and `randomaccessfile` object. This will allow to an alternative implementation of the `_InnerRevlog` that does not need to use Python details. As a result, the new implementation can use the transaction less agressively and avoid some extra output since no data had been written yet. That seems like a good side effect.
Thu, 26 Oct 2023 05:37:37 +0200 revlog: add a `canonical_index_file` attribute on inner revlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Oct 2023 05:37:37 +0200] rev 51105
revlog: add a `canonical_index_file` attribute on inner revlog This is currently the same and the index_file but it will become more complex when we start doing delayed write.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 tip