[PATCH 7 of 8 "] compression: introduce an official `zstd-revlog` requirement
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>>
> 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
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.
More information about the Mercurial-devel