我们希望将我们的团队(约10名开发人员)从SVN转移到mercurial.我们正在努力弄清楚如何管理我们的工作流程.特别是,我们正在尝试查看创建远程磁头是否是正确的解决方案.

我们目前有一个非常大的存储库,包含多个相关项目.他们共享大量代码,但项目的各个部分由不同的团队(3个团队)部署,独立于代码库的其他部分.因此,每个团队都在致力于并发大型功能.

我们目前在SVN中处理此问题的方式是分支机构. Team1有一个Feature1分支,其他团队也有同样的交易.当Team1完成更改后,它将合并到主干中并部署出来.其他团队在他们的项目完成时遵循套件,当然合并.

所以我最初的想法是在这些情况下使用命名分支. Team1使Hg中的默认分支成为Feature1分支.现在,问题就在这里.团队是否应将该分支推入其存储库中的当前/半状态.这将在核心回购中创建第二个头.

我最初的反应是“不！”因为这似乎是一个坏主意.处理我们存储库中的多个磁头听起来很糟糕,但有一些优点……

首先,团队希望设置持续集成以在其开发周期(数月之久)内构建此分支.这只有在CI可以从回购中提取此分支时才有效.这是我们现在使用SVN执行的操作,复制CI构建并更改分支.简单.

其次,它使任何团队成员更容易跳到分支机构并开始工作.如果不推动核心仓库,他们将不得不从该团队的开发人员那里获得变更集信息.也可能失去对硬件故障的本地提交.如果它是一个遵循“不要推到完成”方法的开发者的分支,那么机会会增加很多.

最后只是为了方便使用.开发人员可以随时轻松地提交和推送他们的分支,而不会产生任何后果(就像他们今天在他们的SVN分支中那样).

有没有更好的方法来处理我可能缺少的这种情况？在推进战略之前,我只想要一位退伍军人的意见.

对于错误修复,我们喜欢Mercurial的一般工作流程,匿名分支只包含1-2个提交.简单性非常适合这些情况.

顺便说一句,我读过this,这篇很棒的文章似乎更倾向于命名分支.

最佳答案 你肯定在考虑这个问题,听起来你走的是一条好路.我是克隆人的分支机构,但命名分支已经走了很长的路.

拥有一个向所有命名分支推送的中央仓库,便于控制和备份.仅在分支X上工作的团队可以通过执行hg clone -r X central-ish repo轻松创建自己的分支X仅回购.

你可以做的最好的事情就是帮助团队成功,让他们自己克隆一个位于hgwebdir.cgi实例后面的地方(因为,可能是你的中心回购会).您不仅可以找到团队,而且团队和团队将为您从未尝试过的小型工作建立自己的回购.他们会将它们放在对它们有意义的命名分支上,并在适当时合并回中央.