On 14.05.2015 19:47, Johan Corveleyn wrote: > 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 ...
We had a similar report a while ago ... which turned out to be a bug in a Cisco ASA/IOS PIX, which had HTTP deep packet inspection enabled. Turns out that once its internal queue of packets is full, it'll just start dropping them. A browser user (almost) doesn't care, since she just reloads the page and hopes for the best blaming "flaky internet connection". The SVN client, on the other hand, isn't so forgiving. :) -- Brane
