I was going to chime in earlier, but something in Brane’s response finally put me over the edge. We are having a very similar error when updating over VPN (the problem does not occur when in the office):
Summary of conflicts:
Text conflicts: 1
svn: E175002: REPORT request on '/hepd/Shelby/!svn/me’ failed
The issue occurs while trying to do a merge, and it happens at the point in time when a few large binaries (which take noticeably longer when doing an “svn up” because of their size) are processed. The reason I am replying is that we do have a load balancer in front of our pair of Subversion servers. I hope this helps to shed some light on this issue.
Alfred
> On Mar 10, 2015, at 2:09, Branko Čibej <brane_at_wandisco.com> wrote:
>
> On 10.03.2015 01:09, Stümpfig, Thomas wrote:
>>
>> Hi Bert, All
>> “a REPORT require on ‘/svn/…./!svn/me’ failed “ this is the only message my colleague is getting. Same message with command line tools ,
>
> I'm sorry, but there's no string like that in the Subversion 1.8.x source code. So this can't be the exact error message.
>
>> . Server side (VisualSVN) error cannot exactly be linked to the users action –perhaps this could be an enhancement to mod_dav_svn – send a transaction id in the http header and log it. The server Error very probably is: "Error writing base64 data: APR does not understand this error code [500, #620018] (We have ~300 commits per day and many more reading operations.
>> The error occurs only in WAN circumstances, and only on large updates (>2GB). In LAN environment everything is ok. The user in question has got a 100Mb/s DOCIS3.0 line IPV6 based IPV4 carrier grade nat accessing the companies network via juniper client.
>
> The error code (620018) is the canonical APR error code for "connection aborted", but the question is, what is terminating the connection (it's also strange that "APR does not understand that error code," but that's likely a different issue).
>
> So, do you have a (hardware or software) proxy/load balancer or similar on the entry point from the WAN? If yes, does it have logs you could look at?
>
>> Meanwhile I read about apache timeout,… and set this to 1800 -> 30min… I hope this fixes the issues …. I’ll keep this list informed
>
> FWIW, the kind of update you're talking about shouldn't take more than 10 minutes in the worst case over a 100Mb/s link.
>
> -- Brane
>
Received on 2015-03-10 12:18:05 CET