SVN错误运行上下文:一个现有的连接被远程主机强行关闭 [英] SVN error running context: An existing connection was forcibly closed by the remote host

问题描述

我在我的 Debian Wheezy 构建服务器上创建了一个 SVN 存储库，遵循 本教程.svn --version 给出 1.6.17.

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

遗憾的是，我无法再从我的 Windows 7 机器上提交代码库了；它失败并显示以下错误消息:

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.

我在使用 TortoiseSVN 和 命令行客户端时都遇到过这个错误.

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

这些是提交失败时服务器上 /var/log/apache2/access.log 的内容:access.log.错误日志中没有相同时间的条目.

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.

我仍然可以查看 repo 的内容，并且 svn info http://myurl/svn/myrepo 也可以正常工作.

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

带有 repo 的 Debian 服务器在 Windows Server 2008 R2 (Hyper-V-Manager 6.1) 上的 VM 内运行.从我的 Windows 机器到 Windows Server 的连接是使用 FortiClient 4.2.8.0307 建立的.

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.

在我昨天遇到这个错误后，我从服务器中清除了 svn 并再次设置了 repo.这使得 repo 接受了几个小时的提交，直到它再次失败并出现相同的错误.

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.

目前再次使用 TortoiseSVN 提交工作，但使用 命令行客户端失败.

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

E730054 是什么意思，我该如何永久修复它?

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

在此期间我已经升级到 Jessie，但情况并没有改善.与 Tortoise 的提交再次停止工作，这意味着它在发送内容"操作处挂起大约五分钟，然后打印标题中的错误.

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:
服务器版本:Apache/2.4.9 (Debian)
服务器搭建:2014年3月29日21:52:01

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

svn --version:
svn，版本 1.8.8 (r1568071)
在 i486-pc-Linux-GNU 上于 2014 年 4 月 1 日 03:41:42 编译

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.

改用 svnserve 后问题永久消失apache2.本教程帮助了我设置它.

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

推荐答案

当我阅读线程时，似乎客户端站点上的 WEBDAV 实现中的一些问题使 apache 线程崩溃.我在 1.8 之前的存储库中遇到了其他问题，我通过将整个存储库转储/重新加载到一个新存储库解决了其中的大部分问题(使用svnadmin upgrade"是不够的！).Pre 1.8 repos 有时在修订文件中有损坏/过时"的数据，这些数据会被客户端忽略.看来这可能会导致段错误.

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

请注意，执行更新/重新加载周期可能需要大量时间(大约 1GB/h +- 50%，主要取决于磁盘速度).

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.

这篇关于SVN错误运行上下文:一个现有的连接被远程主机强行关闭的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！