服务器上的apache2 / dav_svn / ssl / subversion中是否有任何设置可以使大型结账时整体表现更好（或至少不消耗所有内存）？
我对如何降低内存消耗的建议特别感兴趣。
此问题的原因：
上周我们的svn服务器出现问题 - 它停止响应所有请求，管理员告诉我们所有内存都是由apache占用的。我们使用apache上的mod_dav通过ssl访问我们的subversion存储库。
内存匮乏的原因是我的一位同事正在进行大约2.5GB的检查，其中可能包含一些大小超过500MB的文件。我听说他多次尝试过，所以可能还有几个进程挂在服务器上。
服务器管理员说你不应该在subversion中存储这么大的文件，但我不同意 - 如果它们对项目很重要，我总是希望它们存储在存储库中。
答案 0 :(得分：2)
这是SVN / Apache / SSL的一个众所周知的问题
有一些解决方法，但似乎目前没有100％修复。有关详细信息，请阅读this issue。
一些建议的解决方法：
答案 1 :(得分：0)
“表现更好”和“消耗更少的记忆”在许多情况下是不兼容的。
通常在使用更多内存（例如缓存）时获得性能。因此，虽然我理解你的问题是关于如何保持较低的内存消耗，但请注意SVN会因此而变慢。
服务器管理员在SVN中保留了巨大的（他们是二进制文件？）文件是对的。 SVN主要用于源代码 - 小文本文件。如果你需要某个地方维护相关数据，输入，测试数据，资源，第三方依赖等版本。我建议你在一些共享位置创建一个二进制存储库，并使用目录结构+可能是符号链接来反映版本控制存在于你的svn回购中。
保持SVN尽可能精简（但不能更精简！）有很多优点。由于它的设计，SVN在结账时出了名的慢（例如，与分支相比，这是非常繁重的操作，非常便宜）。更快的结账和责任等转化为更快的开发周期。因此，我发现在一些备份的网络共享上“手动”维护非代码存储库，而不是在svn中保留所有，这是值得的。
还要记住，你不能在svn中真正放入你需要的所有。你没有把平台sdk放在那里，对吗？因此，使用外部存储库可以为您提供更完整的解决方案，允许您将更多内容放在那里。
在一个不相关的说明：最便宜的解决方案可能只是添加更多的RAM。我实际上已经尝试过基于“RAM-disk”的SVN存储库解决方案，而且它们的速度非常快。