Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> To be clear, ra_svn in current trunk is interoperable with 1.9, right?
> I.e., it doesn't use svndiff2 over the wire.
Yes, both ra_svn and svnserve currently behave as in 1.9, and only
negotiate and use svndiff0 and svndiff1.
> I'm a bit uncomfortable with this logic.
>
> 1. It violates the principle of least surprise: compression-level=9
> means 'gzip -9', compression-level=5 means 'gzip -5', but
> compression-level=1 means LZ4 (with the default acceleration_factor)
> rather than 'gzip -1'.
>
> 2. It leaves no way to use zlib level 1 in f8 filesystems. This seems
> like a decision that should be left to the admin, rather than hardcoded
> into the library.
>
> 3. What if somebody wanted to add a backend with, say, xz compression.
> (xz compression also takes levels like gzip.) Would it make sense to have
> two tunables:
> .
> compression-backend = { lz4 | zlib }
> compression-level = {1..N for lz4, 1..9 for zlib}
> .
> and then other compression backends could be easily added?
>
> This would also allow admins to set the 'acceleration_factor' of lz4.
First of all, I agree that this logic has drawbacks if observed from the
idealistic point of view:
- the choice of the compression algorithm happens implicitly, and
- it doesn't allow users to use stop using LZ4 for any reason with
the compression level set to 1.
In the meanwhile, I think that the current approach is quite pragmatic,
as LZ4 is a suitable alternative for zlib1, and considering the big picture
with a similar configuration knob in mod_dav_svn, where the choice of the
compression algorithm is tied to the negotiation of the wire format for
older clients (see below).
When I've been thinking about allowing an explicit choice of the algorithm,
I had a slightly different line of thought, opposed to "compression-backend
+ compression-level", with a single option:
compression = none | lz4 | zlib | zlib-1 ... zlib-9
(The rationale is to avoid having two dependent options; as well as that,
currently, I don't have the data showing that being able to tune the
acceleration factor of LZ4 can noticeably improve performance.)
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.
As we are lucky that LZ4 is a suitable alternative for zlib1, and that our
current configuration knobs are not tightly bound to zlib, I propose that we
keep the current logic for now and postpone the generic solution up to the
moment when we add another compression algorithm that does not fit this
scheme or requires additional configuration.
In other words, we can always do this separately, when it's absolutely needed
(say, if we find ourselves adding a compression algorithm such as zstd).
Regards,
Evgeny Kotkov
Received on 2017-07-24 18:19:51 CEST