在hg（不是整个变更集）中共享单个文件的更改

Question

场景：

设置企业hg系统。开发人员正在开发多个分支，每个开发人员一个（或多或少）。我们松散地遵循这种模式：https://www.mercurial-scm.org/wiki/ControlledPractice。

设计/工作流约束：回购是超长期（10年以上）;回购的开发者数量在10-30的范围内。

• DevA修复了1个文件中的错误。
• DevB需要固定文件，但明确不希望DevA的其余部分工作。

这将发生lot，我们预计。

有几种方法我能想到的来处理这种情况：

1. bug修正是在一个单一的变更，它得到hg transplant“从德瓦的分支d至发展局的分支机构（或股票代码分支）。
2. 产生修复的命名分支，从DevB的开始提交产生，以便它可以干净地合并。

问题：

1. 重复的变更可能导致有关该商品的特定功能执行，混乱（但也许不是？）。
2. 在这个代码库工作了几年之后，分支机构非常流行=不可接受。

还有其他已知的方法来处理这种情况吗？

Answer 1

处理这个问题的方法是让DevA更加小心他的变​​更的父变更。在devA提交错误修正前，他应该将hg update修改为可以修复错误的最早版本（通常这是导入错误的变更集）。当Dev A提交时，他会看到一条消息，说明创建了一个新头。然后可以将新的头部拉出并合并到任何具有该错误的分支或回购站中，而不会带来任何其他问题。

关键是，当您拉动变更集时，您需要在您的回购库中找到任何变更集，这些变更集是您要更改的变更集的祖先，因此，如果您希望某人能够解决您的问题，在不做所有其他工作的情况下，只要确保修复程序的父母是他们已经拥有的变更集即可。

这确实需要开发人员稍微考虑一下，但最好是使用不同的节点标识符多次对回购库进行相同的更改，正如您注意到的那样存在问题（和丑陋）。

这些新的头像是一些人称之为“匿名分支”，并且它们不像指定分支那样繁殖。

Answer 2

如果您要将变更集从一个分支移动到另一个分支中，我会推荐transplant命令。在了解变更集来自哪里的情况下，您可以使用--log命令将一些信息附加到移植的提交消息中。例如：

hg update default 
hg transplant revX --log 

将在default创建变更与以下提交信息：

<original commit message of revX> 
(transplanted from fa10a36d94385723fc7ecfaacb189365509ee83e) 

我不知道的方式来增加使用TortoiseHg v1.1.X的--log参数，但你当然也可以从repo explorer GUI执行移植。