Mercurial合并在subrepos中创建新的头

Question

我正在从事一个大型项目，其中包含一个主存储库和多个子存储库，其组织方式如下：

main-repo
    sub-a
    sub-b
    sub-c

每个工作人员都有自己的一个或多个命名分支。我在一个分支机构工作，我们称之为shastings-dev，而一个同事有一个分支，我们称之为coworker-dev。(这两个分支都存在于main-repo、sub-a和sub-b中；在sub-c中都不存在，而且我们都在使用其他人的分支来实现这个分支。)

我的问题是，如果不以某种方式创建一个新的头，我就不能再合并来自coworker-dev的更改。这一系列命令会产生意想不到的效果：

hg pull
hg branch # prints: shastings-dev
hg merge --tool internal:other coworker-dev
hg commit -m "merge coworker-dev" --subrepos
hg push

hg push打印以下消息：abort: push creates new remote head 945a60694252 on branch 'shastings-dev'! (in subrepo sub-a)

编辑其余的问题将保留完整的以下谁是真正感兴趣的所有细节。

解决方案:对于每个需要合并的子回购，将目录更改为subrepo并执行以下步骤：

hg update --clean shastings-dev
hg merge --tool internal:other coworker-dev
hg commit -m "merge coworker-dev"
hg push

(我这么做是为了subrepos sub-a和sub-b。对于sub-c，我只是运行hg update correct_branch_name，以确保它也在头上。)

然后，一旦每个子回购正确更新，返回到包含的回购，并：

hg commit -m "commit .hgsubstate after merging in subrepos"
hg push

根据这一经验，我将通过一项新规则：

如果您对子retry有问题，请始终重试各个subrepos.中的命令。

让我感到困惑的是，hg update --clean切换了所有的子记录，但实际上并没有更新它们。子记录的头与用hg branch显示的分支不同。因此，@zerkms的评论是正确的:子really实际上不在头上，合并实际上正在创建一个新的头。

换句话说，即使hg id显示主回购是在头，这并不意味着子回购正确更新，也在各自的头上。逐个检查细分程序，找出事物的真实状态。

编辑--原来问题的其余部分在下面。我的第一个想法是，我在当地复制的回购品不知何故被弄乱了。因此，我克隆了一个绝对新的回购副本，验证了hg pull没有引入任何新的内容，并再次尝试了合并/提交/推。同样的问题。

我尝试在subrepo中执行合并/提交/推送，然后在主回购中执行提交(以更新.hgsubstate)，然后在主回购中执行合并/提交/推。不是joy。

我尝试过在Windows上使用TortoiseHg克隆回购，更新到分支shastings-dev，然后合并/提交/推送。同样的问题。

所以现在我的问题是：

• 为什么要创造一个新的头？我是不是做错了什么，我的分支是不是出了什么问题，还是这是预期的行为？
• 我该怎么办？我可以消除这个多头问题吗?还是应该用-f推动，然后用hg commit --close-branch关闭两个头中较老的一个。
• 如果我使用hg push -f，会发生什么不好的事情？我个人的原则是“除非你是一个变化无常的专家，否则不要这么做”，而我不是一个变化无常的专家。(所以我的个人原则是“永远不要使用hg push -f”。)

顺便说一句，我没有处理任何同事正在处理的文件。在这个时候，我与coworker-dev的区别很小，只要我能找到一个同名的最新分支，我就愿意完全失去分支shastings-dev上的所有历史。(如果我丢失了更改，我愿意再次复制已更改的文件。我只想让Mercurial再次像预期的那样工作。)

编辑:当我做上面的事情时，我是在一个树枝头上。

$ hg heads
changeset:   1515:803ea844dc8a
branch:      coworker2-dev
tag:         tip
user:        coworker2
date:        Tue Oct 08 17:33:31 2013 -0700
files:       .hgsubstate
description:
Fixed some stuff in the foo bar.


changeset:   1513:1e76e6a43d83
branch:      coworker-dev
parent:      1509:5e5392aded0a
user:        coworker@place_where_i_work.com
date:        Tue Oct 08 16:44:04 2013 -0700
files:       foo.java bar.java baz.java quux.java
description:
Added more support to the foo bar for release.


changeset:   1422:8705d62db8f2
branch:      shastings-dev
user:        shastings@place_where_i_work.com
date:        Wed Oct 02 21:08:39 2013 -0700
files:       .hgsubstate
description:
Finish adding files

...many others not copied here...
$ hg id
8705d62db8f2 (shastings-dev)

$ hg update --clean shastings-dev
resolving manifests
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ hg id
8705d62db8f2 (shastings-dev)

$ hg merge --tool internal:other coworker-dev
...much output not copied here...

$ hg commit -m "merge coworker-dev" --subrepos
...much output not copied here...

$ hg push
pushing to https://path/to/repo/dir/main-repo
pushing subrepo sub-a to https://path/to/repo/dir/sub-a
searching for changes
new remote heads on branch 'shastings-dev'
new remote head 85d8faada6c4
new remote head 90ce145db695
abort: push creates new remote head 85d8faada6c4 on branch 'shastings-dev'! (in subrepo sub-a)
(you should pull and merge or use push -f to force)

就像我说的，当我遇到问题时，我重新克隆了一切。所以状态是清楚的:我没有修改的文件。

另外，我还有一个分支，我和另一个分支尝试了上面的序列。正如所描述的那样，这再次发生了。因此，如果有任何问题，我认为它一定是错在分支coworker-dev，而不是在我自己的分支。

Answer 1

为什么要创造一个新的头？我是不是做错了什么，我的分支是不是出了什么问题，还是这是预期的行为？

你不在分行头上，所以合并会创建另一个分支

-- A (you're here) --- B --- C (head #1)
    \
      D (merge, head #2)

因此，您需要确保您正在使用hg id和hg heads。如果没有- hg up

我该怎么办？我能消除这个多头问题吗，还是应该用-f推动，然后用hg提交关闭分支关闭两个头中较老的一个呢？

你应该解决真正的问题。见上面的建议

如果我使用hg push -f，会发生什么不好的事情？我个人的原则是“除非你是一个变化无常的专家，否则不要这么做”，而我不是一个变化无常的专家。(因此，我的个人原则是“永远不要使用hg push -f”)。

我个人的原则是--永远不要使用-f。经过4年的汞经验，我看不出有什么好的理由去使用它。可能会发生什么--一旦有两个头，hg up branchname会怎么做？hg up会怎么做？