revlog: add version 2 format flag to control sparse
Changes PlannedPublic

Authored by indygreg on Jan 10 2019, 7:32 PM.

Details

Reviewers
None
Group Reviewers
hg-reviewers
Summary

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.

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.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped
indygreg created this revision.Jan 10 2019, 7:32 PM

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.

indygreg planned changes to this revision.Jan 11 2019, 6:11 PM

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?

That's a good point and I'm glad you weighed in on this. I meant to ask that question in the commit message!

If we don't have a good reason to disable sparse revlogs, I'd be OK removing the feature flag and implying the feature by default. I'll update this commit accordingly unless others object to making is always on.

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.

Thank you for clarifying this! It might be useful to have this better documented in the code...