SVN性能经过多次修改

我的项目目前正在使用一个svn仓库，每天增加几百个新版本。版本库位于Win2k3服务器上，通过Apache / mod_dav_svn提供。

我现在担心，随着时间的推移，性能会因修改太多而下降。
这种恐惧是否合理？
我们已经计划升级到1.5，所以在一个目录中有成千上万的文件长期不会成为问题。

Subversion在2个版本之间存储增量（差异），所以这有助于节省大量的空间，特别是如果你只提交代码（文本），没有二进制文件（图像和文档）。

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

你有什么types的回购？ FSFS或BDB？

（现在我们假设FSFS，因为这是默认设置。）

在FSFS的情况下，每个修订版本都与之前的差异存储在一起。所以，你会觉得是的，经过多次修改，会很慢。

但是，情况并非如此。 FSFS使用所谓的“skip deltas”来避免在以前的版本中进行太多的查找。

（所以，如果你使用FSFS回购，Brad Wilson的回答是错误的。）

在BDB回购的情况下，HEAD（最新版本）修订版是全文版，但是较早的修订版是作为一系列针对头部的差异而build立的。这意味着之前的转换必须在每次提交后重新计算。

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

PS我们的回购大约20GB，大约有35000个版本，我们没有注意到任何性能下降。

Subversion将最新的版本保存为全文，并带有向后的差异。这意味着更新头脑总是很快，而且你逐渐付出的代价是越来越远。

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

我不认为日常使用会受到很大的影响，但是需要通过不同的修订来看待的东西可能会慢一点。它可能不是显而易见的。

现在，从系统pipe理angular度来看，有几件事可以帮助您将性能瓶颈降至最低。由于Subversion主要是一个基于文件的系统，你可以这样做：

将实际存储库放在不同的驱动器中
确保没有文件locking应用程序，而不是svn，正在上面的驱动器上工作
使驱动器至less7,500 RPM。你可以尝试获得10,000 RPM，但它可能是矫枉过正
如果每个人都在同一个办公室，将局域网更新为千兆位。

这可能是你的情况矫枉过正，但这就是我通常为其他文件密集型应用程序所做的。

如果你“超出”了Subversion，那么Perforce将会是你的下一步。它是最大的源代码pipe理应用程序非常大的项目。

我们正在运行一个价值数十亿字节的代码和二进制文件的颠覆服务器，而且这个服务器的修改量已经超过了两万次。没有减速呢。

Subversion只保存2个版本之间的差异（差异），所以这有助于节省大量的空间，特别是如果你只提交代码（文本）而不提供二进制文件（图像和文档）。

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

也许你担心结账时间？那么我想这将是一个networking问题。

哦，我已经用2Gb +的东西（代码，imgs，docs）在CVS仓库上工作过，从来没有性能问题。由于svn对cvs有很大的改进，我不认为你应该担心。

希望它能帮助你轻松一点;）

我不认为我们的颠覆因老龄化而减慢。目前我们有几个TeraBytes的数据，主要是二进制的。我们每天结算/提交高达50千兆字节的数据。目前我们总共有50000个版本。我们使用FSFS作为存储types，直接连接SVN：（Windows服务器）或通过Apache mod_dav_svn（Gentoo Linux服务器）连接。

我无法确认，随着时间的推移，这会让svn变慢，因为我们build立了一个干净的服务器来进行性能比较，我们可以比较一下。我们不能测量显着的降低。

不过，我不得不说，我们的颠覆行为在默认情况下是非常缓慢的，显然它是颠覆我们在另一个计算机系统尝试。

由于某些未知的原因，颠覆似乎是完全服务器CPU限制。我们的结算/提交速度限制在每个客户端15-30兆字节/秒之间，因为这样一个服务器CPU内核就完全用完了。对于我们的完整服务器（〜5 TeraByte，50000版本）来说，这几乎是空的版本库（1千兆字节，5个版本）。调整像设置压缩0 =closures没有改善这一点。

我们的高带宽（提供〜1千兆字节/秒）的FCarrays空闲，其他核心闲置和networking（目前为客户端1千兆比特/秒，服务器10千兆比特/秒）空闲。好吧，不是真的空转，但如果只有2-3％的可用容量被使用，我称之为闲置。

看到所有组件空转，并且我们需要等待我们的工作拷贝检查或者结算是没有意义的。基本上我不知道在checkout / commit期间，一直在耗费一个CPU内核的时候，服务器进程在做什么。

不过，我只是想find一种方法来调整颠覆。如果这是不可能的，我们可能需要切换到另一个系统。

因此：答：没有SVN在性能上不会降低，它起初很慢。

当然，如果你不需要（高）性能，你将不会有问题。顺便说一句。以上所有内容适用于1.7版本的最新稳定版本

唯一可能放缓的操作是从多个版本（如SVN Blame）读取信息。

我不知道…..我在Centos 5.2上使用SVN和Apache。工作正常。版本号是8230这样的东西…而且在所有的客户端机器上，提交非常慢，我们不得不等待至less2分钟的文件是1kb。我正在谈论1个没有大文件大小的文件。

然后，我做了一个新的存储库。从rev开始现在工作正常。快速。使用svnadmin创buildxxxxxx。没有检查是否FSFS或BDB …..

也许你应该考虑改善你的工作stream程。

我不知道在这些情况下回购是否会有性能问题，但是你有能力回到理性的修订版本。

在你的情况下，你可能需要包括一个validation过程，所以一个团队承诺一个团队领导者回购，他们每个人都承诺团队经理回购谁承诺只读清洁公司回购。你已经做了一个干净的select，在什么提交必须到顶部的阶段。

这样，任何人都可以回到一个干净的副本，一个简单的浏览历史。合并要容易得多，开发人员仍然可以尽其所能地完成任务。