D5565: revlog: add version 2 format flag to control sparse
lothiraldan (Boris Feld)
phabricator at mercurial-scm.org
Fri Jan 11 05:06:39 EST 2019
lothiraldan added a comment.
> Revlog behavior should live as close to the revlog as possible.
> In version 1 revlogs, we engaged sparse semantics by using a
> repository requirement. This constituted action at a distance
> and wasn't optimal.
>
> This commit introduces a feature flag on version 2 revlogs that
> explicitly denotes whether sparse reading semantics are enabled.
Why have a flag for revlog v2 at all? Since v2 have not been "released"
yet, why not use sparse-revlog logic in all case when using revlog v2?
> The flag is enabled by default for version 2 revlogs.
>
> In order to get the flag enabled by default, we had to tweak
> localrepo's logic for populating opener options to only set
> "sparse-revlog" if the requirement was present. This lets the
> revlog initializer use sane defaults depending on the revlog
> version. (The interaction between opener options and the revlog
> class is kinda wonky and could use a re-think. But my little
> brain isn't prepared to handle that at this time.)
>
> I'm also a bit unsure why we have 2 attributes controlling
> sparse behavior (revlog._sparserevlog and revlog._withsparseread).
> I *think* they can be consolidated. But I'm not sure. The new
> revlog feature flag implies both, which seems reasonable.
The revlog._sparserevlog flag enables sparse writing (and reading),
writing sparse revlog requires readers to use sparse-reading and is
gated behind a new requirement (introduced in hg 4.7).
Sparse-reading can be used for non-sparse repositories, it is just a
reader thing.
REPOSITORY
rHG Mercurial
REVISION DETAIL
https://phab.mercurial-scm.org/D5565
To: indygreg, #hg-reviewers
Cc: lothiraldan, mercurial-devel
More information about the Mercurial-devel
mailing list