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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 tip