kot...@apache.org wrote on Fri, 14 Jul 2017 11:13 +:
> Author: kotkov
> Date: Fri Jul 14 11:13:47 2017
> New Revision: 1801940
>
> URL: http://svn.apache.org/viewvc?rev=1801940&view=rev
> Log:
> fsfs: Add initial support for LZ4 compression.
>
> This can significantly (up to 3 times) improve
Daniel Shahaf 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.
>
Good morning Evgeny,
First of all, thanks for the well written response.
Evgeny Kotkov wrote on Mon, 24 Jul 2017 19:19 +0300:
> Daniel Shahaf writes:
> > I'm a bit uncomfortable with this logic.
> >
> > 1. It violates the principle of least surprise: compression-level=9
> > means 'gzip -9', comp
On Tue, Jul 25, 2017 at 6:39 AM, Daniel Shahaf wrote:
> Good morning Evgeny,
>
> First of all, thanks for the well written response.
>
> Evgeny Kotkov wrote on Mon, 24 Jul 2017 19:19 +0300:
>> Daniel Shahaf writes:
>> > I'm a bit uncomfortable with this logic.
>> >
>> > 1. It violates the princip
Daniel Shahaf 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
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
> specify
Stefan Sperling writes:
> 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.
>
kot...@apache.org writes:
> Author: kotkov
> Date: Fri Jul 14 11:13:47 2017
> New Revision: 1801940
>
> URL: http://svn.apache.org/viewvc?rev=1801940&view=rev
> Log:
> fsfs: Add initial support for LZ4 compression.
> * build.conf
> (libsvn_subr): Build LZ4 library sources.
Why do we have an em
On Wed, Jul 26, 2017 at 01:18:00PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling writes:
>
> > 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:
Philip Martin writes:
> $ pkg-config lz4 --libs
> -llz4
Typo, that should be
pkg-config liblz4 --libs
The way the lz4 code is currently embedded in libsvn_subr makes it
awkward to add support for an external liblz4.
--
Philip
Stefan Sperling 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
On Wed, Jul 26, 2017 at 02:41:31PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling 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 pol
On Wed, Jul 26, 2017 at 12:36:05PM +0100, Philip Martin wrote:
> Philip Martin writes:
>
> > $ pkg-config lz4 --libs
> > -llz4
>
> Typo, that should be
>
> pkg-config liblz4 --libs
>
> The way the lz4 code is currently embedded in libsvn_subr makes it
> awkward to add support for an
Stefan Sperling writes:
>> The way the lz4 code is currently embedded in libsvn_subr makes it
>> awkward to add support for an external liblz4.
>
> I agree that an external library should be used during the build.
> It makes life a lot easier for packagers on Unix-style systems,
> and is the expe
Evgeny Kotkov wrote on Wed, 26 Jul 2017 15:48 +0300:
> And building using an embedded copy of the source isn't something new,
> as we already do that for utf8proc and with sqlite-amalgamation.
utf8proc is indeed a precedent, but sqlite is not.
- We support linking against an external sqlite lib t
On Wed, Jul 26, 2017 at 03:48:33PM +0300, Evgeny Kotkov wrote:
> Stefan Sperling writes:
>
> >> The way the lz4 code is currently embedded in libsvn_subr makes it
> >> awkward to add support for an external liblz4.
> >
> > I agree that an external library should be used during the build.
> > It m
Stefan Sperling writes:
> Who will be blamed if, in the future, a package manager for some Linux/BSD
> system fixes an exploitable bug in lz4, and accidentally leaves some systems
> vulnerable because of a missing patch to SVN's internal copy?
Let us consider Subversion's embedded utf8proc. How
Stefan Sperling writes:
> That's not what is being proposed. It's fine if the build can optionally
> use a copy provided by the user, or even a copy embedded in our code.
> But using that internal copy should not be mandatory.
I could have misinterpreted one of the previous e-mails, as I was thi
Evgeny Kotkov writes:
> on my todo list. In the meanwhile, if someone could jump in and help with
> the necessary changes to the Makefiles and etc., that would be greatly
> appreciated.
Patch in preparation...
--
Philip
Evgeny Kotkov writes:
> 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
20 matches
Mail list logo
