问经过多次修订后的SVN性能

EN

你有什么类型的回购？FSFS还是BDB？

(让我们暂时假设FSFS，因为这是默认设置。)

在FSFS的情况下，每个版本都存储为与以前版本不同的版本。所以，你可能会认为，是的，经过多次修改后，它会非常慢。

然而，事实并非如此。FSFS使用所谓的“跳过增量”来避免在以前的转速上进行太多的查找。

(因此，如果您使用的是FSFS代码库，Brad Wilson的答案是错误的。)

在BDB repo的情况下，head (最新的)修订是全文的，但早期的修订是作为与HEAD的一系列差异构建的。这意味着每次提交后都必须重新计算以前的转速。

有关更多信息，请访问：http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas

附注:我们的repo大约是20 we，大约有35,000个修订版，我们没有注意到任何性能下降。

Subversion将最新的版本存储为全文，并具有向后的差异。这意味着head的更新总是很快，而且您逐渐为之付出的代价是在历史上看得越来越远。

我个人没有在实际项目中处理过代码库大于80K LOC的Subversion存储库。我实际拥有的最大的存储库大约是1.2G，但这包括了项目使用的所有库和实用程序。

我认为日常使用不会受到太大影响，但任何需要查看不同版本的东西都可能会稍微慢一点。它可能甚至不会被注意到。

现在，从系统管理员的角度来看，有一些东西可以帮助您最小化性能瓶颈。由于Subversion主要是基于文件的系统，因此您可以这样做：

• 将实际的存储库放在不同的驱动器中
• 确保除svn以外没有文件锁定应用程序在驱动器上运行
• 使驱动器至少每分钟7,500转。您可以尝试获得10,000 RPM，但如果每个人都在同一办公室，则可以将局域网overkill
• Update到千兆位。

对于您的情况来说，这可能有些过分了，但这是我通常为其他文件密集型应用程序所做的。

如果你曾经“超越”Subversion，那么Perforce将是你的下一步。对于大型项目来说，它无疑是最快的源代码控制应用程序。