从特定版本中提取文件 - Mercurial
我有 3 个存储库，每个存储库都使用相同的代码库创建，但差异足以保证不同的存储库。我的“梦想”工作流程是在开发存储库中完成工作，然后将这些更改拉入其他存储库。我知道我可以用类似的方法来做到这一点：
hg pull -r X -f repo
但这将为我提供最多 X 的所有变更集。是否可以从特定修订版甚至一系列修订版中提取所有变更集？
I have 3 repositories, each created with the same code base but different enough to warrant different repositories. My "dream" work flow would be to do work in the development repository and then pull these changes into the other repositories. I know I can do this with something like:
hg pull -r X -f repo
but this will give me all changesets up to X. Is it possible to just pull all the changesets from a specific revision or even from a range of revisions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Mercurial 中没有好的方法来挑选修订（这就是您建议的工作流程的名称）。有一些不太好的方法可以做到这一点：导出+导入（或导出+导入的便捷包装器称为移植），但缺点是您在多个存储库中拥有相同的变更集，但没有好的哈希值如果/当您尝试再次移动更改时的方式来表示。
更好的方法是修改您的工作流程，以便当您想要移动更改时，您可以移动其所有祖先，并且可以通过有意识地选择变更集的祖先来完成此操作。
例如，如果您正在修复开发存储库中的错误，并且所有三个“其他”存储库不仅仅更改更改的父版本，还更改开发存储库的
tip。首先执行hg update -r THE_REVISION_WHERE_THE_BUG_WAS_ADDED，然后修复错误，然后提交。您将看到一条消息，显示已创建新头，这是预期的。现在，您已经将修复作为变更集进行了，其唯一的父级是引入错误的变更集——它必须存在于其他 3 个存储库中，否则它们不会有错误。因此，现在您可以将新的变更集
拉到“3”个其他存储库中，而无需将其他所有内容一起开发。然后，您在这四个存储库中的每一个中进行快速hg merge，将错误修复混合到其可部署的tip中。掌握如何构建具有通用功能但可自定义的存储库可能有点棘手，但如果结构正确，您可以使用推、拉和合并来完成所有存储库内迁移，并且永远不会有要两次修复错误，请在不同的变更集中使用相同的代码，或者重新进行存储库的自定义。
需要注意的是，bisect 命令在开始修复之前很好地回答了“这个错误是在哪里引入的”问题。
There is no good way to cherry pick revisions in mercurial (that's what your proposed workflow is called). There are some not-so-great ways to do it: export+import (or the convenience wrapper around export+import called transplant), but the draw back there is you have the same changeset with different hashes in multiple repositories, with no good way to represent that if/when you try to move changes across again.
Better is to modify your workflow so that when you want to move over a change you're okay with moving over all of its ancestors, and you do this by consciously picking a changeset's ancestors.
For example, if you're fixing a bug that's in the development repository, and all three "other" repositories don't just change the change's parent revision the
tipof the development repository. First do ahg update -r THE_REVISION_WHERE_THE_BUG_WAS_ADDED, then fix your bug, and then commit. You'll see a message sayingnew head created, which is expected.Now you'd got that fix as a changesets whose only parent is the changeset in which the bug was introduced -- which must exist in the 3 other repositories or they wouldn't have the bug. So now you can
pullthat new changeset into the "3" other repositories without bringing everything else in development with them. And then you do a quickhg mergein each of those four repositories blending the bug fix into their deployabletip.Getting a handle of how to structure repositories with common functionality but customizations in each, can be a little tricky, but if you structure things right you can do all of your intra-repo migrations using using push, pull, and merge, and never have to fix a bug twice, have the same code in different changesets, or re-do a repository's customization.
As a note, the bisect command, does a great job of answering the "where was this bug introduced" question before one starts fixing it.
如果您想获取某些变更集的内容并将其应用于任意签出（注意：生成的变更集将是不同的变更集，即使它们使相同的更改），请查看
transplant扩展。If you want to grab the contents of certain changesets and apply them to an arbitrary checkout (note: the resulting changesets will be different changesets, even if they make the same changes), take a look at the
transplantextension.更新答案：从 Mercurial 2 开始，您可以使用 'graft' 命令效果很好。它使用一些内部合并功能来确保您可以手动处理任何冲突。如果没有 Mercurial 无法自行解决的冲突，则会自动挑选新的变更集并在当前修订的基础上提交。
Updated answer: From Mercurial 2 onwards, you can use the 'graft' command that works nicely. It uses some internal merging capabilities to make sure you can handle any conflicts manually. If there are no conflicts that Mercurial can't resolve itself, the new changeset is automagically cherrypicked and committed on top of your current revision.