如何在 Mercurial 的存储库之间推送/拉取单个变更集?

发布于 2024-09-18 22:04:10 字数 638 浏览 8 评论 0原文

我有以下情况:

  • 我有站点 A,其中有 Mercurial 存储库,并且我们已经开发它有一段时间了。假设 A 有 5 次修订。
  • 我们现在必须创建站点 B,除了图形设计之外,它与站点 A 几乎相同。因此,我克隆了该存储库,启动了站点 B,现在 B 的存储库拥有 A 的所有历史记录,以及一堆永远不应该返回到 A 的变更集(主要是 CSS 和图像)。假设这些更改需要我进行 3 次修改。
  • 最后,我现在对 B 进行了更改,我想将其移回 A,因为它属于两个站点。这是 B 存储库中的修订版 9。

问题是:如何将修订版 9 从 B 的存储库移至 A 的存储库,而不同时移动修订版 6-8?

  • 我尝试过定期推/拉,但这会移动所有变更集。
  • 我尝试过导出捆绑包或补丁,但由于缺少父项,它们拒绝导入到 A 中。

我认为 DVCS 的优点之一是我可以轻松地完成这种事情(在“集中式”VCS 世界中,我可以通过分支和合并轻松修复,我已经用 Vault 完成了很多次,而且非常简单) 。

我在这里错过了什么吗?

注意:我研究了“MQ”,但这似乎是一大群蠕虫,而且看起来它只会影响启用的常规提交周期。这是正确的吗?

任何帮助或指示将不胜感激。谢谢你!

丹尼尔

I have the following situation:

  • I have site A, which has it's Mercurial repo, and we've been developing it for a while. Let's say A has had 5 revisions.
  • We now has to create Site B, which is almost identical to site A, except for graphical design, mostly. So I cloned the repo, started site B, and now B's repo has all of A's history, plus a bunch of changesets that should never go back to A (mostly CSS and images). Let's say these changes took me 3 revisions.
  • Finally, I've now made a change to B that I would like to move back to A because it belongs on both sites. This is revision 9 in B's repo.

The question is: How can I move revision 9 from B's repo into A's repo, without also moving revisions 6-8?

  • I've tried regular pushing/pulling, but that moves all the changesets.
  • I've tried exporting bundles or patches, but those refuse to import in A because of the missing parent.

I thought one of the beauties of DVCS was that I could do this kind of thing easily (which in the "centralized" VCS world I could fix easily with branches and merging, I've done it with Vault a lot and it's pretty easy).

Am I missing something here?

NOTE: I looked into "MQ", but that seems to be a big can of worms, and it looks like it'll affect the regular commit cycle just for being enabled. Is this correct?

Any help or pointers will be greatly appreciated. Thank you!

Daniel

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

沒落の蓅哖 2024-09-25 22:04:10

https://www.mercurial-scm.org/wiki/wiki/TransplantExtension

请参阅“使用移植来挑选一组变更集”:

移植可以管理多个变更集或变更集范围,例如
这个:

hg 移植 REV1:REV2 REV3

此示例将挑选指定的变更集范围
REV1:REV2 和工作目录上的附加变更集 REV3
修订。

理想情况下,你会用分支来做到这一点吗?

https://www.mercurial-scm.org/wiki/wiki/TransplantExtension

See under "Using transplant to cherrypick a set of changesets":

Transplant can manage multiple changesets or changeset ranges like
this:

hg transplant REV1:REV2 REV3

This example would cherrypick the range of changesets specified by
REV1:REV2 and the additional changeset REV3 upon the working directory
revision.

Ideally you would do this with branches though?

救赎№ 2024-09-25 22:04:10

我是这样想这些命令的:

  • hg bundle 为您提供变更集的二进制版本,而 hg unbundle 会将捆绑包转换为与接收方完全相同的变更集侧面。

    捆绑和解绑用于通过电子邮件传输变更集,而二进制补丁取决于要存在的父变更集。

  • hg export 为您提供变更集的文本表示形式,除非您使用 --exact 命令行标志进行 hg import,然后应用此补丁不会在接收端创建完全相同的变更集。

    不使用 --exact 的优点恰恰在于,只要不存在文本冲突,您就可以在任何地方应用此类补丁。

  • hg移植只是hg导出hg导入的一个薄包装。

I think of the commands this way:

  • hg bundle gives you a binary version of a changeset and hg unbundle will turn the bundle into exactly the same changeset on the receiving side.

    Bundle and unbundle are there to transfer changesets over, say, email and the binary patch depend on the parent changesets to be present..

  • hg export gives you a text representation of a changeset, and unless you use the --exact command line flag to hg import, then applying this patch wont create the exact same changeset on the receiving side.

    The advantage of not using --exact is precisely that you can apply such a patch anywhere as long as there are no textual conflicts.

  • hg transplant is just a thin wrapper around hg export and hg import.

梅倚清风 2024-09-25 22:04:10

如果您想“折叠”或跳过 Mercurial 存储库中的历史记录,只需更新到基本版本(在您要折叠的部分之前)。如果您想将上面的所有内容折叠到一个变更集中(这似乎就是您想要的),您只需恢复到该分支的头部并提交它(或仅提交您想要的文件) 。这将创建一个包含您想要的内容的新变更集,以便您可以将其推送到您的站点 A。您不需要的内容,您只需忽略(或者如果您无法忽略它,则将其剥离)。

如果您想要保留多个变更集,您应该rebase。启用变基扩展并将#9 变基到#5。如果有 #9 的任何孩子,这些孩子也会随之移动。 Rebase 比移植更好(它做了类似的事情),因为 rebase 使用 3 路合并机制来迁移变更集,使其更有可能成功。移植或多或少只是一种愚蠢的进出口,因此它忽略了共同的历史。

If you ever want to "fold" or skip history in a mercurial repo, you simply update to the base revision (before the section you want to fold). If you want to fold everything above that into a single changeset (this appears to be what you want), you just revert to the head of that branch and commit this (or commit just the files you want). This will create a new changeset with the stuff you want so you can push this to your site A. The stuff you don't want, you just ignore (or strip it if you can't ignore it).

If you have multiple changesets above your fold which you want to keep, you should rebase. Enable the rebase extension and rebase #9 on to #5. If there's any children of #9, these will get moved with it. Rebase is preferable to transplant (which does a similar thing) because rebase uses 3-way merge machinery to migrate changesets, making it more likely to succeed. Transplant is more-or-less just a dumb export-import so it ignores common history.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文