我最近向我的 svn 存储库提交了一个大型变更集（约 7,000 个文件）。这 7,000 个文件仅占使用 FSFS 后端并使用 svnserve 1.7 提供服务的存储库总大小的 5%。从那时起，在这个大型提交之后检查修订需要 20 倍的时间。
Subversion 在内部做了什么导致速度变慢，有没有办法解决这个问题？
更新
在手动检查错误修订时，我可以看到结帐开始变慢的点。结帐开始非常快速地将文件添加到工作副本（您无法足够快地读取 tty 输出）。一旦结帐到达某个目录（错误的修订版本将 2,000 个文件添加到该目录（其中已经包含 17,000 个文件）），文件被添加到工作副本的速度明显变慢（例如每秒 5 个文件），以便结帐的其余部分。坏版本之前的修订版在整个过程中非常快速地将文件添加到工作副本中。此目录中的文件每个大约 1KB。
我为版本 1.6 和 1.7 --with-debuging 和 --with-gprof 编译了我自己的版本，
svnserve以便我们可以深入了解正在发生的事情。一些进一步的研究表明，在 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 倍。