svn - 颠覆性能调整

Question

我们有一个 3.5 Gb 的 SVN 存储库，最近从一个 6 Gb 的存储库迁移而来。我们保留所有内部制作的软件，并且有很多小的共享组件。我们也做了很多标记。项目保留其二进制依赖项的副本，主要是库。我们现在不能转移到 GIT。

我们开发人员的第一印象是 Subversion 很慢，我一直告诉他们历史相关的操作很慢，但也有优点。

访问是通过带有自定义身份验证的 mod_dav_svn 进行的。授权将通过提交后 Hook 实现，因为我们每年都会外包一些项目并需要详细的安全规则。

我们希望优化访问:

• 做了“svn pack”。
• 实现身份验证缓存。
• 准备好评估 svnserve。

我们存储库的布局如下:

\root
 \proyect1
  \trunk
   <files>
  \docs
  \branches
  \tags
   \proyect1-1.2.3-beta
    <files>
   \proyect1-1.3.0
     <files>
   etc...
 .
 .
 .
 \proyectn

是否有其他与硬件无关的优化以前显示成功？我们文件的布局会有什么不同吗？

Answer 1

我只会评论我经历过的部分。

1) 首先，它很大!通常最好将二进制文件和库保存在存储库之外，即使有时将所有内容放在一起更方便。我们有这样的项目(我工作的地方)，其中的文件在存储库中没有它们的位置，而且占据了很多位置。它会在每次结帐或重要提交时杀死服务器，其他项目都很好。

分离项目通常也是一个好主意，使用 svn:externals 你有足够的灵 active 在必要时链接它们，并且你避免了单点故障问题，巨大的存储库大小，它更容易进行备份等。

但您不能总是选择那些参数。

2) 它是 Linux Apache 服务器，还是在 Windows 上运行？我发现两者之间存在很大差异，Windows 版本往往更慢并且对配置非常敏感。

3) 我会使用 svnserve 而不是 Apache mod_dav_svn 进行测试。网络上的负载较轻，当许多人共享同一台服务器时(也取决于网络配置)，这也可能成为阻塞点。

4) 您使用的是 1.5，还是更好的 1.6？文件系统已得到改进，如果您是从以前的版本迁移过来的，执行转储/加载通常会有返回(check this link also)。我们对大型存储库进行了一些测试并获得了几个百分点，但我们观察到的情况存在很大差异。

5) 另外，你可以考虑这个(来自 Version Control with Subversion )——虽然我从来没有尝试过这种特殊的可能性:

As of Subversion 1.6, FSFS filesystems have several configurable parameters which an administrator can use to fine-tune the performance or disk usage of their repositories. You can find these options—and the documentation for them—in the db/fsfs.conf file in the repository.

6) Hook 脚本如果实现不当可能会产生影响，从而增加服务器交互的额外延迟。

7) TortoiseSVN 使用日志缓存，有时很烦人(它往往会锁定您无法删除的文件 - 如果您不知道它可能会令人惊讶)但在浏览日志时为用户提供更快的响应(除了是 Windows 上集成良好的客户端)。