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/

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> - I don't see how the fact that «SVNCompression "lz4, zlib"» might 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 = ...) 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 all,
being explicit about what gets written on the disk is better.

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

>> While such approach is explicit, it also has a couple of drawbacks, as it:
>> - 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 it.

(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
Received on 2017-07-25 18:28:32 CEST