On Thu, May 14, 2015 at 1:47 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, May 13, 2015 at 9:00 PM, Clay Porter <clay.porter_at_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.stieger_at_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.
>
I have a test SVN server that I can use so I can reproduce the problem at
will but I don't know what else to do to debug the issue. There are no
errors in the web server log that indicate the problem and of course the
only errors I see on the client side are the ones I put in the original
post. I'd be glad to spend some time looking into the issue but I don't
know what else to look at.
>
> 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 ...
>
AFAIK, there are no proxy settings or firewalls between the client and
the server as this is all LAN traffic. There is antivirus and firewall
on the Windows clients but none of these exist on the Linux clients so
I don't see how it could be related to that.
I've thought about setting up another VM with a different OS and
SVN implementation, like those from Collabnet or WANDisco, but that
would require more time. I'm also open to other ways to proceed in
troubleshooting the problem.
Clay
> --
> Johan
Received on 2015-05-14 22:45:12 CEST