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