Re: [RFC] Using LZ4 compression by default

Stefan Sperling writes: >> With all that in mind, I propose that we do (2). Any objections? > > I want (2) as well. Thanks for doing this work, and for very clearly > and transparently describing the tradeoffs and our options. Johan Corveleyn writes: >> With

Re: [RFC] Using LZ4 compression by default

Op 19 aug. 2017 11:40 schreef "Stefan Sperling" : On Fri, Aug 18, 2017 at 10:58:13PM +0300, Evgeny Kotkov wrote: > With all that in mind, I propose that we do (2). Any objections? I want (2) as well. Thanks for doing this work, and for very clearly and transparently describing

Re: [RFC] Using LZ4 compression by default

On Fri, Aug 18, 2017 at 10:58:13PM +0300, Evgeny Kotkov wrote: > With all that in mind, I propose that we do (2). Any objections? I want (2) as well. Thanks for doing this work, and for very clearly and transparently describing the tradeoffs and our options.

Re: [RFC] Using LZ4 compression by default

(2) is the best path for USERS of subversion. More toggles is mired in risk and adding complexity. Improvements should "just work" out the box - unless there is some technical hurdle. A 25% increase in disk usage is nothing today for even a fraction more speed on operations happening thousands of

Re: [RFC] Using LZ4 compression by default

Branko Čibej writes: > Of course latency, for practical purposes, tells you how many gateways > there are between the client and the server, not what the effective > bandwidth is. Agreed. Overall, my intention here was to improve what I think is a reasonably common case with

Re: [RFC] Using LZ4 compression by default

Based on what we are seeing - disk storage is at least 10x less concerning across a huge swatch of enterprise SVN users than UX (performance and speed of developer workflows). It's becoming less and less so each quarter. Unless the disk storage increase impacts the server side performance in

Re: [RFC] Using LZ4 compression by default

Paul Hammant writes: > Wouldn't the svn client just speculatively specify a HTTP "Accepts" header > with requests up to the server? You'd be able to do back/forwards > compatibility with that, and not have to change any other wire spec ? I think that this is close to how

Re: [RFC] Using LZ4 compression by default

On 04.08.2017 15:11, Evgeny Kotkov wrote: > Branko Čibej writes: >> To make matters more interesting, when I'm working remotely, I can >> access the office SVN server either remotely through an HTTPS proxy, or >> "locally" by using our VPN ... then my IP address is on the same

Re: [RFC] Using LZ4 compression by default

Wouldn't the svn client just speculatively specify a HTTP "Accepts" header with requests up to the server? You'd be able to do back/forwards compatibility with that, and not have to change any other wire spec ?

Re: [RFC] Using LZ4 compression by default

Branko Čibej writes: >> - Using LZ4 over the wire requires both endpoints to advertise that they >>know how to deal with the new svndiff2 format that allows LZ4 compression. > > "Allows" or "requires"? I expect that anything in svndiff2 that's > compressed uses LZ4? In

Re: [RFC] Using LZ4 compression by default

On 02.08.2017 20:59, Evgeny Kotkov wrote: [...] > - Using LZ4 over the wire requires both endpoints to advertise that they >know how to deal with the new svndiff2 format that allows LZ4 compression. "Allows" or "requires"? I expect that anything in svndiff2 that's compressed uses LZ4?

[RFC] Using LZ4 compression by default

Hi all, With the recently added support for LZ4 compression (r1801940 et al), we now have an option of using it by default for the on-disk data and over the wire. For those who haven't been following this topic, here's a quick recap: - Currently, our default compression algorithm is zlib. -