我们希望将我们的团队（约10名开发人员）从SVN转移到mercurial。我们正在努力弄清楚如何管理我们的工作流程。特别是，我们正在尝试查看创建远程头是否是正确的解决方案。
我们目前拥有一个包含多个相关项目的非常大的存储库。他们共享大量代码，但项目的各个部分由不同的团队（3个团队）部署，独立于代码库的其他部分。因此，每个团队都在开发并发大型功能。
我们目前在SVN中处理此问题的方式是分支机构。 Team1有一个Feature1分支，其他团队也有同样的交易。当Team1完成更改后，它将合并到主干中并部署出来。当项目完成时，其他团队会关注套件，当然要合并。
所以我最初的想法是在这些情况下使用命名分支。 Team1使Hg中的默认分支成为Feature1分支。现在，问题就在这里。团队是否应将该分支推入其存储库中的当前/半状态。这将在核心仓库中创建第二个头。
我最初的反应是“不！”因为这似乎是一个坏主意。在我们的存储库中处理多个磁头听起来很糟糕，但是有一些优点......
首先，团队希望设置持续集成以在其开发周期（数月之久）内构建此分支。这只有在CI可以从回购中提取此分支时才有效。这是我们现在使用SVN执行的操作，复制CI构建并更改分支。容易。
其次，它使任何团队成员更容易跳到分支并开始工作。如果不推动核心仓库，他们将不得不从该团队的开发人员那里获得变更集信息。也可能失去对硬件故障的本地提交。如果它是一个遵循“不要推到完成”方法的开发者的分支，那么机会会增加很多。
最后只是为了方便使用。开发人员可以随时轻松地提交和推送他们的分支，而不会产生任何后果（就像他们今天在他们的SVN分支中那样）。
有没有更好的方法来处理我可能遗失的情况？在推进战略之前，我只想要一位退伍军人的意见。
对于错误修复，我们喜欢Mercurial的一般工作流程，匿名分支只包含1-2个提交。这种情况很简单。
顺便说一句，我读过this这篇好文章似乎更喜欢命名分支。
答案 0 :(得分：1)
你肯定在考虑这个问题，听起来你正走在一条好路上。我是克隆人的分支，但命名分支已经走了很长的路。
拥有一个向所有命名分支推送的中央回购，便于控制和备份。只处理分支X的团队可以通过hg clone -r X central-ish repo轻松创建自己的分支X回购。
你可以做的最好的事情就是让他们帮助团队克隆自己克隆在hgwebdir.cgi实例后面的某个地方（因为，可能是你的中心回购）。您不仅可以找到团队，而且团队和团队将为您从未尝试过的小型工作建立自己的回购。他们会将它们放在对它们有意义的命名分支上，并在适当的时候合并回中心。
答案 1 :(得分：1)
如果这三个项目通过这些项目之间的耦合进入一个存储库（以及在它们之间互换了多少个补丁），我会做出决定。它们越独立，将它们放在一个仓库中就越少（备份和管理除外）。有一些不同类型的设置：
所有这些情况也可以与公共部分中每个项目的自定义分支相结合。但我会尽量减少当前活动分支的数量，因为每个新分支都需要额外的合并。
我很抱歉没有给出具体答案，但“正确的事”（TM）在很大程度上取决于当地的细节。