1

我一直在探索有关 Mercurial 中发布管理的不同答案，并且几乎找到了正确的方法。但是，我只需要一些帮助来正确处理它，以便一切都在我的脑海中很好地点击。

这是我们公司需要的：

1）将使用版本控制方案 {major.minor.patch} 进行开发

2）命名分支和标签将用于管理发布（例如，与克隆存储库相反）

3）在发布时3.0 我们可能需要支持较旧的主要版本。例如，如果在 2.1 版中发现了一个错误，我们将需要修复它（在 2.1.1 版中）并一直合并回当前的 3.0 版

在研究了不同的选项和答案之后，Steve Losh 的以下出色答案（只是复制了下面的变更集树）可能是我们需要的，但我不知道如何在 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 合并回默认值？我在这里错过了什么吗？如果没有，是否有更适合我们的方式来根据我们的要求管理发布？如果您可以为场景提供变更集树的类似快照，那就太好了。

首先十分感谢。你们真棒。

4

2 回答 2

1

根据您维护多个发布版本的要求，我会考虑使用不同的分支策略default进行开发，并且每个主要版本都有一个分支。这在此页面上进行了描述- 它还有一个关于如何处理大修复的部分。

我已经做了一个类似于上面的例子：

@    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 版是什么，然后更新到该版本。

于 2012-06-26T07:53:01.223 回答
0

您的链接问题的第二段说：

完成 2.0 后，将 2.0-dev 合并到默认值并将结果标记为 2.0。

由此，我认为这个想法是在你3.0准备好发布它之前你不会标记它。如果您已经发布了它，那么修复程序2.1.1不会进入3.0，它会进入3.0.1并且您的工作流程不会有问题。

此外，您可以移动标签，因此如果您发现标签3.0太早，您可以使用-f标志将其移动到hg tag.

于 2012-06-22T09:53:53.893 回答