需要mercurial分支结构的帮助吗

我们刚刚从SVN切换到HG，并讨论了分支结构。我们已经提出了以下结构，需要进行一些审查，并想知道这种结构是否会在将来导致问题

                  * Tag v1.2.0
                  |
                  * Merge Branch v1.2.0 into Default 
                 /|
                / | 
               *  |
               |\ |
Merge v1.1.2   | \| 
 fixes into    |  * Tag v1.1.2
 v1.2.0 branch |  |
               |  * Merge Branch v1.1.2 into Default
               |  |\
               |  |  \
   Commit code *  |   * Commit a bug fix
               |  |   |
               |  |   |
Merge v1.1.1   *  |   * Branch v1.1.2
 fixes into    |\ |  /
 v1.2.0 branch | \| /
               |  * Tag v1.1.1
               |  |
               |  * Merge Branch v1.1.1 into Default
   Commit code *  |\
               |  |  * Commit a bug fix
               |  |  |
 Branch v1.2.0 *  |  * Branch v1.1.1
                \ | /
                 \|/
                  * Tag v1.1.0

• 每个标记代表一个版本发布
• 错误修复只发生在v0.0.x分支上
• 只有在v0.x.x分支上才会出现小的改进和小的新特性（UI的外观更新等）
• 默认分支（中心）始终具有稳定且经过测试的代码

问题:

• 将v1.2.0合并到默认分支后，我们是否能够从标记v1.1.2为v1.1.3创建一个分支，并重新设置/标记v1.1.3
• 这个结构是一个有效的结构，还是我们试图提出一些荒谬的东西，并且已经有了解决方案/答案

---

更新：在讨论了Lasse V.Karlsen提供的解决方案后，我们最终同意，在发布v1.2.0后，我们将不需要发布v1.1.3。如果我们的用户希望接收更新，他们应该更新到v1.2.0版本，v1.1.2将是v1.1.x版本的最后一次更新。这样，第一个问题就消除了。谢谢你的建议和小费

---

谢谢大家!

您将无法沿默认时间线追溯引入1.1.3作为变更集，您最好的希望是：

在发布1.1.2时更新回默认值

扩展到1.1.3并提交

将其与默认的1.1.2标记合并，这将在默认分支上创建另一个头部，与您现在正在处理的1.2时间线平行

1.1.3的标签和发布

将这个新的头合并到以前的头中，并将错误修正到1.2.x中

注意事项：我在测试时发现，当我将1.1.3默认内容合并到1.2.0默认内容时，必须合并

.hgtags

。由于标签总是从tipmost变更集中读取（这里我可能错了），这可能表明这不是最好的方法。至少我可能会等待标记，直到我将1.1.3合并到1.2.0时间线（即下图中最顶端的合并）

可以在此处找到我的测试存储库：

它看起来像这样：

* Merge Branch 1.1.3 into Default |\ | \ | * Tag v1.1.3 | | | * Merge Branch v1.1.3 into 1.1.x Default | |\ | | \ Tag v1.2.0 * | * Commit a bug fix | | | | | | Merge Branch * | * Branch v1.1.3 v1.2.0 into /| | / Default / | |/ * | + |\ | / Merge v1.1.2 | \|/ fixes into | * Tag v1.1.2 v1.2.0 branch | | | * Merge Branch v1.1.2 into Default : : *将分支1.1.3合并为默认值 |\ | \ |*标签v1.1.3 | | |*将分支v1.1.3合并为1.1.x默认值 | |\ | | \ 标记v1.2.0*|*提交错误修复 | | | | | | 合并分支*|*分支v1.1.3 v1.2.0进入/||/ 违约/||/ * | + |\ | / 合并v1.1.2 |\|/ 修复到|*标签v1.1.2中 v1.2.0分支机构|| |*将分支v1.1.2合并为默认版本 : :

---

这是否是一个好主意，还不确定，我还没有在Mercurial中管理过一个有很多类似这样的并行版本的项目。

如果每个版本都有单独的分支，并在这些分支上标记发布，而不是默认分支，是否更好？这样，我们就可以继续从旧版本开始。如果你看到我的编辑（警告），那么是的，这可能不是最糟糕的想法。然而，你真正应该做的是将这个问题发布在mercurial邮件列表上，你可能也不需要复制整个问题，只需要复制它的文本，然后在这里引用这个问题。邮寄名单在mercurial@selenic.comAdded指向我的测试存储库的链接：“tagv1.1.1”不应该是“tagv1.1.3”，而“branchv1.1.2”不应该是“branchv1.1.3”？+1，因为实际上在测试存储库中设置分支结构很麻烦。到目前为止，这是判断分支结构是否良好的最佳方法，而且不会花费太长时间。嗨，Ry4an，已经接受了。我感谢他花时间回答这个问题并详细解释了这个问题。