[PATCH 7 of 8 "] compression: introduce an official `zstd-revlog` requirement
gregory.szorc at gmail.com
Tue Apr 2 14:28:08 EDT 2019
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>'
> > 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
> > 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:
> > 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...
More information about the Mercurial-devel