On 10/12/2018 16:53, Gregory Szorc wrote:
> I'm currently reviewing and landing Boris's series to enable sparse
> revlog by default. I think the functionality is stable enough to be
> enabled by default.
>
> The way it is currently implemented, sparse revlogs are an additional
> repository requirement. The "revlogv1" requirement denotes version 1
> revlogs and the "sparserevlog" requirement denotes that revlogs are
> sparse. Sparse revlog functionality is enabled if the repository
> requirement is present.
>
> I'd like to put forward a proposal to change this behavior before the
> 4.9 release. And by "change" I mean "change for new repos but likely
> maintain BC with the existing behavior for existing repos [if it makes
> sense]."
>
> At the very minimum, I think we should introduce a revlog flag that
> denotes the revlog as sparse. We have 16 bits to use and we're only
> using 2 bits for "inline" and "generaldelta." I propose we allocate
> the next bit to denote sparse I/O.
>
> Having a revlog flag to denote sparse forces the "is sparse or not" to
> live closer to the data. It allows revlog opening to not directly care
> about repository requirements. It gives us flexibility to toggle
> sparse behavior on a per-revlog basis (if that makes sense).
>
> This change would align the behavior of sparse revlogs with
> generaldelta revlogs.
>
> Thoughts?

Having the data closer looks like a good idea. However, we'll still have
to care for repository requirement to maintains BC. When we introduce
the flag, we have to be careful in documenting that exception exists.
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to