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

[Gregory Szorc]

On Tue, Apr 2, 2019 at 6:57 AM Pierre-Yves David <
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>
> >> # 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.


>
> > Either way, while a *human* knows that zstd is a compression algo, could
> it
> > make sense to make it easily parsable?  I'm imagining a slightly better
> > error messages when requirements fail, or just the ability to
> > programmatically identify the algo.  For example, instead of the current:
> >
> >    abort: repository requires features unknown to this Mercurial:
> foobar-revlog!
> >
> > hg could emit:
> >
> >    abort: repository requires a compression algo unknown to this
> Mercurial: foobar!
>
> I'm that longer version has much value. Most of our requirement has name
> opaque to normal user. This is why we link to an explanatory pages.
>
> Once this series is in, I am planning to do some UI polish. Especially,
> for version that know this requirement but have been compiled without
> zstd support, we can issue a better message.
>
> >
> >>
> >> This requirement supersede `exp-compression-zstd`. However, we keep
> support for
> >
> > s/supersede/supersedes/ :)
> >
> > Jeff.
> >
>
> --
> Pierre-Yves David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20190402/80af63c5/attachment.html>