为什么svn ls-v需要比正常的svn ls长250？
我使用哪种传输方式似乎并不重要，即使使用file://schema也没什么区别。我还尝试启用memcached，但也没有任何改进。
有趣的是，在顶级目录中，这个命令是最慢的，我越深入，它就越快。一个目录中有多少项似乎并不重要。
我正在为客户端和服务器使用svn 1.7.1版本。以及FSFS回购格式。
这里的定时
svn ls -v svn://trac/koh/ 0.01s user 0.01s system 0% cpu 39.960 total
svn ls svn://trac/koh/ 0.00s user 0.02s system 6% cpu 0.243 total
svn ls可以在本地使用工作目录中的信息，而svn ls -v必须返回服务器才能获得所需的信息。它也可能是要查询的信息量。svn ls只需要文件名，而svn ls也需要修订版和最后一位作者。
然而，我发现时间不会延长250倍：
$ time svn ls
real 0m0.514s
user 0m0.046s
sys 0m0.061s
$ time svn ls -v
real 0m0.530s
user 0m0.000s
sys 0m0.109s
这种情况是发生在所有客户端上，还是只发生在您所在的机器上？这是Windows还是Unix/Linux？您要列出的目录有多大？当您执行svn ls时，工作目录是否发生了更改？或者，你一直在使用URL，所以它必须转到服务器？你注意到其他有速度问题的地方了吗？
我发现"svn ls-vsvn://svn"会导致一条"get-locks"服务器日志消息，这就是花费时间的地方。我们的存储库文件系统是NFS。会发生许多"getattr"one_answers"lookup"NFS调用。因此，出于某种原因，SVN服务器正在为get-lock进行大量属性获取。
我还没有发现这是什么原因。。。