为什么 mercurial 会在工作副本中合并提交的更改？答案

【问题标题】：Why does mercurial merge committed changes in the working copy?为什么 mercurial 会在工作副本中合并提交的更改？
【发布时间】：2010-09-17 23:49:47
【问题描述】：

我已经使用 Mercurial 几个星期了，但不明白为什么 Mercurial 合并来自两个存储库的已提交更改时，它会在工作副本中这样做？

当然可以在不使用工作副本的情况下进行合并，从而无需搁置更改等。

似乎没有必要涉及工作副本。我错过了什么吗？

【问题讨论】：

一般来说，ALL 更改会在您提交之前发生在工作副本上。合并也不例外。合并“来自两个存储库”和“需要上架更改”是什么意思？你能举一个工作流程的例子吗？
我一直在使用以下工作流程 blogs.sun.com/tor/entry/… 将存储库的合并与对您的更改的合并隔离开来
再试一次。我一直在使用以下工作流程blogs.sun.com/tor/entry/mercurial_tip_checking_in_regularly，它对我来说将存储库的合并与将更改合并到您的工作副本中隔离开来（无需搁置）。除非在我拉入 Tor 所谓的同步 repo 时存在冲突，否则进程中的 fetch 是自动的。我的问题是为什么我需要这个额外的存储库？难道 mercurial merge 不能在工作副本以外的地方提交更改吗？

标签： mercurial

【解决方案1】：

每个存储库只有一个工作副本by definition：

工作目录是存储库中的顶级目录，其中文件的普通版本可供读取、编辑和构建。

除非你的文件系统是薛定谔猫的后代，否则你不能同时拥有同一个文件的两个版本，因此你不能拥有两个工作副本。

尽管如此，理论上确实可以使用诸如临时克隆之类的东西（根据@Ry4an）充当合并的工作副本，在那里解决冲突，提交，然后使其消失。你会得到一个漂亮的合并变更集和完整的工作副本。

我可以想到几种方法来实现这一点：

我强烈推荐#4，因为我会推荐几乎所有的工作流程场景。我花了几天时间去摸索 MQ，但一旦我做到了，我就再也不用回头了。

在 MQ 工作流中，您的工作副本始终是当前补丁。因此，对于合并情况，您会这样做：

您不必弹出 #2 中的所有补丁。每当我需要处理真正的变更集以避免将它们与补丁混淆时，我总是这样做。

解决方案 #3 与 #4 完全相同，因为根据定义，补丁是一个临时变更集（这实际上是您理解 MQ 所需的唯一内容）。这只是不同的命令：

如果您想保留工作副本变更集并继续提交，只需在 #5 中更新即可。

从您的问题看来，您似乎已经知道 #4 但不喜欢搁置。我认为搁置很好，因为合并是一项与编码（更改工作副本）根本不同的任务，搁置使上下文切换明确且安全。

【讨论】：

“我会因为引用使徒乔尔而获得 1k 代表吗？”......也许不会。只需 +1 即可获得完整答案；）
很好的答案，你说得对，我不喜欢搁置。在我开始在繁忙的开发环境中使用 Mercurial 之前，搁置是很好的。从那以后，由于搁置中的文件在合并过程中发生了变化，因此我遇到了很多未搁置的中止。这意味着我认为所谓的差异文件的变基（读取.hg中搁置文件的编辑）。我认为 MQ 会遇到与基于补丁的类似问题吗？认为答案可能是简单地克隆单个功能。
每个功能一个克隆是一个可行的工作流程，但有其自身的问题（例如，请参阅我关于 hg 工作流程的问题stackoverflow.com/questions/3719019/…）。如果您在新的基础上重新应用补丁并且存在冲突，MQ 会保存冲突的块并且您需要解决它。我认为这是必要的痛苦，因为你想知道并解决这种冲突。 BTW hg rebase 可以直接使用已应用的补丁并调出合并工具来解决冲突。
你什么时候会在 StackOverflow 中提出另一个问题？我已经非常简要地查看了 hg rebase。我看到很多人神秘地提到它很危险，但我不确定具体是怎么回事。
欢迎提出其他问题。如果他们不喜欢它，人们会杀死它:) rebase 通常被认为是危险的，因为它会改变历史，但它与补丁一起使用是完全合法的，因为补丁不是永久性的。

【解决方案2】：

我没有写 Mercurial，所以我不能说他们为什么这样做，但以下是该决定的一些积极结果：

如果您真的想进行合并，并且在工作目录中有无法提交的内容，请不要打扰搁置，只需执行以下操作：

cd ..
hg clone myrepo myrepo-mergeclone
hg -R myrepo-mergeclone merge
hg -R myrepo-mergeclone push myrepo

在同一个文件系统上，克隆几乎是即时的，并且在后台使用硬链接，因此它几乎不占用临时工作副本之外的空间。

【讨论】：

我唯一担心的是：如果存在重大冲突，您可能想要测试合并，但测试不同的存储库可能需要大量设置，如果您在 myrepo 中进行测试，您将回到原点1.
Geoffrey，是的，保留一个名为 CURRENT 的符号链接，我指向我的即时存储库，我在所有 PATH 和测试配置中都使用它，但我认识到使用一些会更容易工具链比其他工具链。

【解决方案3】：

如HgInit的“合并”一章所述：

合并命令，hg merge，将两个头合并。
然后它将结果留在我的工作目录中。
它没有提交它。这让我有机会检查合并是否正确。

此类检查可能包括合并中的冲突，用户必须查看：

在 KDiff3 中，您会看到四个窗格

左上角是原始文件。

顶部中心显示 Rose 她的版本。

右上角显示 Rose 我的版本。

底部窗格是一个编辑器，Rose 在其中构建已解决冲突的合并文件。

因此，您需要一个工作目录（合并视图）才能完全解决合并问题。

【讨论】：