命名分支与多个存储库
我们目前在一个相对较大的代码库上使用subversion。每个版本都有自己的分支，修复是针对主干执行的，并使用svnmerge.py迁移到版本分支中
我相信现在是时候转向更好的源码控制了，我已经尝试了一段时间了。
关于使用Mercurial管理这样的发布结构，似乎有两个流派。或者每个版本都有自己的repo，并针对发布分支进行修复，并将其推送到主分支(以及任何其他较新的发布分支)。或者使用单个存储库中的命名分支(或多个匹配副本)。
在任何一种情况下，似乎我都是在使用诸如移植之类的东西来筛选包含在发布分支中的更改。
我问你，每种方法的相对优点是什么？
回答 3
Stack Overflow用户
发布于 2009-05-21 00:57:32
我认为您希望在一个代码库中记录整个历史。产生短期回购是为了短期实验，而不是像发布这样的重大事件。
Mercurial的一个令人失望的地方是，似乎没有简单的方法来创建一个短暂的分支，使用它，放弃它，并收集垃圾。树枝是永恒的。我很同情永远不想放弃历史，但超便宜的、一次性的分支是我真的希望在hg中看到的git特性。
Stack Overflow用户
发布于 2009-05-20 23:58:31
据我所知，主要的区别是你已经说过的:命名分支是在一个单一的存储库中。命名分支将所有东西都放在一个地方。单独的回购更小，也更容易移动。在这个问题上有两个学派的原因是没有明确的赢家。无论哪一方的论点对你来说最有意义，你可能都应该赞同，因为他们的环境很可能与你的环境最相似。
Stack Overflow用户
发布于 2009-11-19 21:17:37
我认为这显然是一个实际的决定，取决于当前的情况，例如功能/重新设计的大小。我认为forks对于那些还没有提交者角色的贡献者来说真的很好，他们可以通过证明他们的能力和可以忽略的技术开销来加入开发团队。
https://stackoverflow.com/questions/890723
复制相似问题