Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 26 Feb 2020 17:16:25 +0100] rev 44422
revlog-compression: release note entry for update the config to be a list
I updated the changeset, but forgot to phabsend apparently.
Differential Revision: https://phab.mercurial-scm.org/D8165
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:18 +0100] rev 44421
rust-nodemap: a method for full invalidation
This will be used for exceptional operations,
such as a `__delitem__` on the `MixedIndex` with
Rust nodemap.
In principle, `NodeTree` should also be able to forget
an entry in an efficient way, by accepting to insert
`Element::None` instead of only `Element::Rev(r)`,
but that seems really overkill at this point. We need
to support exceptional operations such as `__delitem__`,
only for completeness of the revlog index as seen from
Python. The Python callers don't seem to even really
need it, deciding to drop the nodemap unconditionally at
at higher level when calling `hg strip`. Also, `hg strip`
is very costly for reasons that are unrelated to nodemap
aspects.
Differential Revision: https://phab.mercurial-scm.org/D8098
Georges Racinet <georges.racinet@octobus.net> [Tue, 18 Feb 2020 19:11:17 +0100] rev 44420
rust-nodemap: accounting for dead blocks
By the very append-only nature of the `NodeTree`, inserting
new blocks has the effect of making some of the older ones
useless as they become unreachable.
Therefore some automatic housekeeping will need to be provided.
This is standard procedure in the word of databases, under names
such as "repack" or "vacuum".
The new `masked_readonly_blocks()` will provide callers with
useful information to decide if the nodetree is ripe for
repacking, but all the `NodeTree` can provide is how many
blocks have been masked in the currently mutable part. Analysing
the readonly part would be way too long to do it for each
transaction and defeat the whole purpose of nodemap persistence.
Serializing callers (from the Python layer) will get this figure
before each extraction and maintain an aggregate counter of
unreachable blocks separately.
Note: at this point, the most efficient repacking is just to restart
afresh with a full rescan.
Differential Revision: https://phab.mercurial-scm.org/D8097