svn - 大型变更集对 Subversion 有什么影响？

Question

我最近向我的 svn 存储库提交了一个大型变更集(约 7,000 个文件)。这 7,000 个文件仅占使用 FSFS 后端并与 svnserve 1.7 一起提供的存储库总大小的 5%。从那以后，在这次大规模提交之后，检查修订需要 20 倍的时间。

Subversion 在内部做什么导致速度变慢，有没有办法解决这个问题？

更新

在手动 check out 错误修订时，我可以看到 check out 开始变慢的点。结帐开始非常快速地将文件添加到工作副本(您无法足够快地读取 tty 输出)。一旦结帐到达某个目录(错误的修订将 2,000 个文件添加到该目录(其中已经包含 17,000 个文件))，文件添加到工作副本的速度会明显变慢(例如每秒 5 个文件)，以便在结帐的其余部分进行。就在坏版本之前的修订版在整个过程中都非常快速地将文件添加到工作副本中。此目录中的文件每个大约 1KB。

我编译了我自己的版本svnserve对于版本 1.6 和 1.7 --with-debuging 和 --with-gprof 以便我们可以深入了解正在发生的事情。一些进一步的研究表明，svnadmin 1.7 中与内存缓存相关的一些增强实际上在本次修订中将其杀死。 即，使用 svnserve 1.6 为存储库提供服务可以解决此问题 .我猜这是在 http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning 中讨论的内存缓存基于 gprof 配置文件在错误的修订版(以及它之前的一个)结帐时间。在 rBAD 中，某些 svn fsfs 到内存缓存函数的调用次数是 rGOOD 中的大约 2,000,000,000 倍。

Answer 1

是的，SVN v1.7 版本推出了许多性能增强。
但是有一些基于一般假设。对于极端情况，例如单次提交中的大量文件或文件大小巨大，需要调整发布说明中指定的预设参数。