我们有一个相当大的SVN存储库。随着我们添加代码越多,执行SVN更新的时间越长越长。我们将svn:externals
添加到了某些项目中重复的文件夹,例如各个网站上的FCKeditor。这有帮助,但不是那么多。
减少更新时间和提高SVN速度的最佳方法是什么?
答案 0 :(得分:14)
如果它是较旧的SVN存储库(或者甚至是新的,但未以最佳方式设置),它可能使用较旧的BDB样式的存储库数据库。 http://svn.apache.org/repos/asf/subversion/trunk/notes/fsfs有新的注释。从一个变为另一个并不太难 - 转储整个历史记录,使用新的svn格式的文件系统重新初始化它并重新导入。同时过滤repo-dump以删除无用信息的全部签名也是有用的(例如,我删除了某人已签入的20MB + tarball文件)。
就普通速度而言 - 基于操作系统的缓存的质量(快速)硬盘和额外内存在提高SVN的工作速度方面很难出错。
在客户端,如果你通过PuttyAgent设置了torto来设置对外部存储库机器的SSH访问,你也可以启用SSH压缩,这也可以提供帮助。
编辑: SVN v1.5还有fsfs-reshard.py工具,它可以帮助将基于FSFS的svn存储库拆分为多个目录 - 这些目录本身可以链接到不同的驱动器主轴上。如果你有成千上万的修订版,那也可以提供帮助 - 如果除了找到一个文件之外没有其他原因需要花费时间(并且通过查看IOwait时间告诉你是否存在问题)
答案 1 :(得分:10)
禁止对包含工作副本代码的文件夹进行病毒检查。这导致我的更新速度提高了一倍。
答案 2 :(得分:5)
不是一个真正的答案,但知道svn之所以如此I / O重的原因之一可能是有趣的是它在.svn / text-base目录中存储了每个文件的一个额外副本。这使得本地差异操作变得很快,但是吃了很多硬盘空间和I / O.
http://subversion.tigris.org/issues/show_bug.cgi?id=525有详细信息。
答案 3 :(得分:4)
听起来你在一个存储库中有多个项目。在适当的地方拆分它们会给你带来很大的推动力。
据说Git比Subversion快得多,因为它存储/处理变化的方式,但我没有第一手经验。
答案 4 :(得分:3)
有一些常见的性能调整。 SVN的I / O非常重,因此可以选择速度更快的硬盘(两端)。为服务器添加更多内存。确保您的客户端具有经过碎片整理的硬盘(适用于Windows)。
您使用的访问方法也很重要。存储在远程文件系统上的存储库(使用file:/// access)将比使用mod_svn的svnserve或Apache慢得多。如果您在简单文件共享上拥有存储库,请考虑使用后者之一。
答案 5 :(得分:3)
确保您与服务器的连接速度很快(千兆位以太网)。 确保服务器在阵列中具有快速磁盘。 当然,只检查你需要的东西。
答案 6 :(得分:2)
默认情况下,TotoiseSVN在后台查看文件更改,我看到这会降低我的机器速度。我更改了配置以排除所有内容,然后只包括我有结帐的目录。您也可以关闭后台检查。这两个设置都位于图标叠加设置节点中。
答案 7 :(得分:2)
有时,慢速svn操作,尤其是许多外部操作,与DNS相关。 看起来svn对每个svn:external执行DNS查找,即使是相对的。 将svn服务器主机名添加到/ etc / hosts或修复resolv.conf可能很有用。
答案 8 :(得分:1)
我根据自己的经验(即:不通过任何实际测试)发现,特别是如果SVN repo服务器是远程的,使用外部设备似乎会减慢速度。如果你在多个地方都有重复的代码(比如你的FCK编辑器),我倾向于坚持使用外部,因为保持这些文件的同步和可管理性比更新速度更重要 - 但是,你可以看看使用符号链接带来而是在重复的代码中。 (如果您使用的是Windows XP,则可以使用junction points)。
答案 9 :(得分:1)
我们已将代码库拆分为多个兄弟模块,并编写了Ant脚本,以便一个开发人员可以一次处理一个模块,而不会过多地关注其他模块中发生的事情。
通常,开发人员需要每周更新整棵树几次,但在午餐/喝咖啡休息之前可以很容易地完成。
答案 10 :(得分:1)
使用读访问权限(即限制对某些人/组的读访问权限)将大大减慢存储库的速度。特别是当以某种特殊方式进行认证时,例如,针对Windows域名。 当然,对于写访问权限也是如此,但写入比阅读更少。限制写访问权限比限制读访问权限更重要
答案 11 :(得分:0)
如果存储库的根目录中有许多文件夹,并且本地副本反映了存储库,那么尝试将单片本地副本分割成许多可分离的可下载文件夹,并单独更新这些文件夹,它将比一个大文件夹快得多。