SVN error running context: An existing connection was forcibly closed by the remote host

I've created an SVN repo on my Debian Wheezy build server following this tutorial. svn --version gives 1.6.17.

Sadly, I can't commit anymore to the repo from my Windows 7 machine; it fails with the following error message:

Transmitting file data .svn: E730054: Commit failed (details follow):
svn: E730054: Error running context: An existing connection was forcibly closed
by the remote host.

I have had this error both with TortoiseSVN and the command line client.

These are the contents of /var/log/apache2/access.log on the server for the time of the failed commit: access.log. There is no entry for the same time in the error log.

I'm still able to check out the contents of the repo and svn info http://myurl/svn/myrepo works also fine.

The Debian server with the repo is running inside a VM on a Windows Server 2008 R2 (Hyper-V-Manager 6.1). The connection from my Windows machine to the Windows Server is established using FortiClient 4.2.8.0307.

After I ran into this error yesterday, I purged svn from the server and setup the repo again. This made the repo accept commits for a couple of hours until it failed again with the same error.

Currently commits work again with TortoiseSVN but fail with the command line client.

What does E730054 mean and how can I fix it for good?

I have upgraded to Jessie in the meantime, but the situation did not improve. Commits with Tortoise stopped working again, meaning that it hangs at the "Sending Content" action for about five minutes and then prints the error that's in the title.

Checkouts still work without a hitch, though.

apache2 -v:
Server version: Apache/2.4.9 (Debian)
Server build: Mar 29 2014 21:52:01

svn --version:
svn, version 1.8.8 (r1568071)
compiled Apr 1 2014, 03:41:42 on i486-pc-Linux-GNU

Here's a thread that discusses the error, but I could not conclude a solution for my problem from it.

I noticed that the problem occurs when I want to commit the second modification of a file.

My fix

The issue went away permanently after using svnserve instead of apache2. This tutorial helped me set it up.

Solution

As I was reading over the thread, it seems like some problems in the WEBDAV implementation on client site crashing the apache-thread. I had other issues with pre 1.8 repositories and I solved most of them by dump/reload the whole repository into a new one (using "svnadmin upgrade" is not sufficient!). Pre 1.8 repos have sometimes "corrupt/obsolete" data in revision files which is ignored by clients. It seems that this could cause the segfault.

You can dump/reload your repository like this:

svnadmin create newrepos
svnadmin dump oldrepos | svnadmin load newrepos

Note that it could take a tremendous amount of time to perform an update/reload cycle (approx. 1GB/h +- 50% depending mostly on disk speed).

If you have a different time, please post your time, I am doing a private research of dump/reload cycle performances.