TortoiseSVN checkout failed error svn: E120106: ra_serf: The server sent a truncated HTTP response body答案

【问题标题】：TortoiseSVN checkout failed error svn: E120106: ra_serf: The server sent a truncated HTTP response bodyTortoiseSVN checkout failed error svn: E120106: ra_serf: The server sent a truncated HTTP response body
【发布时间】：2013-10-13 15:34:37
【问题描述】：

TortoiseSVN 在结帐操作期间显示错误svn: E120106: ra_serf: The server sent a truncated HTTP response body。如何解决问题？

【问题讨论】：

请添加更多细节...例如，您使用的是哪个乌龟版本，哪个版本有颠覆服务器。
其他人可能会遇到相同的错误，但会进行合并。降级客户端解决了这个问题。
在 SVN 1.9.3（windows，命令行）中仍然存在问题
见stackoverflow.com/a/36180657/761095

标签： svn tortoisesvn

【解决方案1】：

然后更新而不是再次签出...不要删除已签出的副本，只需再次更新即可。

【讨论】：

这并没有提供问题的答案。要批评或要求作者澄清，请在他们的帖子下方发表评论 - 您可以随时评论自己的帖子，一旦您有足够的reputation，您就可以comment on any post。
@Sathish，说实话，说这不能提供问题的答案是不正确的。本身没有“问题”。
Sathish - AlexChe 确实提供了一个答案并且它有效。
这是一个有用的答案。你想签出一个 repo，但你得到了一个错误。使用此解决方法，您将能够完成结帐。

【解决方案2】：

来自 TortoiseSVN 开发者的一些 ideas：

发送的数据太大导致服务器关闭连接达到极限。

可以帮助解决此问题的可能步骤：

增加服务器的超时值

在服务器上将压缩级别设置为零（这会使一切变慢但有助于解决此问题）

确保您和 svn 服务器之间的所有代理也增加了超时值

【讨论】：

你会发现如何增加超时here。
客户端和 Visual SVN 服务器的设置 here.

【解决方案3】：

SVN 1.8 包含一个新的 HTTP 客户端库 (Serf)。

我认为这是造成这种情况的原因。我已经安装了TortoiseSVN-1.8.6.25419-x64-svn-1.8.8.msi 并执行svn merge 给出了同样的错误。最初我虽然这是 svn 服务器超时的问题，但相同的合并操作适用于 1.6。所以我想问题出在 SVN 1.8 及更高版本上。 请将您的 svn 客户端版本恢复到 1.7 或 1.6 并尝试！

【讨论】：

这里已经提出了错误，但似乎回到 1.7 是目前唯一的选择。 sourceforge.net/p/tortoisesvn/tickets/678

【解决方案4】：

在 SVN 配置文件中设置以下键值。就是这样。

DeflateCompressionLevel 5

1 是最小值。 9 是最大值。

【讨论】：

“就是这样”什么？您认为它将如何解决问题？

【解决方案5】：

错误Error: ra_serf: The server sent a truncated HTTP response body 可能发生在检查大目录或客户端磁盘非常慢时。据我所知，问题已在 Subversion 的代码中得到解决（例如，参见 r1886490）。该修复程序应包含在下一个 Apache Subversion 版本中。修复发布后，您需要升级 Subversion 客户端以解决问题。

问题在 Apache Subversion SVN-3264 的问题跟踪器中有一张票。

在所有其他情况下，当您收到错误服务器发送了截断的 HTTP 响应正文时，考虑以下一般故障排除步骤是有意义的：

确保使用最新和最新的 Subversion 客户端版本。
确保您可能已在客户端或服务器计算机上安装的防病毒软件不会干扰 Subversion HTTP(S) 流量。您必须添加例外/排除规则，以禁用与您的 Subversion 服务器之间的访问或流量扫描。例如，请参阅文章KB171: Configuring antivirus exclusions for VisualSVN Server。
确保您可能在客户端计算机和 Subversion 服务器之间使用的代理正常工作，并且不会过早终止连接。
请与您的系统管理员联系，检查网络是否存在连接问题。

【讨论】：

【解决方案6】：

我遇到了同样的问题，但在我们的 CI 系统 teamcity 环境中。一些脚本确实执行手动 svn checkout 并导致此错误，而不是使用 teamcity 本身结帐。

在大型存储库上取消内部 SVN 清理检查以进行工作通过脚本而不是内置使用 svn.exe 复制格式 1.7 带有消息的 teamcity SVN：“svn：E120106：ra_serf：服务器发送截断的 HTTP 响应正文。”

无论工作副本格式如何，都可以对小型存储库进行干净签出
使用工作副本格式 1.5 对大型存储库作品进行干净签出
使用导出代替结帐工作
使用 teamcity 8.1.5 内部 svn 客户端工作（不知道为什么）
使用 svn 客户端 1.7 而不是 1.8 会导致类似的超时相关错误：“svn: E175002: REPORT of '/!svn/me': could not read response body: Secure connection truncated”

增加服务器上的 SVN 超时值确实解决了这个问题，此后“ra_serf”和“安全连接被截断错误”都没有发生。

Aniket Thakur 关于恢复 svn 客户端版本的建议确实对这个问题产生了影响，但我无法找到正确的版本。（如果有的话）

Sanmat Jhanjhari 提出的降低压缩级别的建议不仅是公认的解决方案的一部分，而且它可能会起作用的原因是它可以保持 SVN 服务器和客户端之间的响应时间稳定，并且压缩大文件不再导致超时。

将工作副本更改为 1.5 是客户端解决此问题的唯一替代方案。这个工作的原因很可能与数据压缩的方式有关，但我无法弄清楚确切的原因。

如果您只对数据本身感兴趣并且不需要将其作为存储库，则使用导出是一种可怕的客户端替代方案。不过，出口行为略有不同。例如，它不会覆盖现有文件。我也想不通为什么这与正常结帐相比有效。

【讨论】：

【解决方案7】：

不正确的代理设置可能会导致相同的错误消息。

我在结帐期间的不同时刻遇到了完全相同的错误。前几个文件总是成功，但在 5-10 个文件之后出现 ra_serf 错误。大小文件也是如此。

经过一些试验和错误（其他硬件、有线连接）后，我离解决方案更近了。我决定检查所有 Tortoise SVN 设置并找到简单的答案：我的代理设置不正确！

【讨论】：