我最近向svn存储库提交了一个大型变更集（约7000个文件）。这7000个文件只占使用FSFS后端并与svnserve 1.7一起提供服务的存储库总大小的5%。从那以后，在这个巨大的承诺之后，签出到修订需要20倍的时间。
Subversion在内部做了什么导致了速度放缓，有办法解决这个问题吗？
更新
-
在手动检查坏的修订版时，我可以看到检查开始减慢的点。签出开始时会非常快地将文件添加到工作副本中（您无法足够快地读取tty输出）。一旦签出到达某个目录（错误的修订将向该目录添加2000个文件（该目录已包含17000个文件）），则在剩余的签出过程中，文件添加到工作副本的速度要慢得多（比如每秒5个文件）。就在坏版本之前的修订版在整个过程中都会非常快地将文件添加到工作副本中。此目录中的文件每个大约为1KB。
-
我编译了我自己的
svnserve版本，用于1.6和1.7版本——通过调试和gprof，这样我们就可以深入了解正在发生的事情。一些进一步的戳显示，svnadmin 1.7中与内存缓存相关的一些增强实际上正在扼杀它也就是说，使用svnserve 1.6为存储库提供服务可以消除这个问题。我猜这是上讨论的内存缓存http://subversion.apache.org/docs/release-notes/1.7.html#server-基于gprof配置文件的性能调整，用于在错误的修订版（以及之前的修订版）进行签出时间。在rBAD中，某些svn-fsfs-to-memory缓存函数的调用次数是rGOOD中调用次数的2000000000倍。
是的，SVN v1.7版本推出了许多性能增强。但这是基于一些普遍的假设。对于极端情况，如一次提交中有大量文件或文件大小巨大，需要根据相关说明调整预设参数。