Subversion 1.5的性能是否很糟糕？

Question

我们一直致力于一个每个人都在干线上工作的项目。该项目已达到我们的开发团队不断发展的程度，我们终于开始做客户发布（所有好东西）。因此，为了帮助协调所有这些，我们开始遵循SVN分支/合并等最佳实践。

我们面临的问题是合并时间超过20分钟，并且经常因“对等连接重置”或“PROPFIND”错误而失败。分支和合并只是一种痛苦，它们几乎无法使用。我们只有大约1000个文件，而且我们经常合并少于20个文件，但仍需要20分钟。我们正在使用Apache访问SVN。

我的问题是，这是典型的，还是我们配置错了？你的SVN存储库有多大，合并需要多长时间？

编辑：通过互联网访问服务器，我们有一些相当大的二进制文件，我们使用Mac，Linux和Windows客户端。我们不知道没有互联网或网络问题。

Answer 1

这是由于Apache，请参阅Stack Overflow问题“Svnserve VS mod_dav_svn”。

概括说明：

  

似乎鲜为人知的是，所使用的服务器变体的选择--Apache Subversion mod_dav_svn模块或独立的svnserve服务器 - 对测量和感知的颠覆性能有很大影响。通常svnserve比Apache mod_dav_svn快得多   ...............   在针对mod_dav_svn服务器的svn log和svn合并操作期间测量了最显着的性能损失 - 如果例如，您将立即注意到svn日志性能更差。使用Eclipse Subversion插件Subclipse。

Answer 2

完全披露：我和Larf一起工作，我会告诉他不要将我的答案标记为已选中，这样看起来我们不会以某种方式设置游戏系统。我当然喜欢你的赞成票：）

我们最近尝试了一些可能加速的工作，我想在Stack Overflow上捕获它。我不确定它是否适合你，但看起来它对我们有用。

背景

1. 我们的存储库最初是1.4服务器。
2. 将其转储并重新加载到1.5服务器
3. 在转储和加载期间，/ svn / Projects / Project [A | B | C]格式的主存储库被移动到许多较小的存储库/ svn / projectA，/ svn / projectB

更多症状

1. 'svn merge'喜欢随机文件和更改属性。我们有一个测试脚本文件夹（大约100个左右），由于某些原因，其中3-5个随机的属性发生了变化（prop是svn：mergeinfo）。
2. apache日志在进行合并时显示/ svn / Projects / ProjectA的建议和历史查询，尽管dir结构和名称更改发生在 long 之前。
3. 在某些项目中查看svn：mergeinfo显示了一些奇怪的东西：一些永远存在的文件显示某些标签的'标签'祖先但不是全部，其中一些有原始svn路径和新路径的祖先，有时5个以上的路径和存储库布局。
4. 我注意到另一名使用TortoiseSVN（我使用OSX命令行）的员工正在检查“忽略祖先”框，并且与我的相比，他的合并具有“正确”的apache日志。他的合并似乎也开始更快。

虽然所有这些都可能完全正常，但它们肯定听起来不像我预期的那样。

我们做了什么

1. 尝试从主代码文件夹中移出尽可能多的大型，相对静态的二进制文件。这样，dev分支就不需要克隆它们。
2. 从每个文件中删除了svn：mergeinfo属性。我们编写了一个shell脚本来执行此操作并让它运行。

后果

Larf创建了一个dev分支，然后几天后尝试将主干合并到他的分支中。以前，这种类型的合并似乎在开始合并之前停止了13+分钟。现在，它几乎立即开始并在＆lt; 4分钟。

在将代码合并到其他较旧的分支方面（因为我们删除了svn：mergeinfo），我们可能已经开枪了，但这种情况很少发生，我们愿意承担改善dev分支合并时间的风险（和所有分支都在前进）。此外，我们目前正在进行月度发布/分支，因此下一个将在其上设置正确的svn：mergeinfo属性。

Answer 3

这是一个网络问题而不是颠覆问题本身。我曾经有过它，不记得我做了什么来解决它，但快速的谷歌搜索表明它并不罕见。有些事要检查：

1. 你有代理吗？
2. 您使用的是GUI客户端吗？ 乌龟？ （如果是这样，请尝试命令 同一行的行）

我假设你可以毫无问题地svn ls和普通svn co。

Answer 4

你的文件有多大？二进制还是文字？大二进制文件会在服务器上产生大量负载。

此外，“通过对等方重置连接”表示服务器端出现了问题。你检查过服务器的负载，检查日志是否有错误？

您是否遇到其他网络应用程序（浏览器，访问网络共享）的问题？这表明网络本身存在问题。

我正在访问 Internet 上的服务器上的大型存储库（> 100'000个文件），更新最多只需几分钟！不过那是在Linux上。在本地收集文件不是Windows的优势......

[编辑]您的问题是大型二进制文件。在尝试生成xdelta时，服务器可能耗尽了处理时间或内存。我建议你阅读这篇文章：Performance tuning Subversion

Answer 5

我们拥有超过一千个文件，并且始终将大量已更改的文件与冲突合并。我从来没有真正计划合并，但如果花了超过几分钟，我会感到惊讶。也许是时候开一些热水了，但还不足以制作一杯好茶！

我们的存储库位于您的客户端计算机的哪个位置？您是否能够排除任何其他连接问题？

另外，我可能应该补充一点，我们通过SSH使用svnserve。我们一直认为，通过使用Apache来访问SVN而不是SSH，我们可以加快速度。也许我们错了！

Answer 6

可能需要获取存储库的副本并使用svnserve进行快速测试，以确定它是否更快。它可能不是一个适合您的解决方案，但它可能表明瓶颈在哪里。

使用1.5时，合并需要获取所有内容的svn：mergeinfo属性 - 这是每个文件的另一个Web调用，而apache服务从来都不知道做得快。

我们使用svnserve，svn ls -R刚刚在大约40个项目中返回了600,000多个文件。我从来没有注意到合并特别慢。

Answer 7

当我们在Subversion中存储了大量二进制文件（大小为25 MB +大小）时，我们遇到了类似的问题。我们在Apache服务停止/启动后观察到的情况，性能立即得到改善，然后在接下来的一周内缓慢下降。所以我们编写了一个脚本，它每天都会停止/启动一次Apache服务。这显着改善了事情。

我不确定这是否是您面临的问题的正确解决方案。但可能值得一试。

Answer 8

这是集中模型最终会遇到的问题，也是BitKeeper，Git，Bzr和Mercurial等系统背后的激励因素之一。