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 <br...@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 >
