[PATCH 7 of 8 "] compression: introduce an official `zstd-revlog` requirement

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Apr 9 06:06:08 EDT 2019



On 4/2/19 8:28 PM, Gregory Szorc wrote:
> On Tue, Apr 2, 2019 at 6:57 AM Pierre-Yves David 
> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>> 
> wrote:
> 
> 
> 
>     On 4/2/19 9:52 AM, Josef 'Jeff' Sipek wrote:
>      > On Sun, Mar 31, 2019 at 17:36:23 +0200, Pierre-Yves David wrote:
>      >> # HG changeset patch
>      >> # User Pierre-Yves David <pierre-yves.david at octobus.net
>     <mailto:pierre-yves.david at octobus.net>>
>      >> # Date 1553707623 -3600
>      >> #      Wed Mar 27 18:27:03 2019 +0100
>      >> # Node ID 2cfe9983fa92313d58f0420ec62f2341a810343e
>      >> # Parent  108e26fa0a97fe5342a1ce246cc4e4c185803454
>      >> # EXP-Topic zstd-revlog
>      >> # Available At https://bitbucket.org/octobus/mercurial-devel/
>      >> #              hg pull
>     https://bitbucket.org/octobus/mercurial-devel/ -r 2cfe9983fa92
>      >> compression: introduce an official `zstd-revlog` requirement
>      >
>      > Is the requirement for the compression algo or for the
>     compression algo's
>      > use in revlog?
> 
>     The use of zstd in revlog
> 
>      >
>      > If the former, something like 'compression-<algo>' makes more sense.
>      >
>      > If the later, would it be better to call it
>     'revlog-compression-<algo>' or
>      > something to that effect?
> 
> I agree with Jeff that the requirement name should be derived from the 
> compression engine name. e.g. the zstd compression engine supporting 
> revlogs will result in the "revlog-compression-zstd" requirement. That, 
> or the compression engine itself advertises an attribute denoting the 
> requirement for revlogs with that compression format. I think I like the 
> latter better, as it means no special casing of specific string values 
> in the requirements code - just special casing for `None`.
> 
> Could you please try something along these lines? For clarity, the thing 
> that is bothering me is the leaky implementation where the low-level 
> requirements code has to know about zlib and zstd. All of this should be 
> generic and derived from the registered compression engines: that's what 
> the compression engine abstraction is for.

My main concerns here is to avoid accidental promotion of some odd 
compression engine. So I don't want to automatically generates 
revlog-compression-XXX for engine that supports revlog compression.

The requirement related attributes for compression engine seems like a 
good idea. However we needs it to be a list since zstd requires two 
value. Are you fine with that ?
An alternative approach would be to keep the automatic generation with 
some extra argument to convey the fact a compression engine as official 
support.

I am sending a V3 with:
* the updated requirements names
* more generic approach to requirement (but still some hard coding)
* other feedback integrated

I am happy to send follow up removing the hard coding once we converge 
on an approach about that.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list