我的项目目前使用的是svn信息库，每天可获得数百个新修订。
该存储库位于Win2k3服务器上，并通过Apache / mod_dav_svn提供服务。

我现在担心随着时间的推移，性能会因修改过多而降低。
这种恐惧合理吗？
我们已经计划升级到1.5，因此从长远来看，在一个目录中包含数千个文件将不是问题。

Subversion on stores the delta (differences), between 2 revisions, so this helps saving a LOT of space, specially if you only commit code (text) and no binaries (images and docs).

这是否意味着为了签出文件foo.baz的修订版10，svn将采用修订版1，然后应用增量2-10？

解决方案

Subversion仅存储2个修订版之间的增量(差异)，因此这有助于节省大量空间，尤其是在我们仅提交代码(文本)而没有二进制文件(图像和文档)的情况下。

另外，我见过很多使用svn的非常大的项目，并且从未抱怨过性能。

也许我们担心结帐时间？那么我想这真的是一个网络问题。

哦，我已经使用2Gb +的东西(代码，img，文档)在CVS存储库中工作，并且从未遇到性能问题。由于svn是对cvs的重大改进，因此我不认为我们应该担心。

希望它能使头脑轻松些;)

可能会减慢速度的唯一操作是从多个修订版(例如SVN Blame)读取信息的操作。

Subversion将最新版本存储为全文，并具有后向差异。这意味着对头部的更新总是很快的，而我们增量支付的费用则在历史上越走越远。

对于我的实际项目，我个人还没有处理代码库大于80K LOC的Subversion存储库。我实际拥有的最大存储库约为1.2 gig，但这包括该项目使用的所有库和实用程序。

我认为日常使用不会受到太大影响，但是任何需要查看不同修订版本的内容都可能减慢测试速度。它甚至可能不会引起注意。

现在，从系统管理员的角度来看，有几件事可以最大程度地减少性能瓶颈。由于Subversion主要是基于文件的系统，因此我们可以执行以下操作：

• 将实际存储库放在其他驱动器中
• 确保除svn之外，没有其他文件锁定应用程序在上述驱动器上正常工作
• 使驱动器至少为7,500 RPM。我们可以尝试获得10,000 RPM，但这可能会过大
• 如果每个人都在同一办公室，则将LAN更新为千兆位。

对于情况，这可能是过大的了，但这就是我通常对其他文件密集型应用程序所做的事情。

如果我们"超越" Subversion，那么Perforce将是下一步。对于大型项目，它是最快的源代码控制应用程序。

我们正在运行一个具有数千兆字节的代码和二进制文件的Subversion服务器，它的修订版多达2万个。尚未减速。

我们有哪种回购协议？ FSFS还是BDB？

(现在假设是FSFS，因为这是默认设置。)

在FSFS的情况下，每个修订版都存储为与前一个修订版的差异。因此，我们会认为是的，经过多次修订，它会非常缓慢。

但是，事实并非如此。 FSFS使用所谓的"跳过增量"来避免在以前的版本中进行过多的查找。

(因此，如果我们使用的是FSFS存储库，则Brad Wilson的答案是错误的。)

对于BDB回购，HEAD(最新)修订版是全文的，但较早的修订版则是针对head的一系列差异。这意味着每次提交后都必须重新计算以前的转速。

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

P.S.我们的存储库约为20GB，约有35,000个修订版，并且我们还没有发现性能下降。

我不确定.....我在Centos 5.2上将SVN与apache一起使用。可以。修订号是8230之类的...在所有客户端计算机上，提交速度都很慢，以至于我们不得不等待至少2分钟才能得到1kb的文件。我说的是1个没有大文件大小的文件。

然后，我创建了一个新的存储库。从版本开始。 1.现在可以正常工作。快速地。
使用svnadmin创建xxxxxx。
没有检查它是FSFS还是BDB .....

也许我们应该考虑改善工作流程。

我不知道在这种情况下存储库是否会出现性能问题，但是我们可以恢复到理智的版本。

在情况下，我们可能需要包括一个验证过程，因此，一个团队提交一个团队负责人仓库，而每个人都提交给团队经理仓库，而后者又属于只读干净公司仓库。在此阶段，我们已经做出了干净的选择，确定哪些提交必须到达顶部。

这样，任何人都可以返回原始副本，并轻松浏览历史记录。合并要容易得多，并且开发人员仍然可以根据需要提交它们的混乱信息。