我们一直致力于一个每个人都在干线上工作的项目.该项目已达到我们的开发团队不断发展的程度,我们终于开始做客户端版本(所有好东西).因此,为了帮助协调所有这些,我们开始遵循SVN分支/合并等最佳实践.
我们面临的问题是合并时间超过20分钟,并且经常因"对等连接重置"或"PROPFIND"错误而失败.分支和合并只是一种痛苦,它们几乎无法使用.我们只有大约1000个文件,而且我们经常合并少于20个文件,但仍需要20分钟.我们正在使用Apache来访问SVN.
我的问题是,这是典型的还是我们配置错了？你的SVN存储库有多大,合并需要多长时间？
编辑:服务器是通过Internet访问的,我们有一些相当大的二进制文件,我们使用Mac,Linux和Windows客户端.没有我们所知道的互联网或网络问题.
这是由于Apache,请参阅Stack Overflow问题" Svnserve VS mod_dav_svn ".
概括:
似乎鲜为人知的是,所使用的服务器变体的选择--Apache Subversion mod_dav_svn模块或独立的svnserve服务器 - 对测量和感知的颠覆性能有很大的影响.通常svnserve比Apache mod_dav_svn快得多...............在对mod_dav_svn服务器的svn log和svn合并操作期间测量了最显着的性能损失 - 你会注意到更糟糕的svn日志性能如果例如,立即 使用Eclipse Subversion插件Subclipse.
完全披露:我和Larf一起工作,我会告诉他不要将我的答案标记为已选中,这样看起来我们不会以某种方式设置这个系统.我当然喜欢你的赞成:)
我们最近尝试了一些可能加速的工作,我想在Stack Overflow上捕获它.我不确定它是否适合你,但看起来它对我们有用.
我们的存储库最初是1.4服务器.
它被转储并重新加载到1.5服务器中
在转储和加载期间,/ svn/Projects/Project [A | B | C]形式的主存储库被移动到许多较小的存储库/ svn/projectA,/ svn/projectB
'svn merge'喜欢随机文件和更改属性.我们有一个测试脚本文件夹(大约100个),由于某种原因,其中3-5个随机更改了属性(prop是svn:mergeinfo).
apache日志显示了/ svn/Projects/ProjectA在进行合并时的建议和历史查询,尽管dir结构和名称更改很久以前发生了.
在一些项目中查看svn:mergeinfo显示了一些奇怪的东西:一些已经存在的文件永远显示某些标签的'标签'祖先但不是全部,其中一些有原始svn路径的祖先和新路径,有时5 +路径和存储库布局.
我注意到另一名使用TortoiseSVN(我使用OSX命令行)的员工正在检查"忽略祖先"框,并且与我的相比,他的合并具有"正确"的apache日志.他的合并也似乎开始更快.
虽然所有这些都可能完全正常,但它们肯定听起来不像我的预期.
试图从主代码文件夹中移出尽可能多的大型,相对静态的二进制文件.这样,dev分支就不需要克隆它们.
从每个文件中删除了svn:mergeinfo属性.我们编写了一个shell脚本来执行此操作并让它运行.
Larf创建了一个dev分支,然后几天后尝试将主干合并到他的分支中.以前,这种类型的合并似乎在开始合并之前停止了13+分钟.现在,它几乎立即开始,并在<4分钟内完成.
我们可能已经将自己的代码合并到其他旧分支(因为我们删除了svn:mergeinfo),但这种情况很少发生,我们愿意承担改善dev分支合并时间的风险(以及所有分支都在进行)向前).此外,我们目前正在进行月度发布/分支,因此下一个将在其上设置正确的svn:mergeinfo属性.
京公网安备 11010802040832号 | 京ICP备19059560号-6 