Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
MIME-Version: 1.0
In-Reply-To: <20170726111920.GU90677@ted.stsp.name>
References: <20170714111350.B07063A0F99@svn01-us-west.apache.org>
 <1500300013.520913.1043351984.67FF62A9@webmail.messagingengine.com>
 <CAP_GPNjwm1Aj34WcmwfhNCZKUKgK2yxYAfpUUyZoiAi1t+YbCA@mail.gmail.com>
 <20170726095410.GR90677@ted.stsp.name> <CAP_GPNibuoij6VahwgssBRHp0u+4wusv4rzCgfXHhen+iJGxRw@mail.gmail.com>
 <20170726111920.GU90677@ted.stsp.name>
From: Evgeny Kotkov <evgeny.kotkov@visualsvn.com>
Date: Wed, 26 Jul 2017 14:41:31 +0300
Message-ID: <CAP_GPNgx-32DhN9dmcPkT-HNf-LtZH4dPQOUmdHCPuXChk_C_A@mail.gmail.com>
Subject: Re: svn commit: r1801940 - in /subversion/trunk: ./ notes/
 subversion/include/ subversion/include/private/ subversion/libsvn_delta/
 subversion/libsvn_fs_fs/ subversion/libsvn_subr/ subversion/tests/libsvn_delta/
 subversion/tests/libsvn_subr/
To: Stefan Sperling <stsp@elego.de>
Cc: Subversion Development <dev@subversion.apache.org>, Daniel Shahaf <d.s@daniel.shahaf.name>,
	commits@subversion.apache.org
Content-Type: text/plain; charset="UTF-8"
archived-at: Wed, 26 Jul 2017 11:42:03 -0000

Stefan Sperling <stsp@elego.de> writes:

> Sounds like we're headed in a good direction :-)

One particular thing that bothers me about using LZ4 as the new default
is that I think that a decision like that goes a bit against the usual policy
(add new optional feature, switch the default in the next minor release).

But, personally, in this case I would say that it would make sense to
immediately make LZ4 the new default and available to the users, if there
won't be objections to that.

> I agree that 'compression-level = 1' -> lz4 makes sense if you know
> what to expect from lz4 vs. zlib. But honestly imagining myself giving
> a workshop for administrators and explaining it like that, I see people
> shake their heads in disbelief. It looks too much like an implementation
> detail leaked into the config interface. A compression=lz4/zlib knob would
> make a lot more sense to most people, with a corresponding subordinate
> default for compression-level (lz4: 1, zlib: 5).

I think that the proposed solution with the new option that overrides (and,
essentially, deprecates) 'compression-level':

  compression = none | lz4 | zlib | zlib-1 ... zlib-9

is explicit and should be understood by the users in case they stumble
across it.

Please note that I don't think that we should change the behavior of
'compression-level' in fsfs.conf.  In other words, the 'compression-level'
would still mean "zlib compression level", exactly as it works now.  As it's
going to be superseded by the new 'compression' option, it's not necessary
and maybe even wrong to also change the existing meaning of 'compression-
level.


Regards,
Evgeny Kotkov