revlog: also detect intermediate snapshots
Also detect intermediate-snapshot done against another previous snapshot.
Doing an intermediate snapshot instead of a full one can reduce the number of
full snapshots we need. They are especially useful for content with a lot of
churn on the same line (eg: the manifest) where having a delta over multiple
revisions can end up being significantly smaller than the sum of these
revision deltas.
A revlog built using intermediate snapshots can be a bit smaller and reuse
snapshot much more efficiently. This last property is useful combined with
constraints on chain length. Using intermediate snapshot can produce
repository with delta chain ten times shorter without impact on the storage
size. Shorter chain lengths are faster to restore, greatly improving read
performance.
This changesets (and the following ones) focus on getting the core principle
of intermediate snapshots into Mercurial core. Later changeset will introduce
the strategy to create them.
revlog: add a method to tells whether rev is stored as a snapshot
For now we only have one type of snapshot: full snapshot versus nullrev.
However we are looking into adding intermediate snapshot where a large diff
against another snapshot is performed instead of storing a full new text.
The conditional is a bit strange and is done in order to help readability of a
some later changesets.
debugrevlog: fix for non-manifest object
The `filelog` object is no longer an actual revlog. Instead, the actual revlog
is stored in the `_revlog` attribute.
remotephase: avoid full changelog iteration (
issue5964)
Changeset
88efb7d6bcb6 introduced a performance regression by triggering a
full ancestors walk.
This changeset reworks this logic so that we no longer walk down the full
changelog. The motivation for
88efb7d6bcb6,
issue5939, is still fixed.
mercurial compared to a draft repository
----------------------------------------
8eeed92475d5: 0.012637 seconds
88efb7d6bcb6: 0.202699 seconds (x16)
46da52f4b820: 0.215551 seconds (+6%)
this code: 0.008397 seconds (-33% from base)
The payload size reduction we see in `test-bookmarks-pushpull.t` comes from a
more aggressive filter of nullid and is harmless.
nodes: expand/comment the magic nodes so they are more easily searchable
We just encountered `
000000000000modified`, and it was quite annoying to search
for these, even though I knew they existed. For those that don't know that they
exist, this is essentially impossible to search for :)
(Technically we encountered it in its hex form,
3030303030303030303030306d6f646966696564, so I'm adding comments with those
forms in case that's helpful to people in the future).
Differential Revision: https://phab.mercurial-scm.org/D4331