On Sat, Aug 23, 2014 at 2:36 AM, Philip Martin <philip_at_codematters.co.uk>
wrote:
> Philip Martin <philip.martin_at_wandisco.com> writes:
>
> > Mark Phippard <markphip_at_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/
Received on 2014-08-23 15:23:43 CEST