On Sat, Aug 23, 2014 at 2:36 AM, Philip Martin <phi...@codematters.co.uk> wrote:
> Philip Martin <philip.mar...@wandisco.com> writes: > > > Mark Phippard <markp...@gmail.com> writes: > > > >> If I try this with a SVN 1.8 client and server it fails almost > immediately > >> due to connection resets. This manifests as checksum errors or hangs on > >> the client, but they can be seen in wireshark captures. If I > >> add --config-option=servers:global:http-bulk-updates=yes to the client > then > >> it works. > > > > I'm not sure if this explains your problem but the checksum/bulk-updates > > bit sounds like the server might be too old. With serf the GET response > > can be a delta agains a particular revision as specified in the > > X-SVN-VR-Base header, but before 1.6.20 and 1.7.8 mod_dav_svn does not > > send a Vary header to tell a caching proxy that the response depends on > > X-SVN-VR-Base. If the proxy caches the response for one X-SVN-VR-Base > > and returns it for another X-SVN-VR-Base the client should fail with a > > checksum error. > > Thinking a bit more, that's probably not relevant. The client generally > won't use GETs unless the server is 1.8 and 1.8 does send the Vary > header. > I do not believe the checksums are the problem. The issue is the connection resets. The checksums are just what SVN surfaces after receiving incomplete data. I was mainly wondering if haproxy just does not work with SVN. Have since just moved on to nginx which does not have these problems. -- Thanks Mark Phippard http://markphip.blogspot.com/
