我们最近从6 Gb迁移了一个3.5 Gb SVN存储库.我们保留所有内部制作的软件以及许多小型共享组件.我们也做了很多标记.Projects保留了它的二进制依赖项的副本,主要是libs.我们现在不能转移到GIT.
我们开发人员的第一印象是Subversion很慢,我一直告诉他们历史相关的操作,但也有优势.
访问是通过mod_dav_svn进行自定义身份验证.授权将通过post-commit钩子实现,因为我们将一些项目外包一年并需要详细的安全规则.
我们希望优化访问权限:
我们的存储库布局如下:
\root
\proyect1
\trunk
<files>
\docs
\branches
\tags
\proyect1-1.2.3-beta
<files>
\proyect1-1.3.0
<files>
etc...
.
.
.
\proyectn
是否有其他优化与硬件无关,之前显示成功？我们的文件布局可以有所不同吗？
我只会评论我所经历过的部分.
1)首先,它很大!通常最好将二进制文件和库保留在存储库之外,即使有时将所有内容放在一起也更方便.我们有这样的项目(我工作的地方),文件在存储库中没有它们的位置,并且占据了很多位置.它是在每次结账或重要提交时杀死服务器,其他项目都很好.
通常,分离项目也是一个好主意,svn:externals如果有必要,您可以灵活地链接它们,并且可以避免单点故障问题,巨大的存储库大小,更容易进行备份等等.
但你不能总是选择那些参数.
2)它是Linux Apache服务器,还是在Windows上运行？我看到两者之间存在很大差异,Windows版本往往较慢并且对配置非常敏感.
3)我会用svnserveApache而不是Apache mod_dav_svn 进行测试.网络上的负载较轻,当许多人共享同一台服务器时(这也取决于网络配置),这也可能是一个阻塞点.
4)你使用1.5,甚至更好,1.6？文件系统已得到改进,如果您已从先前版本迁移,则执行转储/加载会得到回报(通常也请检查此链接).我们对大型存储库进行了一些测试并获得了几个百分点,但我们观察到的情况存在很大差异.
5)另外,你可以考虑这个(来自版本控制与Subversion) - 虽然我从来没有尝试过这种特殊的可能性:
从Subversion 1.6开始,FSFS文件系统具有几个可配置参数,管理员可以使用这些参数来微调其存储库的性能或磁盘使用情况.您可以在存储库的db/fsfs.conf文件中找到这些选项及其文档.
6)如果钩子脚本实施不当,可能会产生影响,从而增加服务器交互的额外延迟.
7)TortoiseSVN使用日志缓存,它有时很烦人(它往往会锁定你无法删除的文件 - 如果你不知道它可能会令人惊讶)但在浏览日志时为用户提供更快的响应(除了Windows上一个集成良好的客户端).