Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 19:10:35 +0100] rev 51626
dirstate: remove the python-side whitelist of allowed matchers
This whitelist is too permissive because it allows matchers that contain
disallowed ones deep inside, for example through `intersectionmatcher`.
It is also too restrictive because it doesn't pass through
some of the matchers we support, such as `patternmatcher`.
It's also unnecessary because unsupported matchers raise
`FallbackError` and we fall back anyway.
Making this change makes more of the tests use rust code path,
and therefore subtly change behavior. For example, rust status
in largefiles repos seems to have strange behavior.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 18:53:02 +0100] rev 51625
match: make `was_tampered_with` work recursively
This is useful if we are to use it outside of Rust, when
deciding whether or not to do some fast-path operation with
a given matcher.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 26 Apr 2024 19:43:42 +0100] rev 51624
largefiles: mark more matchers as having been tampered with
These happened to slip through the cracks earlier because they
weren't caught by tests. Now that we're enabling rust fast path
more widely these start breaking.
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:50:21 +0200] rev 51623
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:37 +0200] rev 51622
Added signature for changeset 028dc3f92dbd
Raphaël Gomès <rgomes@octobus.net> [Mon, 06 May 2024 18:48:34 +0200] rev 51621
Added tag 6.7.3 for changeset 028dc3f92dbd
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)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Mar 2024 11:34:21 +0100] rev 51596
tags-cache: add a dedicated warm cache function to hgtagsfnodescache
Having a dedicated API point will help to optimize that specific usage. Right
doing a full phases weam takes a long time, even when the cache is already
filled.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 22:37:15 +0200] rev 51595
outgoing: add a simple fastpath when there is no common
This further speed up case like `hg bundle --all` for larger repository.
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.command.bundle
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.revs = all
# benchmark.variants.type = none-streamv2
before: 316.749699
after: 311.165461 (-1.76%, -5.58)
There is further work to be done in this area like not doing any outgoing
computation in the stream case for example. however the recent changes already
gives use a large win for a small amount of local work.
### benchmark.name = hg.command.bundle
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.revs = all
# benchmark.variants.type = none-streamv2
## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog
pre-%ln-change: 1.263859
the-%ln-change: 0.700229 (-44.60%, -0.56)
prev-changeset: 0.496050 (-60.75%, -0.77)
this-changeset: 0.495243 (-60.81%, -0.77)
## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog
pre-%ln-change: 2.975765
the-%ln-change: 1.870798 (-37.13%, -1.10)
prev-changeset: 1.461583 (-50.88%, -1.51)
this-changeset: 1.469185 (-50.63%, -1.51)
## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
pre-%ln-change: 4.540080
the-%ln-change: 3.401700 (-25.07%, -1.14)
prev-changeset: 2.915810 (-35.78%, -1.62)
this-changeset: 2.911643 (-35.87%, -1.63)
## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog
pre-%ln-change: 10.138396
the-%ln-change: 7.750458 (-23.55%, -2.39)
prev-changeset: 6.665565 (-34.25%, -3.47)
this-changeset: 6.672078 (-34.19%, -3.47)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
pre-%ln-change: 399.484481
the-%ln-change: 346.508952 (-13.26%, -52.98)
prev-changeset: 316.749699 (-20.71%, -82.73)
this-changeset: 311.165461 (-22.11%, -88.32)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 22:36:35 +0200] rev 51594
outgoing: rework the handling of the `missingroots` case to be faster
The previous implementation was slow, to the point it was taking a significant
amount of `hg bundle --type none-streamv2` call. We rework the code to compute
the same value much faster, making the operation disappear from the `hg bundle
--type none-streamv2` profile. Someone would remark that producing a streamclone
does not requires an `outgoing` object. However that is a matter for another
day. There is other user of `missingroots` (non stream `hg bundle` call for
example), and they will also benefit from this rework.
We implement an old TODO in the process, directly computing the missing and
common attribute as we have most element at hand already.
### benchmark.name = hg.command.bundle
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.revs = all
# benchmark.variants.type = none-streamv2
## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog
before: 7.750458
after: 6.665565 (-14.00%, -1.08)
## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog
before: 0.700229
after: 0.496050 (-29.16%, -0.20)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
before: 346.508952
after: 316.749699 (-8.59%, -29.76)
## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
before: 3.401700
after: 2.915810 (-14.28%, -0.49)
## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog
before: 1.870798
after: 1.461583 (-21.87%, -0.41)
note: this whole `missingroots` of outgoing has a limited number of callers and
could likely be replace by something simpler (like taking an explicit
"missing_revs" set for example). However this is a wider change and we focus on
a small impact, quick rework that does not change the API for now.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:27:10 +0200] rev 51593
proxy-vfs: also proxy the `audit` attribute
In the previous changeset, we had to do a little dance to access the useful
`audit` attribute. We now provide a proper accessors to it.
We don't update the code in `perf.py` because it has to remain compatible with
older version of Mercurial. This will just be nicer in the future.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Apr 2024 23:40:28 +0200] rev 51592
perf: clear vfs audit_cache before each run
When generating a stream clone, we spend a large amount of time auditing path.
Before this changes, the first run was warming the vfs cache for the other
runs, leading to a large runtime difference and a "faulty" reported timing for
the operation.
We now clear this important cache between run to get a more realistic timing.
Below are some example of median time change when clearing these cases. The
maximum time for a run did not changed significantly.
### data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog
# benchmark.name = hg.perf.exchange.stream.generate
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.version = latest
no-clearing: 17.289905
cache-clearing: 21.587965 (+24.86%, +4.30)
## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog
no-clearing: 32.670748
cache-clearing: 40.467095 (+23.86%, +7.80)
## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog
no-clearing: 37.838858
cache-clearing: 46.072749 (+21.76%, +8.23)
## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog
no-clearing: 32.969395
cache-clearing: 39.646209 (+20.25%, +6.68)
In addition, this significantly reduce the timing difference between the
performance command, from the perf extensions and a `real `hg bundle` call
producing a stream bundle. Some significant differences remain especially on
the "mozilla-try" repositories, but they are now smaller.
Note that some of that difference will actually not be
attributable to the stream generation (like maybe phases or branch map
computation).
Below are some benchmarks done on a currently draft changeset fixing some
unrelated slowness in `hg bundle` (34a78972af409d1ff37c29e60f6ca811ad1a457d)
### data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
hg.perf.exchange.stream.generate: 21.587965
hg.command.bundle: 24.301799 (+12.57%, +2.71)
## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog
hg.perf.exchange.stream.generate: 40.467095
hg.command.bundle: 44.831317 (+10.78%, +4.36)
## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog
hg.perf.exchange.stream.generate: 39.646209
hg.command.bundle: 45.395258 (+14.50%, +5.75)
## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog
hg.perf.exchange.stream.generate: 46.072749
hg.command.bundle: 55.882608 (+21.29%, +9.81)
## data-env-vars.name = mozilla-try-2023-03-22-zlib-general-delta
hg.perf.exchange.stream.generate: 334.716708
hg.command.bundle: 377.856767 (+12.89%, +43.14)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
hg.perf.exchange.stream.generate: 302.972301
hg.command.bundle: 326.098755 (+7.63%, +23.13)
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:41:36 +0200] rev 51591
perf: start recording total time after warming
The warming might be costly and this should not affect the "time profile" of the
actual collection.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:40:15 +0200] rev 51590
perf: run the gc before each run
The python garbage collector is a large source of performance troubles, we run
it right before the timed section to reduce the change for the gc to add noise
to the benchmark.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:38:41 +0200] rev 51589
perf: allow profiling of more than one run
By default, we still profile the first run only. However profiling more run help
to understand side effect from one run to the other. So we add an option to be
able to do so.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:36:55 +0200] rev 51588
profiler: flush after writing the profiler output
Otherwise, the profiler output might only partially appears until the next flush
of the buffer. Since profiling often happens for long operation, the next flush
can be a long time away.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Apr 2024 02:33:36 +0200] rev 51587
stream-clone: disable gc for the entry listing section for the v2 format
This is similar to the change we did for the v3 format in 6e4c8366c5ce.
The benchmark bellow show this gives us a notable gains, especially on larger
repositories.
### benchmark.name = hg.perf.stream-locked-section
# benchmark.name = hg.perf.stream-locked-section
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.version = v2
## data-env-vars.name = pypy-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 0.503820 ~~~~~
1106d1bf695e: 0.470078 (-6.70%, -0.03)
## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 0.535756 ~~~~~
1106d1bf695e: 0.490249 (-8.49%, -0.05)
## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog
5e931bf8707c: 1.327041 ~~~~~
1106d1bf695e: 1.174636 (-11.48%, -0.15)
## data-env-vars.name = netbeans-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 2.439158 ~~~~~
1106d1bf695e: 2.220515 (-8.96%, -0.22)
## data-env-vars.name = netbeans-2019-11-07-zstd-sparse-revlog
5e931bf8707c: 2.630794 ~~~~~
1106d1bf695e: 2.261473 (-14.04%, -0.37)
## data-env-vars.name = mozilla-central-2018-08-01-zstd-sparse-revlog
5e931bf8707c: 5.769002 ~~~~~
1106d1bf695e: 5.062000 (-12.26%, -0.71)
## data-env-vars.name = mozilla-try-2019-02-18-zstd-sparse-revlog
5e931bf8707c: 13.351750 ~~~~~
1106d1bf695e: 12.346655 (-7.53%, -1.01)
## data-env-vars.name = mozilla-central-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 10.772939 ~~~~~
1106d1bf695e: 9.495407 (-11.86%, -1.28)
## data-env-vars.name = mozilla-unified-2024-03-22-zstd-sparse-revlog
5e931bf8707c: 10.864297 ~~~~~
1106d1bf695e: 9.475597 (-12.78%, -1.39)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
5e931bf8707c: 17.448335 ~~~~~
1106d1bf695e: 16.027474 (-8.14%, -1.42)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 02:54:19 +0200] rev 51586
phases: rework the logic of _pushdiscoveryphase to bound complexity
This rework the various graph traversal in _pushdiscoveryphase to keep the
complexity in check.
This is done though a couple of things:
- first, limiting the space we have to explore, for example, if we are not in
publishing push, we don't need to consider remote draft roots that are also
draft locally, as there is nothing to be moved there.
- avoid unbounded descendant computation, and use the faster "rev between"
computation.
This provide a massive boost to performance when exchanging with repository with
a massive amount of draft, like mozilla-try:
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.command.push
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.explicit-rev = all-out-heads
# benchmark.variants.issue6528 = disabled
# benchmark.variants.protocol = ssh
# benchmark.variants.reuse-external-delta-parent = default
## benchmark.variants.revs = any-1-extra-rev
before: 20.346590 seconds
after: 11.232059 seconds (-38.15%, -7.48 seconds)
## benchmark.variants.revs = any-100-extra-rev
before: 24.752051 seconds
after: 15.367412 seconds (-37.91%, -9.38 seconds)
After this changes, the push operation is still quite too slow. Some of this
can be attributed to general phases slowness (reading all the roots from disk
for example) and other know slowness (not using persistent-nodemap, branchmap,
tags, etc. We are also working on them, but with this series, phase discovery
during push no longer showing up in profile and this is a pretty nice and bit
low-hanging fruit out of the way.
### (same case as the above)
# benchmark.variants.revs = any-1-extra-rev
pre-%ln-change: 44.235070
this-changeset: 11.232059 seconds (-74.61%, -33.00 seconds)
# benchmark.variants.revs = any-100-extra-rev
pre-%ln-change: 49.234697
this-changeset: 15.367412 seconds (-68.79%, -33.87 seconds)
Note that with this change, the `hg push` performance is now much closer to the
`hg pull` performance, even it still lagging behind a bit. (and the overall
performance are still too slow).
### data-env-vars.name = mozilla-try-2023-03-22-ds2-pnm
# benchmark.variants.explicit-rev = all-out-heads
# benchmark.variants.issue6528 = disabled
# benchmark.variants.protocol = ssh
# benchmark.variants.pulled-delta-reuse-policy = default
# bin-env-vars.hg.flavor = rust
## benchmark.variants.revs = any-1-extra-rev
hg.command.pull: 6.517450
hg.command.push: 11.219888
## benchmark.variants.revs = any-100-extra-rev
hg.command.pull: 10.160991
hg.command.push: 14.251107
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.explicit-rev = all-out-heads
# benchmark.variants.issue6528 = disabled
# benchmark.variants.protocol = ssh
# benchmark.variants.pulled-delta-reuse-policy = default
## bin-env-vars.hg.flavor = default
## benchmark.variants.revs = any-1-extra-rev
hg.command.pull: 8.577772
hg.command.push: 11.232059
## bin-env-vars.hg.flavor = default
## benchmark.variants.revs = any-100-extra-rev
hg.command.pull: 13.152976
hg.command.push: 15.367412
## bin-env-vars.hg.flavor = rust
## benchmark.variants.revs = any-1-extra-rev
hg.command.pull: 8.731982
hg.command.push: 11.178751
## bin-env-vars.hg.flavor = rust
## benchmark.variants.revs = any-100-extra-rev
hg.command.pull: 13.184236
hg.command.push: 15.620843
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 22:47:44 +0200] rev 51585
phases: introduce a performant efficient way to access revision in a set
This will be useful in the next changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 14:13:47 +0200] rev 51584
phases: use revision number in `_pushdiscoveryphase`
We now reach our target checkpoint in terms of rev-num conversion. The
`_pushdiscoveryphase` function is now performing graph computation based on
revision number only. Avoiding repeated conversion from node-id to rev-num.
See previous changeset updated `new_heads` for rationnal.
Again, time saved in the 100 milliseconds order of magnitude for the mozilla-try
benchmark I have been using.
However, wow that the logic is done using revision number, we can look into having
better logic in the next changesets, which will provide a much bigger speedup.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 14:11:02 +0200] rev 51583
phases: move RemotePhasesSummary to revision number
This continue our quest to align more logic on revision number instead of
node-ids. The motivation is similar to the change to `new_heads` and
`analyze_remote_phases` a few changeset earlier.
Again, we take this as an opportunity to rename the class, and the attribute to
the new naming scheme. This will highlight the need for code update for any
code using it an expecting node-ids.
Many of the rev-num → node-id conversion we had to introduce in the previous
changesets can now be removed. More will be removed in the future as we continue
to align code toward rev-num usage.
time saved in the 100 milliseconds order of magnitude for the mozilla-try
benchmark I have been using.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 12:24:47 +0200] rev 51582
phases: stop using `repo.set` in `remotephasessummary`
The `repository.set` create changectx on the fly, an expensive operation. Using
`repo.revs` and a direct rev-num → node-id translation will be significantly
faster.
This is especially true as we prepare ourself to no longer do the rev-num →
node-id transalation there.
The speedup is a bit lost in the overall noisyness of the slow phase discovery algorithm, but it save a small amount of time in my benchmark.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 12:02:43 +0200] rev 51581
phases: use revision number in analyze_remote_phases
Same logic as the previous change to `new_heads`, see rationnal there.
This avoids a small number of `nodes -> revs` conversion speeding thing up in
the 100 milliseconds order of magnitude for the worses cases. However, the rest
of the logic is noisy enough that it hardly matters for now.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 11:33:47 +0200] rev 51580
phases: use revision number in new_heads
All graph operations will be done using revision numbers, so passing nodes only
means they will eventually get converted to revision numbers internally.
As part of an effort to align the code on using revision number we make the
`phases.newheads` function operated on revision number, taking them as input
and using them in returns, instead of the node-id it used to consume and
produce.
This is part of multiple changesets effort to translate more part of the logic,
but is done step by step to facilitate the identification of issue that might
arise in mercurial core and extensions.
To make the change simpler to handle for third party extensions, we also rename
the function, using a more modern form. This will help detecting the different
between the node-id version and the rev-num version.
I also take this as an opportunity to add some comment about possible
performance improvement for the future. They don't matter too much now, but they
are worse exploring in a while.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 08 Apr 2024 15:11:49 +0200] rev 51579
phases: convert remote phase root to node while reading them
This is currently a bit silly as we will convert them back to node right after,
but that is an intermediate step before doing more disruptive changes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 11:17:25 +0200] rev 51578
phases: more compact error handling in analyzeremotephases
using an intermediate variable result in more readable code, so let us use it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 02:54:12 +0200] rev 51577
push: rework the computation of fallbackheads to be correct
The previous computation tried to be smart but ended up being wrong. This was
caught by phase movement test while reworking the phase discovery logic to be
faster.
The previous logic was failing to catch case where the pushed set was not based
on a common heads (i.e. when the discovery seemed to have "over discovered"
content, outside the pushed set)
In the following graph, `e` is a common head and we `hg push -r f`. We need to
detect `c` as a fallback heads and we previous failed to do so::
e
|
d f
|/
c
|
b
|
a
The performance impact of the change seems minimal. On the most impacted
repository at hand (mozilla-try), the slowdown seems mostly mixed in the
overall noise `hg push` but seems to be in the hundred of milliseconds order of
magnitude. When using rust, we seems to be a bit faster, probably because we
leverage more accelaratd internals.
I added a couple of performance related common for further investigation later
on.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 11:05:54 +0200] rev 51576
revset: stop serializing node when using "%ln"
Turning hundred of thousand of node from node to hex and back can be slow… what
about we stop doing it?
In many case were we are using node id we should be using revision id. However
this is not a good reason to have a stupidly slow implementation of "%ln".
This caught my attention again because the phase discovery during push make an
extensive use of "%ln" or huge set. In absolute, that phase discovery probably
should use "%ld" and need to improves its algorithmic complexity, but improving
"%ln" seems simple and long overdue. This greatly speeds up `hg push` on
repository with many drafts.
Here are some relevant poulpe benchmarks:
### data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
# benchmark.name = hg.command.push
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.explicit-rev = all-out-heads
# benchmark.variants.issue6528 = disabled
# benchmark.variants.protocol = ssh
# benchmark.variants.reuse-external-delta-parent = default
## benchmark.variants.revs = any-1-extra-rev
before: 44.235070
after: 20.416329 (-53.85%, -23.82)
## benchmark.variants.revs = any-100-extra-rev
before: 49.234697
after: 26.519829 (-46.14%, -22.71)
### benchmark.name = hg.command.bundle
# bin-env-vars.hg.flavor = default
# bin-env-vars.hg.py-re2-module = default
# benchmark.variants.revs = all
# benchmark.variants.type = none-streamv2
## data-env-vars.name = heptapod-public-2024-03-25-zstd-sparse-revlog
before: 10.138396
after: 7.750458 (-23.55%, -2.39)
## data-env-vars.name = mercurial-public-2024-03-22-zstd-sparse-revlog
before: 1.263859
after: 0.700229 (-44.60%, -0.56)
## data-env-vars.name = mozilla-try-2023-03-22-zstd-sparse-revlog
before: 399.484481
after: 346.5089 (-13.26%, -52.98)
## data-env-vars.name = pypy-2024-03-22-zstd-sparse-revlog
before: 4.540080
after: 3.401700 (-25.07%, -1.14)
## data-env-vars.name = tryton-public-2024-03-22-zstd-sparse-revlog
before: 2.975765
after: 1.870798 (-37.13%, -1.10)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 14:41:48 +0200] rev 51575
bundlespec: drop unused _bundlespecvariants dictionary
Why do we have a `_bundlespecvariants`?
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 14:37:24 +0200] rev 51574
bundlespec: type the _bundlespeccontentopts dictionary
If only we had a tool to detect the kind of stupid error we just fixed… ho wait.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 Apr 2024 14:36:01 +0200] rev 51573
bundlespec: fix the "streamv2" and "streamv3-exp" variant
In c4aab3661f25, we broken this feature by adding unicode instead of bytes to
the dictionary.
On the other hand, this feature was never tested, so augment the tests to tests
this.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 04 Apr 2024 14:15:32 +0100] rev 51572
wireprotoserver: ensure that output stream gets flushed on exception
Previously flush was happening due to Python finalizer being run on
`BufferedWriter`. With upgrade to Python 3.11 this started randomly
failing.
My guess is that the finalizer on the raw `FileIO` object may
be running before the finalizer of `BufferedWriter` has a chance to run.
At any rate, since we're not relying on finalizers in the happy case
we should also not rely on them in case of exception.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Mon, 15 Apr 2024 16:33:37 +0100] rev 51571
match: strengthen visit_children_set invariant, Recursive means "all files"
My previous interpretation of "Recursive" was too relaxed: I thought it
instructed the caller to do something like this:
> you can stop calling `visit_children_set` because you'll need to descend into
> every directory recursively, but you should still check every file if it
> matches or not
Whereas the real instruction seems to be:
> I guarantee that everything in this subtree matches, you can stop
> querying the matcher for all files and dirs altogether.
The evidence to support this:
- the test actually passes with the stronger invariant, revealing no
exceptions from this rule
- the implementation of `visit_children_set` for `DifferenceMatcher`
clearly relies on this requirement, so it must hold for that not to
lead to bugs.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 16:09:45 +0100] rev 51570
match: fix the rust-side bug in visit_children_set for rootfilesin matchers
The fix is checked by `test_pattern_matcher_visit_children_set` test,
which is what caught the bug in the first place, but also by an end-to-end
test that I made for this purpose.
Accept the new results of Cargo tests
Many of these were already annotated with "FIXME", which is a good sign.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 15:39:21 +0100] rev 51569
match: fix the "visitdir" method on "rootfilesin" matchers
This fixes just the Python side, the fix for the rust side will follow shortly.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 14:21:14 +0100] rev 51568
match: rename RootFiles to RootFilesIn for more consistency
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 14:17:10 +0100] rev 51567
match: small tweak to PatternMatcher.visit_children_set
This makes it a bit more efficient (avoid a computation in case of early
return), and in my opinion clearer.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 14:09:55 +0100] rev 51566
matchers: fix the bug in rust PatternMatcher that made it cut off early
This brings the rust output in line with the Python output.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 12 Apr 2024 13:48:38 +0100] rev 51565
tests: add an end-to-end test to show a bug in `visit_children_set`
Concretely, `rootfilesin` is completely broken with respect to
`visit_children_set` optimization.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 11 Apr 2024 19:57:36 +0100] rev 51564
tests: add tests and document expectations from visit_children_set in rust
The tests this patch are adding have the form of formal spec in
invariants::visit_children_set::holds,
and then a series of checks that all examples must satisfy this
formal spec.
I tried to make the spec consistent with how this function is used
and how it was originally conceived. This is in conflict with how it's
documented in Rust. Some of the implementations also fail to implement
this spec, which leads to bugs, in particular when complicated patterns
are used with `hg status`.
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 11 Apr 2024 15:53:23 +0100] rev 51563
tests: add a test that demonstrates a bug in rhg status pattern handling
The bug is in [visit_children_set], will be elaborated on in
follow-up changes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Apr 2024 01:07:46 +0200] rev 51562
bundle-spec: properly parse boolean configuration as boolean
Before this changesets "v2;revbranchcache=no" would actually request the
addition for a revbranchcache part as the non-empty string `"0"` is `True`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 04 Apr 2024 16:41:43 +0200] rev 51561
bundle-spec: properly identify changegroup-less bundle
It is possible to produce a bundle without changegroup. For example if we want
to only send phases or obsolescence information. However that lead to crash for
command that identifies bundle content. So we fix that.
The test will come in the next changesets, when we fix another bug preventing to
generate such bundle by hand.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 Apr 2024 15:33:25 +0200] rev 51560
perf: create the temporary target next to the source in stream-consume
See inline comment for rational.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 03 Apr 2024 16:00:37 +0200] rev 51559
setup: display return code information about failed `hg` call
This help to understand what is going wrong when things goes wrong.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Apr 2024 21:53:17 +0200] rev 51558
bundlespec: rationalize the way we specify stream bundle version
Instead of having weird dedicated option for each version (v2, v3, etc) we
reuse the same "stream" parameters. This is consistent with the ability to
request a stream clone using "none-v2;stream=v2".
This changeset introduce no user visible change, this is pure internal cleaning.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 02 Apr 2024 17:02:39 +0200] rev 51557
bundle: do no check the changegroup version if no changegroup is included
We don't need to check the compatibility of something we will not use.
In practice this was getting in the was of `streamv2` bundles on a narrow
repository as the 'cg.version=02' value was rejected by this checks.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 18:51:33 +0000] rev 51556
perf-stream-consume: use the source repository config when applying
This might contains critical configuration for the benchmark, like enabling of
extensions like narrow.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:46:23 +0000] rev 51555
unbundle: move most of the logic on cmdutil to help debug::unbundle reuse
This make sure `hg debug::unbundle` focus on the core logic.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:29:48 +0000] rev 51554
postincoming: move to cmdutil
This looks like a good place for it to live.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Mar 2024 17:21:46 +0000] rev 51553
postincoming: avoid computing branchhead if no report will be posted
This otherwise defeat some of the branch v3 optimization.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:46:44 +0000] rev 51552
streamclone: stop listing files for entries that have no volatile files
This will save a lot of python related time.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
prev-change: 20.88 seconds (-40%)
prev-change: 14.22 seconds (-60%)
this-change: 11.58 seconds (-67% from baseline; -18% from prev)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:34:05 +0000] rev 51551
stream-clone: disable gc for the initial section for the v3 format
The number of small container created turn Python in a gc-frenzy that seriously
impact performance.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
prev-change: 20.88 seconds (-40%)
this-change: 14.22 seconds (-60% from baseline; -31% from prev)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:32:46 +0000] rev 51550
stream-clone: disable gc for `_entries_walk` duration
The number of small container created turn Python in a gc-frenzy that seriously
impact performance.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.04 seconds
prev-change: 24.51 seconds (-30%)
this-change: 20.88 seconds (-40% from baseline; -15% from previous changes)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 13:28:52 +0000] rev 51549
nocg: make the utility work are both a decorator and context manager
In some case, the context manager version will be simpler.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 11:24:20 +0000] rev 51548
stream-clone: stop getting the file size of all file in v3
The point of v3 is to do less work in the locked section. It was currently not
the case.
This significantly boost performance. The following number comes from a large
private repository using perf::stream-locked-section:
base-line: 35.03 seconds
this-change: 24.50 seconds (-30%)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 18:55:40 +0000] rev 51547
stream: in v3, skip the "size" fast path if the entries as some unknown size
We are about to prefetch size during the lock less in the v3 case. So we need to
avoid trying to use that prefetched size when it is not available.
See next changeset for the motivation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:43:20 +0000] rev 51546
perf-stream-locked-section: advertise the right version key in the help
As the v3 format is still experimental, its key is "v3-exp". The help text was
not pointing that out.
(we also fix `perf::stream-generate` in the process)
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:39:08 +0000] rev 51545
perf-stream-locked-section: fix the call to the v3 generator
That generator simply return chunks so we should not assign the return to a
tuple.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:36:47 +0000] rev 51544
perf-stream-locked-section: actually use v1 generation when requested
We were fetching a v1 generator but actually using the v2 function…
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Mar 2024 21:39:00 +0100] rev 51543
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Mar 2024 21:37:09 +0100] rev 51542
Added signature for changeset 803e61387e86
Raphaël Gomès <rgomes@octobus.net> [Fri, 29 Mar 2024 21:37:06 +0100] rev 51541
Added tag 6.7.2 for changeset 803e61387e86
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Mar 2024 14:47:20 +0000] rev 51540
relnotes: add 6.7.2
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 28 Mar 2024 07:12:09 +0000] rev 51539
bundle2: make the "hgtagsfnodes" part advisory
This bundle2 part is about helping the client to warms its cache. There is no
reason for it to be mandatory.
So we mark it advisory.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 16:27:48 +0000] rev 51538
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 10:57:16 +0100] rev 51537
branchcache: allow to detect "pure topological case" for branchmap
We don't rum this detection every time we run the branchcache, that would be
costly. However we now do it when running `hg debugupdatecache`.
This will help existing repository to benefit from the fastpath when possible.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 04:15:23 +0100] rev 51536
branchcache: add a "pure topological head" fast path
In a narrow but actually quick common case, all topological heads are all on
the same branch and all open. In this case, computing the branch map is very
simple. We can quickly detect situation where this situation will not change.
So we update the V3 format to be able to express this situation and upgrade the
update code to detect we remains in that mode.
The branch cache is populated with the actual value when the branch map is
accessed, but the update_disk method can do the update without needing to
populate it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:18:03 +0100] rev 51535
branchcache: move the processing of the new data in a dedicated method
In a future changeset, this will allow the V3 of the branch cache to use a fast
path when possible.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:10:44 +0100] rev 51534
branchcache: gather newly closed head in a dedicated set
This is part of a series to more clearly split the update in two step. This
will allow us to introduce a fast path during update in a future changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 16:09:42 +0100] rev 51533
branchcache: gather new obsolete revision in a set
This is part of a series to more clearly split the update in two step. This
will allow us to introduce a fast path during update in a future changeset.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 15:54:22 +0100] rev 51532
branchcache: filter obsolete revisions sooner
Since we won't do anything with the obsolete revisions, we can just ignore them
sooner.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 10:55:22 +0100] rev 51531
branchcache: skip entries that are topological heads in the on disk file
In the majority of cases, topological heads are also branch heads. We have
efficient way to get the topological heads and efficient way to retrieve
their branch information. So there is little value in putting them in the branch
cache file explicitly. On the contrary, writing them explicitly tend to create
very large cache file that are inefficient to read and update.
So the branch cache v3 format is no longer including them. This changeset focus
on the format aspect and have no focus on the performance aspect. We will cover
that later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 01:35:43 +0100] rev 51530
branchcache: simplify the branch rev cache test
We don't need that many content dump and this gets in the way in change in
access pattern (e.g. accessing revision in a different order change the order of
branches in the "names" file).
So we simplify this test in advance.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 11:39:44 +0100] rev 51529
branchcache: store filtered hash and obsolete hash independently for V3
This will avoid the bug covered in tests/test-branches-obsolete.t when we stop
storing all heads explicitly in V3.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 12:07:31 +0100] rev 51528
branchcache: show the cache file content in test-branches-obsoletes.t
This help to track the changes in format between v2 and v3.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 02:20:53 +0100] rev 51527
branchcache: rework the `filteredhash` logic to be more generic
We now have a more flexible `key_hashes` tuple. We duplicated various logic in
the V2 and V3 version of the cache as the goal is to start changing the logic
for V3 in the next few changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 01:53:52 +0100] rev 51526
filteredhash: rename the filteredhash function
The new name is less ambiguous, as we are about to introduce an alternative
function it seems like a good idea to have clearer name to distinct the two.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 06 Mar 2024 01:43:51 +0100] rev 51525
filteredhash: split the computation of revision sets
The branch2's filteredhash combines the filtered revisions and the obsolete
ones, this will creates issue for implicit reference to heads we want to
introduce for the v3 of the branch cache format. So we isolate this logic for
alternative use.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2024 15:21:18 +0100] rev 51524
filteredhash: move the hashing in its own function
This will help us to reuse this logic in variants of the hashes used for branch
cache validation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 23:31:50 +0100] rev 51523
branchcache: cleanup the final key generation after update
A lot of duplicated work seemed to be done, as we already update the tiprev and
tipnode when needed right before. So we simplify that part to focus on the
filtered hash.
See inline comment for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 12:56:08 +0100] rev 51522
branchcache: add more test for the logic around obsolescence and branch heads
While working on branch-cache-v3, we noticed some ambiguity in the
filtered+obsolete hash. However this was only caught by a rebase test by
chance.
It seems important to explicitly tests these cases.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:44:44 +0100] rev 51521
branchcache-v3: use more explicit header line
The key-value approach is clearer and gives more rooms to have the format evolve
in a clear way. It also provides extension (like topic) simpler way to extend
the validation scheme.
This is just a small evolution, the V3 format is still a work in progress.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 14:20:36 +0100] rev 51520
branchcache-v3: introduce a v3 format
For now the format is the very same, however we will start changing it in
future changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Feb 2024 14:04:29 +0100] rev 51519
branchcache: use an explicit class for the v2 version
This prepare the introduction of an experimental v3 format version.
In the process, we move the description of the format in that new class.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Feb 2024 15:33:21 +0100] rev 51518
branchcache: add some blank line in a test
This helps each section to stand out.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 02:09:15 +0100] rev 51517
phases: update the phase set as we go during retract boundary
Apparently iterating over the `changed_revs` dictionary is very expensive.
On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets
bundle gives give use the following timing.
e57d4b868a3e: 4.6 seconds
ac1c75188440: 102.5 seconds
prev-changeset: 30.0 seconds
this-changeset: 4.6 seconds
So, the performance regression is gone.
Once again: thanks to marvelous Python!
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 01:50:31 +0100] rev 51516
phases: avoid a potentially costly dictionary interation in some case
If we retract for the draft phase, there is not non-public item to be retracted
and we can skip this part. This part is was apparently super costly thanks to
Python.
On mozilla-try-2019-02-18, a perf::unbundle call with a 10 000 changesets
bundle gives give use the following timing.
e57d4b868a3e: 4.6 seconds
ac1c75188440: 102.5 seconds
this-changeset: 30.0 seconds
So we recovered about ⅔ of the regression, the next changeset will give us the
rest back.
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:26:46 +0100] rev 51515
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:24:42 +0100] rev 51514
Added signature for changeset 2e6fde2ed01e
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:24:36 +0100] rev 51513
Added tag 6.7.1 for changeset 2e6fde2ed01e
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:23:25 +0100] rev 51512
relnotes: add 6.7.1
Felipe Resende <felipe@fcresende.dev.br> [Sat, 16 Mar 2024 21:02:19 -0300] rev 51511
subrepo: fix normalizing paths with scheme
After revision 0afe96e374a7, subrepo paths were normalized using
posixpath.normpath and that resulted in ssh paths being wrongly converted
from ssh://host/path to ssh:/host/path
This fix applies the same logic used in urlutil.url to split the path scheme
from the rest and only use posixpath.normpath to the string after scheme://
Felipe Resende <felipe@fcresende.dev.br> [Sat, 16 Mar 2024 18:37:07 -0300] rev 51510
sshpeer: fix path when handling invalid url exception
In 73ed1d13c0bf the code was refactored but the error handling seems to have
been missed (or maybe the object shoud have implemented __bytes__)
Raphaël Gomès <rgomes@octobus.net> [Mon, 18 Mar 2024 11:25:21 +0100] rev 51509
delta-search: fix crash caused by unbound variable
This code path was apparently not tested. This fixes a crash when cloning the
Tryton repo.
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:52:51 +0100] rev 51508
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:49:44 +0100] rev 51507
Added signature for changeset c9ceb4f60256
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:49:40 +0100] rev 51506
Added tag 6.7 for changeset c9ceb4f60256
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2024 01:31:57 +0100] rev 51505
phases: avoid N² behavior in `advanceboundary`
We allowed duplicated entries in the deque, which each entry could potentially
insert all its ancestors. So advancing boundary for the full repository would
mean each revision would walk all its ancestors, resulting in O(N²) iteration.
For repository of any decent size, N² is quickly insane.
We introduce a simple set to avoid this and get back to reasonable performance.
Raphaël Gomès <rgomes@octobus.net> [Thu, 14 Mar 2024 16:25:46 +0100] rev 51504
relnotes: add 6.7
Raphaël Gomès <rgomes@octobus.net> [Thu, 14 Mar 2024 11:24:52 +0100] rev 51503
admin-commands: move the chainsaw extension to the admin commands module
Activating an extension is always a little bit of a chore and the long name,
options and "chainsaw" bits are deterrent enough.
This also allows us to help the discoverability for people looking for
repo "administration" tools, with the widest semantic of "administration".
Anton Shestakov <av6@dwimlabs.net> [Wed, 13 Mar 2024 16:22:13 -0300] rev 51502
obsutil: sort metadata before comparing in geteffectflag()
This is probably less important now that we dropped Python 2. We do still
support Python 3.6 though, and the dictionaries aren't ordered there either
(that was a big change that came with 3.7).
Still, maybe it's a good idea to sort metadata explicitly.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 11:11:34 +0100] rev 51501
tests: disable revlog compression in test-generaldelta.t (issue6867)
The revlog compression makes a lot of numbers unstable. Since checking revlog
compression is not the goal of this test, we disable the compression to get
stable numbers.
This should avoid wasting more time on this kind of changes in the future.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 11:09:29 +0100] rev 51500
test-general-delta: actually test optimize-delta-parent-choice=no
Since the configuration was not explicit, the case stopped testing what it
intended to test when the default value changed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 13:09:01 +0100] rev 51499
test-chg: stabilize the log checking
The "worker process exited" line have been making the CI flaky for a long time.
Lets sort this out.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 12:03:40 +0100] rev 51498
tests: fix test-patchbomb-tls.t instability
The flakiness on chg is caused by a client that exit faster than the server
output log.
So actively wait for the server to issue the expected output (with a small
timeout)
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 16:05:28 +0100] rev 51497
test-lock: use synchronisation file instead of sleep
This will prevent the test to be flaky on load.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:29:12 +0100] rev 51496
branchcache: use update_disk to refresh 'served' and 'served.hidden'
The `update_disk` method is dedicated to this kind of usecase. Now that the writting patterns are more consistent, we can use it to warm these two important cache.
I am dropping the first comment about "refreshing all the others" because it is
false. If a branchmap already exist for "served", none of the subset will be
updated.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:25:04 +0100] rev 51495
branchcache: explictly update disk state only if no transaction exist
If a transaction exist the `write_dirty` call will eventually be done and the state will be synched on disk. It is better to no interfer with that.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:32:50 +0100] rev 51494
branchcache: do not use `__getitem__` in updatecache
The `update_disk` method uses `updatecache` and the point of `update_disk` is to be able to do alternative processing to the one we do in `__getitem__`. So we calling `__getitem__` in `updatecache` defeat this purpose.
Instead we do the equivalent explicitly to preserve the spirit of `update_disk` (that we will actually put to use soon, I promise)
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 05:10:00 +0100] rev 51493
branchcache: explicitly track inheritence "state"
We move from a binary "dirty" flag to a three value "state": "clean", "inherited", "dirty".
The "inherited" means that the branch cache is not only "clean", but it is a
duplicate of its parent filter.
If a branch cache is "inherited", we can non only skip writing its value on
disk, but it is a good idea to delete any stale value on disk, as those will
just waste time (and possibly induce bug) in the future.
We only do this in the update related to transaction or explicit cache update
(e.g `hg debugupdatecache`). Deleting the file when we simply detected a stall
cache during a read only operation seems more dangerous.
We rename `copy` to `inherit_for` to clarify we associate a stronger semantic
to the operation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 04:53:17 +0100] rev 51492
branchcache: stop writing more branchcache file on disk than needed
Before this change, we were unconditionally writing a branchmap file for the
filter level passed to `update_disk`. This is actually counter productive if no
update were needed for this filter level. In many case, the branch cache for a
filter level is identical to its parent "subset" and it is better to simply
keep the subset update and reuse it every time instead of having to do identical
work for similar subset.
So we change the `update_disk` method to only write a file when that filter
level differ from its parent. This removes many cases where identical files were
written, requiring multiple boring update in the test suite.
The only notable changes is the change to `test-strip-branch-cache.t`, this
case was checking a scenario that no longer reproduce the bug as writing less
branchmap file result in less stalled cache on disk.
Strictly speaking, we could create a more convoluted scenario that create a
similar issue. However the next changeset would also cover that scenario so we
directly updated that test case to a "no longer buggy" state.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:49:06 +0100] rev 51491
branchcache: do not copy the `_dirty` flag
If the inherited branch cache is dirty, it will be written on disk, and the
super-set did not need to modify it, the on disk value for the subset will be
re-useable as is. So the super set does not needs to write the very same content
itself.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:52:08 +0100] rev 51490
branchcache: explicitly assert that copy is always about inheritance
This would catch cases where copy is used for something else if any existed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 Mar 2024 02:07:15 +0100] rev 51489
branchcache: stop using `copy(…)` in `replace(…)`
The `copy` method is mostly used for a filter level to inherit the branchmap
from a subset. So we stop using (abusing) it in "replace" to ensure `copy` is
used only for inheritance purposes.
Since `replace` is a method of the BranchMapCache, it seems fine to do lower
level operation there.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 16:47:32 +0100] rev 51488
branchcache: change the _delayed flag to an explicit `_dirty` flag
This is more consistent with the logic we use for other object and it open the way to a clearer management of the cache state.
Now, cache are created clean, cache update mark them dirty, writing them on
disk mark them clean again.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 15:50:15 +0100] rev 51487
branchcache: write branchmap in subset inheritance order
This way, we can guarantee a valid subset has been written before touching the
branchmap of another filter.
This is especially useful as we are bout to start deleting outdated branchmap
file.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 15:06:54 +0100] rev 51486
branchcache: do not accept "empty update"
This currently does not happens and it will be simpler that is remains that way.
If all update do something, we will be able to simply declare, in a later
changesets, that all update to result in a dirty branchcache.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 11:04:34 +0100] rev 51485
branchcache: avoid created a `None` filter repoview when writing
The repoview class is not intended to be used for unfiltered repository.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:49:55 +0100] rev 51484
stream-clone-tests: stop filtering non existent warning
This filtering was introduced in 74c004a515bc, however there is already no
warning in that changeset. So I guess the warnings existed when we the patch
was created but the problem was solved in another changeset that 74c004a515bc,
rebased on.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:46:12 +0100] rev 51483
stream-clone-test: simplify case testing obsolescence
There is only two important things in this test:
- the number of file we send, to show we picked the obsstore.
- the resulting state, to show we did alter things in the process.
The rest are of the number are very fragile and consume a lot of time for little
value when adjusting formats, caches, and protocol.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:43:07 +0100] rev 51482
stream-clone-test: simplify the case testing phases
There is only two important things in this test:
- the number of file we send, to show we picked the phase roots.
- the resulting phases, to show we did not modified them.
The rest are of the number are very fragile and consume a lot of time for little
value when adjusting formats, caches, and protocol.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:39:10 +0100] rev 51481
stream-clone-test: simplify bookmark clone
The important things to test here is the number of file included (to catch that
the bookmark file was sent). So we keep that part non glob'ed but glob the
rest.
The glob'ed numbers are very fragile and consume a lot of time for little value
when adjusting formats, caches, and protocol.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:31:42 +0100] rev 51480
stream-clone-test: add a verify call to the "clone while changing" case
It seems useful to very that the clone did not result in a corrupted copy.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 10:59:51 +0100] rev 51479
stream-clone-test: add title to various test cases
These case are fine as is, but as we are adding title to all the other as we
simplify them, lets add title for all cases.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:28:07 +0100] rev 51478
stream-clone-test: simplify testing of secret cloning restriction
Here, we just want to check if the streaming clone is allowed and used or not.
We do not care about the details of the clone itself.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:26:27 +0100] rev 51477
stream-clone-test: simplify the background file closing test
Here we just care about the fact the background file closing logic actually ran. We don't need to check the details of the cloning.
The details of the output is very fragile and consume a lot of time for little
value when adjusting formats, caches, and protocol. So we filter it out.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 10:51:01 +0100] rev 51476
stream-clone-test: simplify the --uncompressed alias check
To check that --uncompressed is an alias we just need to check it trigger a
stream clone, we don't need to check anything else.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 08 Mar 2024 10:50:42 +0100] rev 51475
stream-clone-test: drop an automatic pattern replacement
That pattern is nice, but it prevent us to glob the number of bytes when we
don't care about them. We don't care about them more often that what we
currently checks so dropping this pattern will help use to simplify various
tests.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:15:33 +0100] rev 51474
stream-clone-test: simplify the test for getbundle with stream=1
The core of this tests is about checking we receive a stream bundle with such
request. We don't need to look at too much of the details of the stream itself.
Since the content of the stream if shifting overtime, Such check is very
fragile and consume a lot of time for little value when adjusting formats,
caches, and protocol.
So we reduce the size of what we check to focus on "is this a stream clone"
question.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:05:28 +0100] rev 51473
stream-clone-test: factor some piece of basic clone test out
Multiple parts of this case (listing cache, checking error) are common to all
cases and don't need to be in the conditionnal block.
This simplify the test update.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 28 Feb 2024 22:01:09 +0100] rev 51472
stream-clone-test: simplify the case where server disabled it
We have an option to disable it, we don't need to test it with all protocol
variants.
In addition there is little value in looking at the bytes to bytes details of
the reply. Such check is very fragile and consume a lot of time for little
value when adjusting formats, caches, and protocol.
Georges Racinet <georges.racinet@octobus.net> [Mon, 11 Mar 2024 13:36:25 +0100] rev 51471
rust-matchers: raw regular expression builder
Extracting this `re_builder()` from `re_matcher()` makes it reusable
in more general cases than matching `HgPath` instances and would
help reducing code duplication in RHGitaly.
Georges Racinet <georges.racinet@octobus.net> [Mon, 11 Mar 2024 13:23:18 +0100] rev 51470
rust-filepatterns: export glob_to_re function
Making this function public should not risk freezing the internal API,
and it can be useful for all downstream code that needs to perform
glob matching against byte strings, such as RHGitaly where it will
be useful to match on branches and tags.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2024 01:20:12 +0100] rev 51469
repoview: prevent `None` to be passed as the filtername
We let such instantiation slip in a previous commit, so we add an explicit check
to prevent it to happen in the future.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 11:04:34 +0100] rev 51468
branchcache: avoid created a `None` filter repoview when writing
The repoview class is not intended to be used for unfiltered repository.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2024 15:07:47 +0100] rev 51467
rust-index: don't use mutable borrow to computed filtered heads
This does not need to mutate the index.
This is the prime suspect for some RuntimeError raised during some pushes.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 05 Mar 2024 15:07:04 +0100] rev 51466
rust-index: don't use mutable borrow for head-diff computation
It does not needs to mutate the index.
This is one of the two suspects of RuntimeError being thrown during push.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:26:08 +0100] rev 51465
branchcache: move head writing in a `_write_headers` method
Same rational: this will help having format variants.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:25:41 +0100] rev 51464
branchcache: move head writing in a `_write_heads` method
Same rational: this will help having format variants.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:23:45 +0100] rev 51463
branchcache: move the header loading in a `_load_header` class method
This will help changing header parsing in format variants.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:15:10 +0100] rev 51462
branchcache: simplify a long line
Gratuitous change to help code readability.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:12:20 +0100] rev 51461
branchcache: rename `load` to `_load_heads`
We are about to have more similar function, we rename the existing one to a more
meaningful name and mark it private in the process.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 20:40:37 +0100] rev 51460
branchcache: move the filename to a class attribute
This prepare the introduction of more variant of cache.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 27 Feb 2024 22:52:00 +0100] rev 51459
test-clonebundles: simplify matching to be less flavor depends
We keep the files and bytes output for the first call, but then we mostly check
that we are being served a stream-clone bundle, not the actual content and size
of the bundle. That aspect being tested by the stream clone test themselves.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 23:05:33 +0100] rev 51458
repoview: fix changelog.__contains__ method
This have been around for ten years, so we can safely that this method have few
callers. However I am about to add one.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 08 Jan 2024 15:11:34 +0100] rev 51457
branchcache: unconditionally write delayed branchmap
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 16:14:15 +0100] rev 51456
branchcache: drop the unused `_verifyclosed`
This code appears dead since its introduction about 5 years ago in this three
consecutive commits:
- 6578654916ae → introduce the method with two calls
- 7c9d4cf23adf → remove first call
- be5eeaf5c24a → remove second call
o changeset: be5eeaf5c24a
| user: Pulkit Goyal <pulkit@yandex-team.ru>
| date: Fri Apr 05 15:57:09 2019 +0300
| summary: branchcache: don't verify closed nodes in _branchtip()
|
o changeset: 7c9d4cf23adf
| user: Pulkit Goyal <pulkit@yandex-team.ru>
| date: Fri Apr 05 15:56:33 2019 +0300
| summary: branchcache: don't verify closed nodes in iteropen()
|
o changeset: 6578654916ae
| user: Pulkit Goyal <pulkit@yandex-team.ru>
~ date: Mon Apr 01 13:56:47 2019 +0300
summary: branchcache: lazily validate nodes from the branchmap
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 15:46:24 +0100] rev 51455
branchcache: dispatch the code into the dedicated subclass
The code useful only to the local brancache have now been moved into the
dedicated subclass. This will help improving the branchcache code without subtle
breaking the remote variants.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 25 Feb 2024 14:09:36 +0100] rev 51454
branchcache: introduce a base class for branchmap
This will help define a clear boundary between the two.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Feb 2024 12:09:06 +0100] rev 51453
branchcache: fix the copy code
We copy some internal attribute along too. This should prevent inconsistency in
the resulting branchmap.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Feb 2024 13:11:42 +0100] rev 51452
branchcache: pass a "verify_node" attribut to __init__ instead of hasnode
The hasnode callback cannot be inherited and is dropped on copy, which seems
like a bad idea. Instead we pass the actual semantic as a parameter and let the
internal logic deal with it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Feb 2024 11:59:56 +0100] rev 51451
branchcache: stop storing a repository instance on the cache altogether
We did not really needed it and we do not needs it anymore at all. So lets make
things simpler for consistency and garbage collecting and stop storing it
altogether.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 19 Feb 2024 11:43:19 +0100] rev 51450
branchcache: pass the target repository when copying
Branchmap are usually copied to be used on a different repoview using a
different filter level. Passing the repository around means the repository in
`branchcache._repo` will drift from the actual branchmap filter.
This is currently "fine" because the repo is only used to retrieve the `nullid`
value. However, this is a fairly big trap for any extension or future code using
the `_repo` attribute.
The replace logic is now using a copy to ensure the right repository view is
used to initialized the cached value.
We add a couple of assert for make sure this inconsistency does not sneak back.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Jan 2024 11:30:10 +0100] rev 51449
branchcache: have an explicit method to update the on disk cache
Explicit is better and will give use more flexibility for future evolution of
the storage.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 29 Feb 2024 14:13:21 -0800] rev 51448
crecord: drop calls to `curses.endwin()`
We got a bug report where `curses.endwin()` failed with `_curses.error: endwin()
returned ERR`. Looking at e306d552dfb12, it seems like we should be able to just
remove these calls.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 04 Mar 2024 04:16:15 +0100] rev 51447
config: move the option to mmap rev branch cache in the storage section
See previous commit for rational.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 04 Mar 2024 04:13:33 +0100] rev 51446
config: document the storage and format sections
This should help people to put configuration in the right section.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 12:59:57 +0100] rev 51445
rust-index: drop offset_override
The inline `offsets` value diverge from the one on disk for added value, so the
offset_override tricks is not going to work well once we start having the full
revlog logic in Rust.
We remove it beforehand and align the Rust logic to the Python one (adjusting
the segment offset at read time for inline revlog).
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 26 Feb 2024 13:41:02 +0100] rev 51444
rust-index: stop calling `with_offset` in the tests
We are not adding any data, so why are we setting any offset?
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:57:50 +0100] rev 51443
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:55:53 +0100] rev 51442
Added signature for changeset d1d48d18db37
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:55:49 +0100] rev 51441
Added tag 6.7rc0 for changeset d1d48d18db37
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:18:29 +0100] rev 51440
relnotes: add 6.7rc0
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:18:17 +0100] rev 51439
relnotes: remove outdated message from `next`
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:10:44 +0100] rev 51438
branching: merge default into stable for 6.7rc0
Raphaël Gomès <rgomes@octobus.net> [Fri, 23 Feb 2024 15:09:18 +0100] rev 51437
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 14:07:33 +0100] rev 51436
perf: add a --as-push option to perf::unbundle
This turned out to make a quite significant difference.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:25:09 +0100] rev 51435
chainsaw-update: exit early if one of the intermediate command fails
That will prevent the user to be presented with a start that pretend to be
consistent with the request, but is not.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:32:35 +0100] rev 51434
chainsaw-update: lock the repository for the duration of the operation
This should prevent and catch some misusage where something else try to touch
the repository.
Georges Racinet <georges.racinet@octobus.net> [Fri, 23 Feb 2024 11:41:55 +0100] rev 51433
chainsaw-update: taking care of initial cloning
Perhaps we should go just a bit lower level than this `instance()`,
since the main added value in our use-case is full path resolution,
that we need to do anyway for the rmtree cleanup.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 11:30:58 +0100] rev 51432
chainsaw-update: use a graph with branching in graph
This will be relevant for the next improvement of `chainsaw-update`.
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:39:06 +0100] rev 51431
chainsaw-update: log actual locks breaking
Previously, the command would simply state that it was about
to break locks, not if there was actually some to break.
This version is race-free. It would be also possible to display
the content of the lock before hand (not race-free but informative
in almost all cases).
Georges Racinet <georges.racinet@octobus.net> [Wed, 17 Jan 2024 14:26:58 +0100] rev 51430
vfs: have tryunlink tell what it did
It is useful in certain circumstances to know whether vfs.tryunlink()
actually removed something or not, be it for logging purposes.
Georges Racinet <georges.racinet@octobus.net> [Sat, 26 Nov 2022 12:23:56 +0100] rev 51429
chainsaw: new extension for dangerous operations
The first provided command is `chainsaw-update`, whose one and single job is
to make sure that it will pull, update and purge the target repository,
no matter what may be in the way (locks, notably), see docstring for rationale.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:45:07 +0100] rev 51428
rust: disable the RustIndex without persistent nodemap
See rational inline.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 03:44:56 +0100] rev 51427
rust: stop claiming the C index is compatible with the rust code
This is no longer the case since the introduction of the pure Rust Index, and
was probably not the case since the MixedIndex itself.
So we fix the dedicated attribute value.
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:11:26 +0100] rev 51426
rust-index: remove one collect when converting back
Turns out this is slightly faster. Sending the results back to Python is still
the most costly (like 75% of the time) of the whole method, but it's about
as fast as it can be now.
hg perf::phases on mozilla-try-2023-03-22
before: 0.267114
after: 0.247101
Raphaël Gomès <rgomes@octobus.net> [Thu, 22 Feb 2024 15:06:16 +0100] rev 51425
rust-index: improve phase computation speed
While less memory efficient, using an array is *much* faster than using a
HashMap, especially with the default hasher. It even makes the code simpler,
so I'm not really sure what I was thinking in the first place, maybe it's more
obvious now.
This fix a significant performance regression when using the rust version of the
code. (however, the C code still outperform rust on this operation)
hg perf::phases on mozilla-try-2023-03-22
- 6.6.3: 0.451239 seconds
- before: 0.982495 seconds
- after: 0.265347 seconds
- C code: 0.183241 second
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 06:37:25 +0100] rev 51424
phases: directly update the phase sets in advanceboundary
This is similar to what we do in retractboundary. There is no need to invalidate
the cache if we have everything at hand to update it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 05:25:35 +0100] rev 51423
phases: large rework of advance boundary
In a similar spirit as the rework of retractboundary, the new algorithm is doing
an amount of work in the order of magnitude of the amount of changeset that
changes phases. (except to find new roots in impacted higher phases if any may
exists).
This result in a very significant speedup for repository with many old draft
like mozilla try.
runtime of perf:unbundle for a bundle constaining a single changeset (C code):
before 6.7 phase work: 14.497 seconds
before this change: 6.311 seconds (-55%)
with this change: 2.240 seconds (-85%)
Combined with the other patches that fixes the phases computation in the Rust
index, the rust code with a persistent nodemap get back to quite interresting
performances with 2.026 seconds for the same operation, about 10% faster than
the C code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 19:21:14 +0100] rev 51422
phases: apply similar early filtering to advanceboundary
advanceboundary is called the push's unbundle (but not the other unbundle) so
advanceboundary did not show up the profile I looked at so far.
We start with simple pre-filtering to avoid doing any work if we don't needs
too.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 11:09:25 +0100] rev 51421
phases: filter revision that are already in the right phase
No need to compute new roots if everything is already in order.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 13:05:29 +0100] rev 51420
phases: invalidate the phases set less often on retract boundary
We already have the information to update the phase set, so we do so directly
instead of invalidating the cache.
This show a sizeable speedup in our `perf::unbundle` benchmark on the
many-draft mozilla-try repository.
### 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-10
before: 2.055259 seconds
after: 1.887064 seconds (-8.18%)
# benchmark.variants.revs = last-100
before: 2.409239 seconds
after: 2.222429 seconds (-7.75%)
# benchmark.variants.revs = last-1000
before: 3.945648 seconds
after: 3.762480 seconds (-4.64%)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 13:05:23 +0100] rev 51419
phases: incrementally update the phase sets when reasonable
When the amount of manual walking is small, we update the phases set manually
instead of computing them from scratch. This should help small update. The next
changesets will make this used more often by reducing the amount of full
invalidation we do on roots upgrade.
The criteria for using an incremental upgrade are arbitrary, however, it "should
never hurt".
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 23 Feb 2024 00:01:33 +0100] rev 51418
phasees: properly shallow caopy the phase sets dictionary
We are about to increments the set more incrementally in some case, so we need
to make a proper shallow copy of it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 14:42:13 +0100] rev 51417
phases: pass an unfiltered repository to _ensure_phase_sets
It seems better for such a low level function to be able to assume it operate on
a real repository.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 13:01:25 +0100] rev 51416
phases: drop set building in `hasnonpublicphases`
We don't actually use the set, so why do we ensure they are built?
(we should also clean up the use of repository argument but that's a quest for later).
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 11:59:28 +0100] rev 51415
phases: gather the logic for phasesets update in a single method
This logic is duplicated around for no good reason, we gather it in a single
place.
The conditional is the new function are a bit weird as we about going to extend it soon.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 10:58:54 +0100] rev 51414
phases: change the way we warm the phasecache in repocache
Same logic as for the previous chngeset. We are about to rename and change the
method used here.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 10:56:05 +0100] rev 51413
phases: use a more generic way to trigger a phases computation for perf
Querying the tip most revision will require the cache to warm the same as
calling the dedicated method. This avoid using a method that is mostly meant for
internal use and will be renamed in a coming changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 12:01:09 +0100] rev 51412
phases: fix an overzealous invalidation of the phase sets
If `len(cl) == self._loadedrevslen` the cache is up to date.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 11:04:56 +0100] rev 51411
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 51410
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 51409
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 51408
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 51407
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 51406
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 51405
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 51404
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 51403
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 51402
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 51401
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 51400
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 22 Feb 2024 18:28:01 +0100] rev 51399
perf: support --template on perf::phases
Zeger Van de Vannet <zeger@vandevan.net> [Wed, 14 Feb 2024 08:14:46 +0100] rev 51398
annotate: limit output to range of lines
Arseniy Alekseyev <aalekseyev@janestreet.com> [Mon, 12 Feb 2024 20:01:27 +0000] rev 51397
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 51396
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 51395
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 51394
branching: merge stable into default
Arun Kulshreshtha <akulshreshtha@janestreet.com> [Tue, 20 Feb 2024 10:47:47 -0500] rev 51393
hg-core: separate timestamp and extra methods
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 21 Feb 2024 02:12:58 +0100] rev 51392
debugformat: fix formatting for compression level
`bytes(<int>)` gives a very different result as `str(<int>)` and the display
of `hg debugformat` have been broken for a while as a result.
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!
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Feb 2024 18:10:41 +0000] rev 51389
tests: tweak chg test to make it fail less often
the test apparently sometimes prints the word "start" as a part of profile,
so let's no longer match "start":
CHGHG=/*/install/bin/hg (glob)
+ \x1b[90m | 50.0% 0.01s profiling.py: __enter__ line 196: self.start()\x1b[0m (esc)
+ \x1b[90m | 50.0% 0.01s profiling.py: start line 261: self._profiler.__enter__()\x1b[0m (esc)
+ \x1b[90m | 50.0% 0.01s profiling.py: statprofile line 125: statprof.start(mechanism=b'...\x1b[0m (esc)
+ \x1b[90m | 50.0% 0.01s statprof.py: start line 356: state.thread.start()\x1b[0m (esc)
+ \x1b[90m | 50.0% 0.01s threading.py: start line 852: self._started.wait()\x1b[0m (esc)
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 15 Feb 2024 15:21:43 +0000] rev 51388
cext: fix potential memory leaks of list items appended with PyList_Append
Also reduce the duplication in the tricky code that uses PyList_Append by
extracting it into a function `pylist_append_owned`.
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Wed, 14 Feb 2024 22:55:11 -0500] rev 51387
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.