Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 11:04:56 +0100] rev 51409
phases: type annotation for `_phasesets`
Does not hurt.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 23:46:21 +0100] rev 51408
phases: leverage the collected information to record phase update
Since the lower level function already gather this information, we can directly
use it.
This comes with a small change to the test that are actually fixing them. The
previous version over-reported some phase change that did not exists. In both
case, we are force revision `1` to be secret and `0` remains draft`, the
previous code wrongly reported `0` as moving to secret while it properly
remained draft in the repository.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 10:41:09 +0100] rev 51407
phases: large rewrite on retract boundary
The new code is still pure Python, so we still have room to going significantly
faster. However its complexity of the complex part is `O(|[min_new_draft, tip]|)` instead of
`O(|[min_draft, tip]|` which should help tremendously one repository with old
draft (like mercurial-devel or mozilla-try).
This is especially useful as the most common "retract boundary" operation
happens when we commit/rewrite new drafts or when we push new draft to a
non-publishing server. In this case, the smallest new_revs is very close to the
tip and there is very few work to do.
A few smaller optimisation could be done for these cases and will be introduced in
later changesets.
We still have iterate over large sets of roots, but this is already a great
improvement for a very small amount of work. We gather information on the
affected changeset as we go as we can put it to use in the next changesets.
This extra data collection might slowdown the `register_new` case a bit, however
for register_new, it should not really matters. The set of new nodes is either
small, so the impact is negligible, or the set of new nodes is large, and the
amount of work to do to had them will dominate the overhead the collecting
information in `changed_revs`.
As this new code compute the changes on the fly, it unlock other interesting
improvement to be done in later changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 15:49:21 +0100] rev 51406
phases: fast path public phase advance when everything is public
Everything is already public, so we have nothing to do here.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 15:24:22 +0100] rev 51405
phases: fast path retract of public phase
There are no boundary to retract, so lets do nothing.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 21:40:13 +0100] rev 51404
phases: keep internal state as rev-num instead of node-id
Node-id are expensive to work with, dealing with revision is much simple and
faster.
The fact we still used node-id here shows how few effort have been put into
making the phase logic fast. We tend to no longer use node-id internally for
about ten years.
This has a large impact of repository with many draft roots. For example this
Mozilla-try copy have ½ Million draft roots and `perf::unbundle` see a
significant improvement.
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.perf.perf-unbundle
# bin-env-vars.hg.flavor = no-rust
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.issue6528 = disabled
# benchmark.variants.revs = last-1
before:: 1.746791 seconds
after:: 1.278379 seconds (-26.82%)
# benchmark.variants.revs = last-10
before:: 3.145774 seconds
after:: 2.103735 seconds (-33.13%)
# benchmark.variants.revs = last-100
before:: 3.487635 seconds
after:: 2.446749 seconds (-29.85%)
# benchmark.variants.revs = last-1000
before:: 5.007568 seconds
after:: 3.989923 seconds (-20.32%)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 21:40:08 +0100] rev 51403
phases: do filtering at read time
This remove the need for the `filterunknown` method at all.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 21:38:01 +0100] rev 51402
phases: always write with a repo
In the future change that move the internal representation of phase-roots from
node-id to rev-num, we will use a repository to translate revision numbers back
to node at write time.
Since that future change is quite complicated already, we do this small API
change beforehand.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 17:18:15 +0100] rev 51401
phases: mark `phasecache.phaseroots` private
We are about to change its content from nodeid to revnum. So anyone directly
using the content might be in unexpected troubles. We start by making it private
to explicitly break any such user (and discourage them to do so).
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 17:17:54 +0100] rev 51400
phases: check secret presence the right way during discovery
There is an official function for this, lets use it.
This will prevent the code to break in the future while we refactor the phase
code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 20 Feb 2024 14:21:18 +0100] rev 51399
phases: explicitly filter stripped revision at strip time
Explicit is better than implicit. The current logic is bit subtle and fragile.
It also get in the way of using something else than node-id as internal storage.
We replace it with a more explicit filtering while striping.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 04:26:03 +0100] rev 51398
debug: add a debug::unbundle command that simulate the unbundle from a push
The code have different behavior when the unbundle comes from a push, so we
introduce a command that can simulate such unbundle.
For our copy of mozilla-try-2023-03-22, this make the unbundle jump from 2.5
seconds (with `hg unbundle`) to 15 seconds (with `hg debug::unbundle`).
That 15 seconds timings is consistent with the issue seen in production.
Zeger Van de Vannet <zeger@vandevan.net> [Wed, 14 Feb 2024 08:14:46 +0100] rev 51397
annotate: limit output to range of lines
Arseniy Alekseyev <aalekseyev@janestreet.com> [Mon, 12 Feb 2024 20:01:27 +0000] rev 51396
revlog: add a Rust implementation of `headrevsdiff`
Python implementation of `headrevsdiff` can be very slow in the worst
case compared with the `heads` computation it replaces, since the
latter is done in Rust.
Even the average case of this Python implementation is still
noticeable in the profiles.
This patch makes the computation much much faster by doing it in Rust.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 21 Dec 2023 20:30:03 +0000] rev 51395
revlog: add a C implementation of `headrevsdiff`
Python implementation of `headrevsdiff` can be very slow in the worst
case compared with the `heads` computation it replaces, since the
latter is done in C.
Even the average case of this Python implementation is still
noticeable in the profiles.
This patch makes the computation much much faster by doing it in C.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 21 Dec 2023 17:38:04 +0000] rev 51394
unbundle: faster computation of changed heads
To compute the set of changed heads it's sufficient to look at the recent commits,
instead of looking at all heads currently in existence.
Raphaël Gomès <rgomes@octobus.net> [Wed, 21 Feb 2024 11:53:30 +0100] rev 51393
branching: merge stable into default
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Tue, 20 Feb 2024 10:47:47 -0500] rev 51392
hg-core: separate timestamp and extra methods
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Thu, 15 Feb 2024 11:39:18 -0500] rev 51391
hg-core: implement timestamp line parsing
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 15:21:44 -0500] rev 51390
doc: document that labels must have a dot in them to have an effect
I noticed that the `hg topics` template has a bare `topic` label with
no dot, and that makes it useless, as such a label will never receive
any effect by the colour extension.
This dot has been required for a long time, at least since 2011, but
we never formally documented it!
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:55:11 -0500] rev 51389
crecord: enable search hotkeys (issue6834)
The keys I chose here should be similar to less/vim keybindings, which
should fit the overall keybinding theme of crecord.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:54:21 -0500] rev 51388
crecord: add handle(next|prev)search functions
These are now just simple wrappers around `searchdirection`
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:53:58 -0500] rev 51387
crecord: add a searchdirection function
If a regex has already been previously set, this function handles the
UI elements of searching again forward or backward.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:50:00 -0500] rev 51386
crecord: add a handlesearch function
This function sets up some of the UI, such as getting the search
string from the user and displaying results or their absence.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:48:09 -0500] rev 51385
crecord: add a showsearch function
This function takes a regex and searches either forward or backward,
moving the current item to the found item, if any, and unfolding the relevant context.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:46:41 -0500] rev 51384
crecord: add a default regex to curseschunkselector
Whether there is a regex to search or not will affect if we can find
the next or the previous search hit.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:43:51 -0500] rev 51383
crecord: add `content` properties to all nodes
In order to have a unified API of what can be searched, let's provide
a `content` property to each node type. This way we can search
filenames, context headers (e.g. containing function names, if
deducible from patch context) or changed lines themselves.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:42:08 -0500] rev 51382
crecord: update uiheader docstring
There's no need to move anything to patch.py. The uiheader class only
has methods relevant to crecord and overrides __getattr__ in order to
use `patch.header` objects as a sort of mixin.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:40:47 -0500] rev 51381
crecord: add skipfolded param to previtem
This just simplifies the API a bit so it matches `nextitem` and I
can handle both nextitem and previtem symmetrically.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 15:23:59 -0500] rev 51380
dispatch: don't attempt to import debugger as bytestring
The __import__ thingie needs a string, not a bytestring. Guess I'm the
only one who uses this once in a while and noticed it was broken.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 11:53:04 -0500] rev 51379
debugsetparents: fix Marmoutian docstring
Just some light proofreading.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 13 Feb 2024 11:49:55 -0800] rev 51378
docs: fix broken `make` in `docs/`
We had some wrapped lines without blank lines between, which made the runrst
script think the list was not a list and it got confused about the
indentation. I added blank lines, and also some other minor styling for
consistency with the rest of the file.