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/

On Mon, Jul 24, 2017 at 07:19:09PM +0300, Evgeny Kotkov wrote:
> However, there are a couple of difficulties with porting this approach to
> mod_dav_svn, i.e., if we introduce the SVNCompression directive. There
> are clients that don't use LZ4, so, presumably, this options would require
> specifying all formats that a server can use, in the preferred order:
>
> SVNCompression "lz4, zlib"
>
> 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.

Does mod_dav_svn really need an option for this?

Can't lz4 (svndiff2) be negotiated as a mutual protocol capability of
client and server? Why won't a simple logic such as the following work:

  If the client announces lz4 compression level 1 support, use it.
  Else, use zlib.

As an admin or user my expectation would be that clients and servers pick
the most suitable protocol automatically. At best, options I set should
indicate what I think the ideal protocol configuration would be, but if that
won't work (e.g. because an old client conencts) I would expect a fallback.

I think we should also consider which decision people who are not experts
will make if we give them such options. I would expect many admins would
use a logic such as:

  lz4 is better (newer) than zlib!
  compression level 9 is better than level 1!

and then set their server to lz4 with compression-level 9...

Not even having to think about any of these options is much better
for our users and saves them time.
Received on 2017-07-26 11:56:05 CEST