我的项目目前正在使用svn存储库，每天可以获得数百个新版本。存储库驻留在Win2k3服务器上，通过Apache / mod_dav_svn提供。
我现在担心，由于修改过多，性能会随着时间的推移而降低。 这种恐惧是否合理？ 我们已经计划升级到1.5，因此从长远来看，在一个目录中拥有数千个文件不会成为问题。
Subversion存储了两个版本之间的增量（差异），因此这有助于节省大量空间，特别是如果您只提交代码（文本）而没有二进制文件（图像和文档）。
这是否意味着为了检查文件foo.baz的修订版10，svn将采用修订版1然后应用增量2-10？
你有什么类型的回购？ FSFS还是BDB？
（我们现在假设FSFS，因为这是默认值。）
在FSFS的情况下，每个修订都存储为与前一个版本的差异。所以，你会认为是的，经过多次修改后，它会非常缓慢。
但事实并非如此。 FSFS使用所谓的“跳过增量”来避免在以前的转速上进行太多的查找。
（所以，如果你使用FSFS回购，Brad Wilson的回答是错误的。）
在BDB存储库的情况下，HEAD（最新）版本是全文的，但早期版本是针对头部的一系列差异构建的。这意味着每次提交后都必须重新计算以前的转速。
欲了解更多信息：http://svn.apache.org/repos/asf/subversion/trunk/notes/skip-deltas
附：我们的回购大约是20GB，大约有35,000个版本，我们没有注意到任何性能下降。
Subversion将最新版本存储为全文，具有向后看的差异。这意味着对头部的更新总是很快，而你逐步支付的费用在历史上看起来越来越远。
我个人还没有处理过实际项目代码大于80K LOC的Subversion存储库。我实际拥有的最大的存储库大约是1.2演出，但这包括项目使用的所有库和实用程序。
我不认为日常使用会受到那么大的影响，但任何需要查看不同版本的内容都可能会慢下来。它甚至可能不明显。
现在，从系统管理员的角度来看，有一些东西可以帮助您最小化性能瓶颈。由于Subversion主要是基于文件的系统，因此您可以这样做：
这可能对你的情况来说太过分了，但这就是我通常为其他文件密集型应用程序所做的事情。
如果你“过度生长”Subversion，那么Perforce将是你的下一步。它是非常大型项目中最快的源代码控制应用程序。
我们正在运行一个带有千兆字节代码和二进制文件的subversion服务器，它可以进行超过两万次修订。没有减速。
Subversion仅存储2个修订版之间的增量（差异），因此这有助于节省大量空间，特别是如果您只提交代码（文本）而没有二进制文件（图像和文档）。
另外我看过许多使用svn的非常大的项目，从不抱怨性能。
也许你担心结账时间？那么我想这真的是一个网络问题。
哦，我已经使用2Gb +的东西（代码，imgs，docs）在CVS存储库上工作，并且从未遇到过性能问题。由于svn对cvs有很大改进，我觉得你不应该担心。
希望它有助于你的思想一点点;）
我不认为我们的颠覆会因衰老而减缓。我们目前有几个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最新稳定版
唯一可能减速的操作是从多个修订版中读取信息的内容（例如SVN Blame）。
我不确定.....我在Centos 5.2上使用带有apache的SVN。工作正常。版本号是8230之类的东西...并且在所有客户端机器上，Commit非常慢，我们必须等待至少2分钟才能获得1kb的文件。我说的是一个没有大文件大小的文件。
然后我创建了一个新的存储库。从rev开始1.现在工作正常。快速。使用svnadmin创建xxxxxx。没检查是FSFS还是BDB .....
也许你应该考虑改进你的工作流程。
我不知道回购在这些条件下是否会出现性能问题，但你有能力回到理智的版本。
在您的情况下，您可能希望包含一个验证过程，因此团队在团队领导者回购中提交，并且每个团队都会向提交给只读清洁公司回购的团队经理回购提交。你必须在什么提交必须到顶部的阶段做出一个干净的选择。
这样，任何人都可以回到干净的副本，并且可以轻松浏览历史记录。合并更容易，开发人员仍然可以随心所欲地完成他们的混乱。