On Wed, May 13, 2015 at 9:00 PM, Clay Porter <clay.por...@gmail.com> wrote: > Hello, > > Everything is working now (see inline below). I can't thank you enough > for your help with this. > > On Tue, May 12, 2015 at 5:21 PM, Andreas Stieger <andreas.stie...@gmx.de> > wrote: >> Hello, >> >> On 12/05/15 18:27, Clay Porter wrote: >>> svn: E175002: GET request failed: 400 Bad request >>> There is no corresponding error in the Apache HTTP logs. >>> >>> svn: E200014: Checksum mismatch for <file> >>> expected: 4b4ef9e3432aa84aed190457b68c01ad >>> actual: 863b9f52f352a5cb20298ef0eecb9e97 >>> In this case the server logs have this: >>> [Tue May 12 12:13:05 2015] [error] [client 153.65.184.225] Unable to >>> deliver content. [500, #0] >>> [Tue May 12 12:13:05 2015] [error] [client 153.65.184.225] Could not >>> write data to filter. [500, #175002] >> >> Does setting/changing SVNAllowBulkUpdates make any difference? >> https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default > > Setting SVNAllowBulkUpdates to Prefer has fixed the problem for me. > I checked the behavior using SVN clients 1.5 through 1.8 on various > platforms and all worked.
I'm glad you got it fixed. However, it's not normal that serf's skelta mode (the default for 1.8 clients, unless they get instructed by the server with "SVNAllowBulkUpdates Prefer") doesn't work. If you have the time it might be interesting to investigate this a little bit further. You should be able to reproduce the issue again, even when your server is configured with "SVNAllowBulkUpdates Prefer", by using a client with http-bulk-updates=no in its "servers" configuration file (see the release notes snippet that Andreas pointed to). This will instruct your client to never use bulk-updates mode (i.e. force skelta mode), even though the server prefers it. Some possible reasons for the error you were seeing include problems with proxies or firewalls between client and server. Or other components that interfere with the network communication, rewriting packets or things like that (e.g. antivirus components, surf shield stuff, ...). Skelta mode uses a lot more small requests/responses (instead of one huge "update response" for the bulk-updates mode), so maybe some security component on your network considers this an insecure pattern, and decides to drop things ... -- Johan
