我一直在探索关于Mercurial发布管理的不同答案，并且几乎找到了正确的方法。但是，我只是需要一些帮助来使它正确，以便所有内容都能很好地点击我的脑袋。
以下是我们公司的需求：
1）将使用版本控制方案{major.minor.patch}进行开发
2）命名分支和标签将用于管理版本（例如，与克隆存储库相对）
3）在3.0版本上工作时，我们可能需要支持较旧的主要版本。例如，如果在版本2.1中发现错误，我们将需要修复它（在版本2.1.1中）并将所有方式合并到当前版本3.0中
在研究了不同的选项和答案后，Steve Losh的以下great answer（刚刚复制了下面的变更集树）可能就是我们需要的，但我无法理解你如何处理2.1.1和如果后者已被标记，则默认情况下合并回3.0;
$ hg glog -l 1000
@ changeset: 25:efc0096f47c0 tip
| summary: Added tag 3.0 for changeset d1a7fc3d7d77
|
o changeset: 24:d1a7fc3d7d77 3.0
|\ summary: Merge in the redesign changes.
| |
| o changeset: 23:b5b69d24c8f7 3.0-dev
| | summary: Finish 3.0 redesign.
| |
| o changeset: 22:4c2f98fac54b 3.0-dev
|/| summary: Merge in the latest changes to 2.1/mainline.
| |
o | changeset: 21:37df04521032
| | summary: Added tag 2.1 for changeset 39ecc520fc0a
| |
o | changeset: 20:39ecc520fc0a 2.1
|\ \ summary: 2.1 development is done.
| | |
| o | changeset: 19:208f3f9236af 2.1-dev
| | | summary: Finish the 2.1 work.
| | |
| | o changeset: 18:4a024009a9d6 3.0-dev
| | | summary: More redesign work.
| | |
| | o changeset: 17:00c416888c25 3.0-dev
| |/| summary: Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o | changeset: 16:a57e781a0db1 2.1-dev
| | | summary: More 2.1 work.
| | |
| | o changeset: 15:ddeb65402a61 3.0-dev
| | | summary: More redesign work.
| | |
+---o changeset: 14:90f5d7a8af9a 3.0-dev
| | | summary: Merge in the fire fixes.
| | |
| o | changeset: 13:78a949b67bb9 2.1-dev
|/| | summary: Merge in the fire fixes.
| | |
o | | changeset: 12:6dfe9d856202
| | | summary: Oh no everything is on fire, fix it in the mainline.
| | |
| o | changeset: 11:86767671dcdb 2.1-dev
| | | summary: Smaller changes for 2.1.
| | |
| | o changeset: 10:25dec81d2546 3.0-dev
| | | summary: Work more on the redesign.
| | |
+---o changeset: 9:42c7d689fb24 3.0-dev
| | summary: Start working on a complete redesign.
| |
| o changeset: 8:3da99186ca7d 2.1-dev
|/ summary: Start working on 2.1.
|
o changeset: 7:9ba79361827d
| summary: Added tag 2.0 for changeset 755ed5c5e291
|
o changeset: 6:755ed5c5e291 2.0
|\ summary: Merge in the dev branch for 2.0.
| |
| o changeset: 5:44a833fcc838 2.0-dev
| | summary: Finish work on 2.0.
| |
| o changeset: 4:d7ba6aae1651 2.0-dev
|/| summary: Merge in the critical fix.
| |
o | changeset: 3:968049f1b33a
| | summary: Fix a critical bug on the main branch.
| |
| o changeset: 2:917869609b25 2.0-dev
| | summary: More work on the new version.
| |
| o changeset: 1:f95798b9cb2e 2.0-dev
|/ summary: Start working on version 2.0.
|
o changeset: 0:8a3fb044d3f4
summary: Initial commit.
换句话说，使用上面的变更集树/发行版，是否可以在我们已经开始使用3.0时修复2.1.1？我的意思是如果3.0已被标记，我们如何将2.1.1合并回默认值？我在这里错过了什么吗？如果没有，是否有更合适的方式让我们根据我们的要求管理发布？如果您可以为场景提供变更集树的类似快照，那就太棒了。
非常感谢提前。你们摇滚。
答案 0 :(得分：1)
根据您维护多个版本的要求，我会考虑使用default分支进行开发的不同分支策略，并为每个主要版本分支。这在this page中有所描述 - 它还有一个关于如何处理大修复的部分。
我做了一个与上面相似的例子：
@ changeset: 13:3d6ac57cce61
|\ tag: tip
| | parent: 9:5953138c3f87
| | parent: 12:9691c48d79f2
| | user: steve.kaye
| | date: Tue Jun 26 08:39:42 2012 +0100
| | summary: Merge bug fix
| |
| o changeset: 12:9691c48d79f2
| | branch: V3
| | user: steve.kaye
| | date: Tue Jun 26 08:35:23 2012 +0100
| | summary: Added tag 3.1 for changeset e49d9a6bb459
| |
| o changeset: 11:e49d9a6bb459
| |\ branch: V3
| | | tag: 3.1
| | | parent: 7:5354c406c68a
| | | parent: 8:00dfa7869e8c
| | | user: steve.kaye
| | | date: Tue Jun 26 08:35:20 2012 +0100
| | | summary: Merge bug fix
| | |
| | | o changeset: 10:a84c532ce507
| | |/ branch: V2
| | | parent: 8:00dfa7869e8c
| | | user: steve.kaye
| | | date: Tue Jun 26 08:31:09 2012 +0100
| | | summary: Added tag 2.1 for changeset 00dfa7869e8c
| | |
o | | changeset: 9:5953138c3f87
| | | parent: 5:80b80eb9581b
| | | user: steve.kaye
| | | date: Tue Jun 26 08:30:41 2012 +0100
| | | summary: Start work on next version
| | |
| | o changeset: 8:00dfa7869e8c
| | | branch: V2
| | | tag: 2.1
| | | parent: 4:6c4a68f3c073
| | | user: steve.kaye
| | | date: Tue Jun 26 08:29:56 2012 +0100
| | | summary: Fixed a bug in V2
| | |
| o | changeset: 7:5354c406c68a
| | | branch: V3
| | | user: steve.kaye
| | | date: Tue Jun 26 08:24:52 2012 +0100
| | | summary: Added tag 3.0 for changeset 3f3a006aacdd
| | |
| o | changeset: 6:3f3a006aacdd
|/ / branch: V3
| | tag: 3.0
| | user: steve.kaye
| | date: Tue Jun 26 08:23:54 2012 +0100
| | summary: Version 3.0 ready for release
| |
o | changeset: 5:80b80eb9581b
| | parent: 2:21cf96f3ed91
| | user: steve.kaye
| | date: Tue Jun 26 08:22:47 2012 +0100
| | summary: Start work on next version
| |
| o changeset: 4:6c4a68f3c073
| | branch: V2
| | user: steve.kaye
| | date: Tue Jun 26 08:20:07 2012 +0100
| | summary: Added tag 2.0 for changeset 666cc4453281
| |
| o changeset: 3:666cc4453281
|/ branch: V2
| tag: 2.0
| user: steve.kaye
| date: Tue Jun 26 08:19:43 2012 +0100
| summary: Version 2.0 ready for release
|
o changeset: 2:21cf96f3ed91
| user: steve.kaye
| date: Tue Jun 26 08:18:31 2012 +0100
| summary: More work on the new version
|
o changeset: 1:6177b193da7c
| user: steve.kaye
| date: Tue Jun 26 08:18:06 2012 +0100
| summary: Start work on version 2.0
|
o changeset: 0:51cc3c0590f9
user: steve.kaye
date: Tue Jun 26 08:17:27 2012 +0100
summary: Initial commit
如你所见，我有三个分支。 default是新开发的地方，然后我决定它已准备好发布，所以我创建了一个V2分支并标记了它2.0。然后我继续default工作，直到我决定将其分发到V3并将其标记为3.0时就已准备好发布了。然后我发现了一个错误并发现它是在版本2中引入的，因此我将其修复到V2分支并标记为2.1。然后，我将该修补程序合并到V3并将其标记为3.1，然后将V3合并到default以获取开发代码中的修复程序。
如果从最旧的版本开始，在分支之间移植修复程序会更容易。这允许您更轻松地将该修复程序合并到较新的分支。如果您先在default中修复此问题，则无法将该修补程序合并到V2或V3，因为您将获得旧版本中的所有新功能以及错误修复。
请注意，您仍然拥有与其他分支策略一样多的头 - 一个default一个用于V2，一个用于V3但如果您保持多个，它们将会更整齐地排列版本。要获得软件版本2的最新版本，您只需要hg up V2，然后再需要找出最新版本2，然后再更新。
答案 1 :(得分：0)
您关联问题的第二段说：
完成2.0后，将2.0-dev合并为默认值，并将结果标记为2.0。
从这一点来看，我认为你的想法是，在你准备发布它之前，你不会标记3.0。如果您已将其发布，则2.1.1的修补程序不会进入3.0，它会进入3.0.1，您的工作流程也不会出现问题。
此外，您可以移动代码，这样如果您发现标记3.0太早，可以使用-f标记将其移至hg tag。