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: <1500982743.1886944.1051840176.629897B4@webmail.messagingengine.com>
References: <20170714111350.B07063A0F99@svn01-us-west.apache.org>
 <1500300013.520913.1043351984.67FF62A9@webmail.messagingengine.com>
 <CAP_GPNjwm1Aj34WcmwfhNCZKUKgK2yxYAfpUUyZoiAi1t+YbCA@mail.gmail.com> <1500982743.1886944.1051840176.629897B4@webmail.messagingengine.com>
From: Evgeny Kotkov <evgeny.kotkov@visualsvn.com>
Date: Tue, 25 Jul 2017 19:28:04 +0300
Message-ID: <CAP_GPNika+MBG77NdMcDyWN_5Ff6wXF2y1o0+3TCYY+cvqthMA@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: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Subversion Development <dev@subversion.apache.org>, commits@subversion.apache.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Daniel Shahaf <d.s@daniel.shahaf.name> writes:

> - I don't see how the fact that =C2=ABSVNCompression "lz4, zlib"=C2=BB mi=
ght be
>   considered too complex to add, affects my arguments about fsfs.conf.
>   As I said earlier, FSFS f8 does not need to support 1.9 and 1.10
>   clients in parallel, so it has no need for a compression negotiation
>   configuration.  Perhaps you could clarify the fsfs part of your
>   argument?

[...]

> Yes, there are further changes we could make if we find ourselves adding
> more compression algorithms, but it is premature to consider them.  At
> this point, I simply suggest to add a fsfs.conf "compression" knob, with
> the syntax you proposed, that overrides compression-level if both are set=
.
> We can make further changes as and when.

With a bit more thought on this, I agree that providing an explicit knob
(compression =3D ...) in fsfs.conf would be more appropriate than what we
have now.

I had an assumption that it would be nice to keep the configuration in
fsfs.conf and in mod_dav_svn working in a similar way.  But, as they
have different scopes (and only the latter requires negotiation), there
is no reason not to have the explicit configuration in fsfs.conf.  After al=
l,
being explicit about what gets written on the disk is better.

Let me see what I can come up with regarding the new "compression =3D ..."
option.

>> While such approach is explicit, it also has a couple of drawbacks, as i=
t:
>>   - leaves a window for mistakes (say, if the user sets "SVNCompression =
lz4"
>>     and inadvertently disables compression for older clients),
>>   - is not forward-compatible, as new compression algorithms require the
>>     server to be reconfigured, and
>>   - adds complexity.
>
> - We can detect the configuration "SVNCompression lz4" and error out on i=
t.

(A minor side note for future readers)

I think that raising an error in this case might not be the right thing to =
do,
as this configuration could actually represent what a user wants.

For instance, for 10 or 100 Mbps LAN, where the throughput is limited by
the slow network, using fast compression can be better than disabling
compression altogether.  In this case, a user might want to avoid costly
zlib compression, but make use of LZ4 with newer clients, and that could
be done with "SVNCompression lz4".


Regards,
Evgeny Kotkov