在 hg 中共享单个文件的更改（而不是整个更改集）
场景：
建立企业汞系统。开发人员正在多个分支上工作，每个开发人员一个（或多或少）。我们大致遵循这种模型：https://www.mercurial-scm.org/wiki /受控练习。
设计/工作流程限制：回购协议是超长期的（10年以上）；回购协议上的开发人员数量在 10-30 范围内。
- DevA 修复了 1 个文件中的错误。
- DevB 需要固定文件，但明确不想要 DevA 的其余工作。
我们预计，这种情况将会发生很多次。
我可以想到几种方法来处理这种情况：
- Bugfix 位于单个变更集中，它从 DevA 的分支移植到 DevB 的分支（或共享代码分支）。
- 为修复生成一个命名分支，从 DevB 的开始提交生成，以便可以干净地合并。
问题：
- 重复的变更集可能会导致对给定功能的实现位置产生混淆（但也许不是？）。
- 经过几年的代码库工作后，分支过多 = 不可接受。
还有其他已知的方法来处理这种情况吗？
Scenario:
Setting up a corporate hg system. Devs are working on multiple branches, one per dev (more or less). We are loosely following this sort of model: https://www.mercurial-scm.org/wiki/ControlledPractice.
Design/workflow constraints: repos are super long-term (10+ years); # of devs on repo is in the 10-30 range.
- DevA fixes a bug in 1 file.
- DevB needs the fixed file, but explicitly doesn't want the rest of DevA's work.
This is going to happen a lot, we anticipate.
There are several ways I can think of to handle this situation:
- Bugfix is in a single changeset, which gets
hg transplant'd from DevA's branch to DevB's branch (or a share-code branch). - Spawn off a named branch for the fix, spawning from DevB's start commit, so that it can be cleanly merged.
Problems:
- Duplicate changesets might lead to confusion about where a given feature was implemented(but maybe not?).
- Branch profusion after a few years of work on this codebase = not acceptable.
Are there other known ways to handle this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
处理这个问题的方法是让 DevA 更加小心其变更的父变更集。在 devA 提交 bug 修复之前，他/她应该
hg update到可能已进行该 bug 修复的最早版本（通常是引入该 bug 的变更集）。当开发人员 A 提交时，他/她将看到一条消息，说明已创建新头。然后，可以将这个新头拉出并合并到任何有错误的分支或存储库中，而无需携带任何其他内容。关键是，当您拉取变更集时，您需要在存储库中包含您正在拉取的变更集的祖先的任何变更集，因此，如果您希望某人能够拉取您正在执行的修复程序，则无需这样做拉动您已完成的所有其他工作，您只需确保修复的父级是他们肯定已经拥有的变更集。
这确实需要开发人员稍微多一些深思熟虑，但比使用不同的节点 ID 多次在存储库中进行相同的更改更好，正如您所注意到的，这是有问题的（而且很难看）。
这些新头就是一些人所说的“匿名分支”，它们不会像命名分支那样增殖。
The way to handle this is to have DevA be more careful about the parent changeset of his change. Before devA commits the bugfix s/he should
hg updateto the earliest revision in which that bugfix could have been made (often that's the changeset in which the bug was introduced). When Dev A commits s/he will see a message saying a new head was created. That new head can then be pulled and merged into any branch or repo that has the bug without bringing anything else with it.The key is that you when you pull a changeset you're required to have in your repo any changesets that are the ancestors of the changeet you're pulling, so if you want someone to be able to pull a fix you're doing without pulling all the other work you've done you just make sure the parent of the fix is a changeset they're sure to already have.
This does require slightly more forethought on the part of the developer, but is preferable to having the same change in the repo multiple times with different node ids, which as you note is problematic (and ugly).
These new heads are what some folks call "anonymous branches" and they don't proliferate in the same way named branches would.
如果您要将变更集从同一存储库中的一个分支移动到另一个分支，我建议您使用
transplant命令。为了了解变更集来自哪里，可以使用--log命令将一些信息附加到移植的提交消息中。例如：将使用以下提交消息在
default上创建一个变更集：我不知道如何使用 TortoiseHg v1.1 添加
--log参数.X，但您当然也可以从存储库资源管理器 GUI 执行移植。if you're moving changesets from one branch to another in the same repo, I would recommend the
transplantcommand. In terms of knowing where the changeset came from, you can use the--logcommand to append some information to the commit message of the transplant. For example:would create a changeset on
defaultwith the following commit message:I don't know of a way to add the
--logargument using the TortoiseHg v1.1.X, but you can certainly perform the transplant from the repo explorer GUI as well.