Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Mar 2024 08:43:20 +0000] rev 51584
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 51583
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 51582
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 51581
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Mar 2024 16:27:48 +0000] rev 51580
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 07 Mar 2024 10:57:16 +0100] rev 51579
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 51578
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 51577
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 51576
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 51575
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 51574
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 51573
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 51572
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 51571
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 51570
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 51569
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 51568
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 51567
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 51566
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 51565
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 51564
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 51563
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 51562
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 51561
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 51560
branchcache: add some blank line in a test
This helps each section to stand out.
Raphaël Gomès <rgomes@octobus.net> [Thu, 21 Mar 2024 12:26:46 +0100] rev 51559
branching: merge stable into default
Raphaël Gomès <rgomes@octobus.net> [Fri, 15 Mar 2024 10:52:51 +0100] rev 51558
branching: merge stable into default
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2024 03:29:12 +0100] rev 51557
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.