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