我的项目目前正在使用svn存储库，每天可以获得数百个新版本。 存储库驻留在Win2k3服务器上，通过Apache / mod_dav_svn提供。
我现在担心，由于修订过多，性能会随着时间的推移而降低 这种恐惧是否合理？ 我们已经计划升级到1.5，因此从长远来看，在一个目录中拥有数千个文件不会成为问题。
Subversion on存储两个修订版之间的delta（差异），这样有助于节省大量空间，特别是如果你只提交代码（文本）而没有二进制文件（图像和文档）。
这是否意味着为了查看文件foo.baz的修订版10，svn将采用修订版1，然后应用增量2-10？
答案 0 :(得分：60)
你有什么类型的回购？ FSFS或BDB？
（我们现在假设FSFS，因为这是默认值。）
对于FSFS，每个修订版本都存储为前一个版本的差异。所以，你会认为是的，经过多次修改后，它会非常缓慢。
但事实并非如此。 FSFS使用所谓的“跳过增量”来避免在以前的转速上进行太多的查找。
（所以，如果你使用FSFS回购，Brad Wilson的回答是错误的。）
在BDB回购的情况下，HEAD（最新）版本是全文的，但早期版本是针对头部的一系列差异构建的。这意味着每次提交后都必须重新计算以前的转速。
了解更多信息：http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
P.S。我们的回购大约是20GB，大约有35,000个版本，我们没有注意到任何性能下降。
答案 1 :(得分：16)
Subversion将最新版本存储为全文，具有向后看的差异。这意味着对头部的更新总是很快，而你逐步支付的费用在历史上看得越来越远。
答案 2 :(得分：5)
我个人还没有处理过实际项目代码大于80K LOC的Subversion存储库。我实际拥有的最大的存储库大约是1.2演出，但这包括项目使用的所有库和实用程序。
我不认为日常使用会受到那么大的影响，但任何需要查看不同版本的内容都可能会慢下来。它甚至可能都不会引人注意。
现在，从系统管理员的角度来看，有一些事情可以帮助您最大限度地减少性能瓶颈。由于Subversion主要是基于文件的系统，因此您可以这样做：
对于您的情况，这可能有点过头了，但这是我通常为其他文件密集型应用程序所做的事情。
如果你“超越”Subversion，那么Perforce将是你的下一步。对于大型项目，它是最快的源代码控制应用程序。
答案 3 :(得分：4)
我们正在运行一个带有千兆字节代码和二进制文件的subversion服务器，并且它有超过两万个版本。没有减速。
答案 4 :(得分：3)
Subversion仅存储2个版本之间的增量（差异），因此这有助于节省大量空间，特别是如果您只提交代码（文本）而没有二进制文件（图像和文档）。
此外，我看过许多使用svn的非常大的项目，从不抱怨性能。
也许你担心结账时间？那么我想这真的是一个网络问题。
哦，我已经使用2Gb +的东西（代码，imgs，docs）处理CVS存储库，并且从未遇到过性能问题。由于svn对cvs有很大改进，我认为你不应该担心。
希望它能让你的思绪变得轻松一点;）
答案 5 :(得分：3)
我不认为我们的颠覆会因衰老而减缓。我们目前有几个TeraBytes数据，主要是二进制数据。我们每天结账/提交最多50千兆字节的数据。总共我们目前有50000个修订版。我们使用FSFS作为存储类型，并直接连接到SVN :( Windows服务器）或通过Apache mod_dav_svn（Gentoo Linux Server）。
我无法确认这会让svn随着时间的推移而减速，因为我们设置了一个干净的服务器来进行性能比较，我们可以比较一下。我们无法测量显着的降级。
但是我不得不说默认情况下我们的颠覆是非常慢的，显然它是我们尝试使用另一台计算机系统时的颠覆。
由于某些未知原因，subversion似乎完全是服务器CPU限制的。我们的结账/提交率限制在每个客户端15-30兆字节/秒之间，因为这样一个服务器CPU核心就完全用完了。对于几乎空的存储库（1 GigaByte，5个版本），这与我们的完整服务器（~5 TeraByte，50000版本）相同。调整如将压缩设置为0 =关闭并没有改善这一点。
我们的High Bandwith（提供~1 GigaByte / s）FC-Array空闲，其他核心空闲和网络（目前客户端为1 GigaBit / s，服务器为10 GigaBits / s）空闲。好吧不是真的空转，但如果只使用2-3％的可用容量，我称之为闲置。
看到所有组件闲置并不是真正的乐趣，我们需要等待我们的工作副本签出或签署。基本上我不知道服务器进程通过在结账/提交期间一直完全消耗一个CPU核心来做什么。
然而，我只是想找到一种调整颠覆的方法。如果无法做到这一点，我们可能需要切换到另一个系统。
因此：答案：没有SVN在性能上不会降低，因为它最初很慢。
当然，如果你不需要（高性能），你就不会有问题。 顺便说一句。以上所有适用于subversioon 1.7最新稳定版
答案 6 :(得分：2)
唯一可能减速的操作是从多个修订版中读取信息的内容（例如SVN Blame）。
答案 7 :(得分：-1)
我不确定.....我在Centos 5.2上使用带有apache的SVN。工作正常。版本号是8230之类的东西...并且在所有客户端机器上，Commit非常慢，我们必须等待至少2分钟才能获得1kb的文件。我说的是一个没有大文件大小的文件。
然后我创建了一个新的存储库。从rev开始1.现在工作正常。快速。 使用svnadmin创建xxxxxx。 没有检查它是FSFS还是BDB ......
答案 8 :(得分：-2)
也许您应该考虑改善工作流程。
我不知道回购在这些条件下是否会出现性能问题，但是你能够回到理智的版本。
在您的情况下，您可能希望包含验证流程，因此团队提交团队领导者回购，并且每个团队都会向提交给只读清洁公司回购的团队经理回购提交。你必须在什么提交必须到顶部的阶段做出一个干净的选择。
这样，任何人都可以回到干净的副本，并且可以轻松浏览历史记录。合并更容易，开发人员仍然可以随心所欲地完成他们的混乱。