Version control 使用多个磁头管理存储库的缺点是什么？

默认情况下，我有一个带有单个分支的项目。我已经在这个单独命名的分支上迭代了一段时间，并且我一直在使用标记来标记版本号里程碑

该项目的源代码在标签1.0.7和1.1.0（当前）之间发生了很大的变化。但是，1.0.7上的一些用户需要修复bug。因此，我检查了源代码，更新为标记1.0.7，实现了一个修复并提交。这被标记为1.0.8，可能是1.0.x行上的最后一次提交

我现在在默认分支上有两个头部。我预料到了。但当我试图推到我们的BitBucket帐户时，我收到了hg的警告：“推创建新的远程头”。读了这条信息，我得到了很多答案，解释了为什么信息会在那里，对大多数人来说，答案只是合并。然而，我不认为我希望在这种情况下。这两个分支不兼容

---

看起来我可以使用-f选项强制将新磁头推送到远程存储库，但是hg help和web上的各种帖子似乎都不鼓励这样做，没有解释原因。那么这样做的坏处是什么呢？似乎我仍然可以更新到我想要继续工作的任何标记/修订。如果我将该头部推到BitBucket帐户，我会以某种方式攻击自己的脚吗？

多个头部完全可以

如果有多个头部，且几乎没有关于其用途的指示，则其他人可能很难看到它们应该在哪里继续，以及包含最新发展的头部是什么，例如哪些获得了新功能

但是，通过使用分支上的标记和您一样进行清晰的版本控制，这个问题也不存在

---

不过有一个小问题：Mercurial将在克隆时更新到默认分支中的最新提交-例如，接收最后一次提交的头。如果那是你的1.0.x头，那可能是不幸的。但是，您可以通过将特殊的“@”书签附加到主线或开发头来解决此问题。Mercurial将始终更新到带有该书签的头部，如果它存在的话-无论哪个头部有最新的提交。

您的使用根本不会困扰我。我认为主要的反对意见是，克隆回购协议后，可能不完全清楚应该更新哪些变更集。