On Tue, Apr 2, 2019 at 6:57 AM Pierre-Yves David < pierre-yves.da...@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.da...@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 >
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
