经过多次修改后的SVN性能

我的项目目前正在使用svn存储库,每天可以获得数百个新版本.存储库驻留在Win2k3服务器上,通过Apache/mod_dav_svn提供.

我现在担心,由于修改过多,性能会随着时间的推移而降低.
这种恐惧是否合理？
我们已经计划升级到1.5,因此从长远来看,在一个目录中拥有数千个文件不会成为问题.

Subversion存储了两个版本之间的增量(差异),因此这有助于节省大量空间,特别是如果您只提交代码(文本)而没有二进制文件(图像和文档).

这是否意味着为了检查文件foo.baz的修订版10,svn将采用修订版1然后应用增量2-10？

1> myron-semack..：

---

你有什么类型的回购？FSFS还是BDB？

(我们现在假设FSFS,因为这是默认值.)

在FSFS的情况下,每个修订都存储为与前一个版本的差异.所以,你会认为是的,经过多次修改后,它会非常缓慢.

但事实并非如此.FSFS使用所谓的"跳过增量"来避免在以前的转速上进行太多的查找.

(所以,如果你使用FSFS回购,Brad Wilson的回答是错误的.)

在BDB存储库的情况下,HEAD(最新)版本是全文的,但早期版本是针对头部的一系列差异构建的.这意味着每次提交后都必须重新计算以前的转速.

欲了解更多信息:http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

PS我们的回购约为20GB,修订版约为35,000,我们没有注意到任何性能下降.

---

作为附注,PHP存储库存储在Subversion上(在编写本文时)295,197次修订.http://svn.php.net/repository/php/php-src/trunk/

---

这是一个有趣的信息.我有一个包含73000个文件(大约350 MB)的存储库,这是令人难以置信的缓慢.我必须询问他们正在使用什么.

2> Brad Wilson..：

---

Subversion将最新版本存储为全文,具有向后看的差异.这意味着对头部的更新总是很快,而你逐步支付的费用在历史上看起来越来越远.

---

根据这里的答案,你是对的:"Subversion使用FSFS存储库中的前向增量和BDB存储库中的后向增量"http://stackoverflow.com/questions/8824597/how-are-version-control-histories-存储-and计算

3> Hector Sosa ..：

---

我个人还没有处理过实际项目代码大于80K LOC的Subversion存储库.我实际拥有的最大的存储库大约是1.2演出,但这包括项目使用的所有库和实用程序.

我不认为日常使用会受到那么大的影响,但任何需要查看不同版本的内容都可能会慢下来.它甚至可能不明显.

现在,从系统管理员的角度来看,有一些东西可以帮助您最小化性能瓶颈.由于Subversion主要是基于文件的系统,因此您可以这样做:

将实际存储库放在不同的驱动器中

确保除了svn之外没有文件锁定应用程序在上面的驱动器上工作

使驱动器至少达到7,500 RPM.您可以尝试获得10,000 RPM,但可能有点矫枉过正

如果每个人都在同一个办公室,请将LAN更新为千兆位.

这可能对你的情况来说太过分了,但这就是我通常为其他文件密集型应用程序所做的事情.

如果你"超越"​​Subversion,那么Perforce将是你的下一步.它是非常大型项目中最快的源代码控制应用程序.