Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 17:51:21 +0200] rev 51620
relnotes: add 6.7.3
Georges Racinet <georges.racinet@octobus.net> [Mon, 22 Apr 2024 19:47:08 +0200] rev 51619
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.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 15:30:21 +0200] rev 51618
rust-cpython: don't swallow the dirstate error message
In case we do get a dirstate error, we want to get the full error message and
not just an opaque `Dirstate error`.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 13:07:02 +0200] rev 51617
dirstate-v2: check that root nodes are at the root before writing
More explanations in the previous changeset.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 13:02:52 +0200] rev 51616
dirstate-v2: add check of parent/child nodes being related when writing
This stems from a corruption seen in a private repository. We're not sure
of the source of the corruption, and it's very possible that we're seeing
compounded effects of multiple writes on a corrupted dirstate.
Adding this check is not expensive in itself and large writes of the dirstate
are not common.
This change does not catch this problem at the root node, the next one will.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 16:29:00 +0200] rev 51615
admin-verify: expect a number of errors to be returned
It's the responsibility of the check to handle errors, we only care about
the total count to sum up the check's work.
We use `admin::verify -c dirstate` to test this path at least somewhat.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 16:16:15 +0200] rev 51614
admin-verify: fix error message handling
`dirstate.verify` used to return tuples but does not anymore, it returns
the pre-formatted error message, which is a nicer interface anyway.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 12:31:29 +0200] rev 51613
admin-verify: pass p1 down to the dirstate function
This was forgotten and can break with certain kinds of corruption.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 11:27:29 +0200] rev 51612
Backed out changeset
3e0f86f09f26
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 11:26:52 +0200] rev 51611
Backed out changeset
fc317bd5b637
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 May 2024 02:20:42 +0200] rev 51610
re2: make errors quiet
By default, the re2 library will output error on its own instead of keeping the
error in an exception. This make re2 printing spurious error before fallback to
the stdlib remodule that may accept the pattern or also fails to parse it and
raise a proper error that will be handled by Mercurial.
So we also pass an Option object that changes this default.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 02 May 2024 08:46:58 +0200] rev 51609
fold-or-prune-me: update proposal
This does the same things but with a narrower wrapping.
Felipe Resende <felipe@fcresende.dev.br> [Sun, 31 Mar 2024 17:57:46 -0300] rev 51608
subrepo: propagate non-default path on outgoing
There was already a fix made in
5dbff89cf107 for pull and push commands. I did
the same for the outgoing command.
The problem I identified is that when the parent repository has multiple paths,
the outgoing command was not respecting the parent path used and was always
using the default path for subrepositories.
Hraban Luyat <hraban@0brg.net> [Tue, 26 Mar 2024 01:27:27 -0400] rev 51607
hgrc: search XDG_CONFIG_HOME on mac
Searching for hgrc was special cased not to look through ~/.config/hg on Mac,
but that’s unnecessary: Macs support it as do other unix based systems. There
are plenty tools that use it there, e.g. git, and people expect it to work, e.g.
"https://stackoverflow.com/questions/
72499837/mercurial-on-macos-doesnt-read-config-hg-hgrc".
Initial code introduced in
354020079723.
Raphaël Gomès <rgomes@octobus.net> [Tue, 16 Apr 2024 09:51:11 +0200] rev 51606
base-revsets: use an author that actually exercises a lot of changesets
This was caught in my big find-and-replace:
d4ba4d51f85f.
The point of `base-revsets` is to give revsets that will give a good coverage
of the repository. Using Pierre-Yves as the second largest committer
(in terms of number of changesets) seems like a good idea.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 16 Apr 2024 17:21:37 +0100] rev 51605
match: simplify the rust-side file pattern kind parsing
There's no need to add the ':' characters if
we're simply pattern matching against constants next.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 16 Apr 2024 13:51:45 +0100] rev 51604
match: share code between includematcher and patternmatcher
No need to have this duplication.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 05 Apr 2024 17:57:26 +0100] rev 51603
matchers: support patternmatcher in rust
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 09 Apr 2024 11:12:24 +0100] rev 51602
match: avoid rust fast path if the matcher was tampered with
Otherwise the fast path does not respect the modifications made
by the extension (concretely largefiles, but other extensions can
start using that too)
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 09 Apr 2024 11:00:52 +0100] rev 51601
largefiles: track if a matcher was tampered with
This is used to make sure rust fast path is not taken for the
modified matchers.
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Apr 2024 12:28:48 +0200] rev 51600
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Mar 2024 12:02:06 +0100] rev 51599
tags-cache: directly perform a monimal walk for hgtagsfnodescache warming
We do something narrower than the path retrieving data. So lets use dedicated
code instead.
This provides further useful speedup:
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.debug.debug-update-cache
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.pre-state = warm
before-this-series: 19.947581
skip-fnode-filter: 18.916804 (-5.17%, -1.03)
use-rev-num: 17.493725 (-12.30%, -2.45)
this-changesets: 15.919466 (-20.19%, -4.03)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Mar 2024 11:51:11 +0100] rev 51598
tags-cache: directly operate on rev-num warming hgtagsfnodescache
Not having to goes through nodeid speed up things notably.
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.debug.debug-update-cache
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.pre-state = warm
before-this-series: 19.947581
before-this-changes: 18.916804 (-5.17%, -1.03)
this-changesets: 17.493725 (-12.30%, -2.45)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Mar 2024 11:38:28 +0100] rev 51597
tags-cache: skip the filternode step if we are not going to use it
When warming the hgtagsfnodescache, we don't need the actual result, so we can
simply skip the part that "filter" fnode we read from the cache. So provide a
quite visible speed up to the top level `hg debugupdatecache` function.
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.debug.debug-update-cache
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.pre-state = warm
before: 19.947581
after: 18.916804 (-5.17%, -1.03)