如何在Mercurial中自动合并.hgtags？

我有一个脚本，在构建服务器上以非交互模式运行一些Mercurial命令。其中一个命令合并两个分支，合并期间，

.hgtags

文件中始终存在冲突，因为构建脚本的设置方式不同

---

如何强制Mercurial始终使用两个文件的更改合并

.hgtags

文件，先从一个文件合并，然后从另一个文件合并

例如，如果要合并的文件是

A
B
C

A
B
C

及

我希望结果是

A
B
C
D

---

我猜我需要一个自定义合并工具。什么工具提供了这个功能？

你应该试试，它太棒了

您无法通过执行无人参与的合并来自动解决合并冲突。如果不进行合并（即选择“仅我的”或“仅其他”），它将起作用

很抱歉，您的工作流程规划得很糟糕-生成服务器不能执行任何修改源的操作。这是人类的任务，也是人类的选择

但我想，确切的数据在.hgtags中必须对构建服务器有价值（它使用自己的克隆，我希望没有填充给任何人？！），因此您可以在命令中定义任何合并策略并合并（错误，数据丢失）。hgtags合并

---

顺便说一句，“先从一个，然后从另一个”在任何语言中，只使用形式逻辑，对于pair

及

意味着

ABCABD

结果

请参阅Magras de La Mancha提供的关于Mercurial 3.1的更好解决方案。下面是针对Mercurial旧版本的更简单、更幼稚的解决方案

---

是的，您需要为

.hgtags

文件配置自定义标签。Mercurial没有为

.hgtags

提供任何特殊的合并工具，您需要使用普通的三向合并工具手动合并

.hgtags

文件中的冲突可以有两种类型：

• 愚蠢的冲突：这就是你的情况，这里没有真正的冲突。发生的是一个分支

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 C
  

  而另一个分支

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 C
  

  每个标记只引用一个变更集，因此这里没有冲突。合并当然应该是两个文件的并集：

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

• 真正的冲突：只有一个分支

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 C
  

  而另一个分支

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 D
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  12e0fdbc57a0be78f0e817fd1d170a3615cd35da C
  

  f40273b0ad7b3a6d3012fd37736d0611f41ecf54 A
  0a28dfe59f8fab54a5118c5be4f40da34a53cdb7 B
  979c049974485125e1f9357f6bbe9c1b548a64c3 C
  

  这里有一个真正的冲突：

  hg tag C

  在两个分支上都完成了，但是标记引用了不同的变更集。解决此问题是一项手动任务

如果您可以保证只有愚蠢的冲突，并且每个变更集只有一个标记，那么您可以使用

hg log -r "tagged()" --template "{node} {tags}\n" > .hgtags

生成新的

.hgtags

文件。关键是Mercurial知道如何在内部合并标签！当您有两个具有不同

.hgtags

文件的磁头时，它会一直这样做。上面的模板只是基于此内部合并生成一个新的

.hgtags

文件

如果每个变更集可能有多个标记，则上述操作无效-所有标记都打印在一行上，因此您将获得一个标记

foo bar

，而不是两个标记

foo

和

bar

。然后，您可以使用此选项：

它为每个标记输出一行，而不是变更集。将此样式保存在某个位置并配置合并工具：

[merge-tools]
hgtags.executable = hg
hgtags.args = log -r "tagged()" --style ~/tmp/tags-style > $output
hgtags.premerge = False
hgtags.priority = -1000

[merge-patterns]
.hgtags = hgtags

现在您有了自动标记合并。有一些警告：

三个或更多的头：只有在合并时有两个头时，该技术才有效。如果您有三个头或更多头，则删除的标记可能会重新出现。如果您有X、Y和Z头，并且标签

A

在X中被删除，那么Mercurial通常能够判断出

A

被整体删除。它是基于X中

.hgtags

文件中的

000…0a

行执行此操作的。但是，如果将X和Y合并为W，则建议的方法将不包含任何此类

000…0a

行。Z中

A

的定义现在将突然生效，并重新引入

A

真正的冲突：如果您在

.hgtags

中有真正的冲突，那么上述方法将为您从最近的头中自动拾取标签。合并工具基本上将

hg标签

保存在

.hgtags

中，并且具有多个头部的

hg标签

的行为非常简单。由于

hg tags

无条件地读取并静默地合并来自所有头部的

.hgtags

文件，因此我们无法用这种简单的方法来处理它。处理这个问题需要一个更大的脚本来读取两个

.hgtags

文件并检测冲突

---

实际上，您不需要合并.hgtags文件。不同分支上的标记可能不同，Mercurial将正确列出所有分支上的所有标记

我们使用来告诉Mercurial在合并.hgtag时使用本地分支。将以下内容添加到存储库的hgrc文件：

 [merge-patterns]
 .hgtags = internal:local

当执行涉及.hgtags文件的合并时，.hgtags将显示为已修改，但不会更改。

Mercurial 3.1（2014-08-01）引入内部：tagmerge。它被标记为实验性的，所以要小心。 以下是本文的序言（如果您点击链接，您可以找到有关算法的更多详细信息）：

添加一个新的内部：tagmerge合并工具，该工具为mercurial的标记文件实现自动合并算法

tagmerge算法能够解决当前会触发.hgtags合并冲突的大多数合并冲突。它不能（也不能）处理的唯一情况是，两个标记指向每个合并父级上的不同修订，并且它们对应的标记历史具有相同的等级（即相同的长度）。在所有其他情况下，合并算法将选择属于具有最高等级标记历史的父项的修订。合并的标记历史是两个标记历史的组合（特殊