将我们的存储库升级到Subversion 1.5之后不久，我的团队开始编写一个新应用程序几个月，然后突然回到我们原来的代码库。我们的开发人员在我们的服务器上使用TortoiseSVN 1.5.9和Subversion Client 1.6（仅适用于svnversion -n）和Subversion 1.5。我们的客户通过svn + ssh连接。
我们的原始代码库使用svnversion -n将SVN修订版号集成到代码中，以查询WC的当前版本。然而，突然之间，这个操作已经发展到我记得短暂的一两秒到10秒（我在VM开发环境中看到更糟糕的情况等等）我们也经历了类似的延迟回顾和实验使用Tortoise的SubWCRev和Subversion Client 1.5。
这不是一个大问题，但它肯定是一个烦恼，因为这个检查是在每次构建操作之前作为预编译步骤。因此，我喜欢在我们的反馈循环中消息几秒钟！
所以，我的问题： 我是不是已经离开了我的旧代码库太长时间，或者是否有其他人注意到此操作的延迟？
如果这种延迟是一种新现象，有人会修复它。如果是这样，怎么样？
答案 0 :(得分：4)
我同意约翰威尔登的观点。如果您使用的是Apache（http（s）），则可以减慢svn log命令的速度。这种情况发生在更改/添加了大量文件路径的提交中。一种解决方案是删除基于路径的授权或删除特定修订。有关详细信息，请参阅here：
所有这些路径检查有时可能非常昂贵，尤其是在svn log的情况下。检索修订列表时，服务器会查看每个修订中的每个更改路径并检查其是否可读。 [...]毋庸置疑，这对影响大量文件的版本来说非常耗时。这是安全成本：即使您还没有配置mod_authz_svn之类的模块，mod_dav_svn模块仍然要求Apache httpd在每条路径上运行授权检查。
答案 1 :(得分：2)
在强烈推荐的red-bean svn book中，他们声明大型提交（一次提交中的许多文件）会极大地影响性能。您最近是否签入了大量文件，比如最近100次检查？
答案 2 :(得分：1)
我刚在服务器上解决了这样的问题。你用什么认证？结帐，提交或日志操作是一系列多个HTTP请求。在日志显示的情况下，它是数百。如果你有一个auth层，它将在每个请求上进行身份验证。如果你正在对一个缓慢的后端进行打算，这会减慢你的速度。在我的情况下，我们正在对我们的IMAP服务器进行authing（自定义mod_auth_imap）。一旦我将缓存添加到auth层（保持哈希用户/传递对60秒），它就会大大加快速度：签出过去需要1.5分钟，现在需要3秒钟。
答案 3 :(得分：1)
在（正确配置的）zsh中，您可以在svn根文件夹中尝试：
sed -ns "4 p" **/.svn/entries | sort | uniq
如果您的存储库是混合的，它将提供您的最新更新的修订版或修订版列表。它不像“svnversion”那样完整，并且它可能不符合所有svn版本（我的是1.6.16），但它在某些情况下完成了工作并且速度非常快（在我的情况下为1s vs 3mn） ！）