Mercurial 补丁队列用例

Posted 2023-02-16

【中文标题】Mercurial 补丁队列用例

【英文标题】：Mercurial Patch Queue Use Cases

【发布时间】：2010-11-05 05:12:52

【问题描述】：

我在以下情况下使用 mercurial 补丁：-

当我需要从远程存储库中提取并有未提交的更改时。然后我只需创建一个补丁，qpop 它，从远程存储库中拉取，然后再次导入补丁。 当我需要将补丁上传到审查板时。我只是打个补丁然后上传。

您还如何使用 Mercurial 补丁队列？我觉得它是一个非常强大的 Mercurial 扩展，我并没有充分发挥它的潜力。

【参考方案1】：

Mercurial wiki 在用例上有一个good section：

总结：

保存工作副本的当前状态，以便日后轻松恢复 防止“混乱的工作副本” - 如果您正在进行更改并想要更改其他内容 提供可变的、可重新排列的提交，这样您就可以在推送之前查看“历史记录”。

【讨论】：

谢谢，这完美地回答了我的问题。

【参考方案2】：

您实际上并不需要 Mercurial 补丁。如果您在拉取时有未提交的未提交更改，它们将与提示合并。

示例：

C:\>hg init db
C:\>cd db
C:\db>echo >file1
C:\db>echo >file2
C:\db>echo >file3
C:\db>hg ci -Am codebase          # Create a code base with 3 files.
adding file1
adding file2
adding file3
C:\db>echo a change >>file2       # Outstanding change to file2.
C:\db>hg st
M file2

此时我们将克隆数据库并提交我们可以拉取的更改。

C:\db>hg clone . \db2
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>cd \db2
C:\db2>echo a change >>file3
C:\db2>hg ci -m "file3 change"    # Commit a change to file3.

回到原来的数据库...

C:\db2>cd \db
C:\db>hg st                       # Still have uncommitted change
M file2
C:\db>hg pull \db2
pulling from \db2
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
C:\db>hg st                       # We have the new history, but haven't updated.
M file2                           # file2 has uncommitted change.
C:\db>type file3                  # file3 is unchanged. 
ECHO is on.
C:\db>hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
C:\db>hg st                       # We've updated, and file2 *still* has
M file2                           #    uncommitted change.
C:\db>type file2
ECHO is on.
a change
C:\db>type file3                  # But file3 now has committed change
ECHO is on.                       #    that was pulled.
a change

所以道德是，您可以拉取和更新，即使是未提交的更改。如果存在合并冲突，也会发生正常的合并行为。

对于补丁导出hg export <rev> 将导出补丁供审核。

【讨论】：

关于补丁，当您处理许多可能会或可能不会叠加在另一个上的补丁时，使用 MQ 会困难得多。在不需要时弹出补丁的想法已经丢失。

【参考方案3】：

当您在 Bitbucket 上创建补丁队列时，它会在右侧窗格中列出补丁队列的一些常见用途。他们的解释非常好，直接回答了你的问题。引用如下。

补丁队列适用于：

开发您打算提交给上游审核的功能

因为补丁队列中的补丁可以 进行修改，它们提供了一种理想的方式 开发一个功能 历史追踪的方式，虽然仍然 让您轻松融入 反馈

尝试添加新功能

补丁队列不会弄乱你的 项目的历史，所以你可以安全 使用它们作为一种快速尝试的方式 一个想法，并将其保留在版本中 控制，而不会弄乱你的 失败的项目历史 短途旅行。如果您决定保留 实验，你可以很容易地打开一个 补丁队列成一组传统的 Mercurial 提交

维护另一个项目的私人定制

因为补丁队列不属于 项目的官方变更日志， 它们非常适合维护私人 上游的定制 项目。例如，您可能 维护一个补丁队列，使 程序更好地与您的集成 公司工作流程

补丁队列不适合

长期运行的分支机构

因为补丁队列高度 不稳定，他们在跟踪方面做得很差 您的来源的长期历史 代码。为此，长期运行 分支，例如那些 对应于产品发布，应该 保存在存储库中或命名 分支。

团体发展

补丁队列不跟踪合并 历史，这使他们成为穷人 选择进行小组发展， 你真正希望看到的地方 给定的一组特征被合并到 一个存储库。有疑问时，你 应该坚持传统的叉子， 但掌握补丁的力量 队列会给你巨大的 工作流程的灵活性，以及 为您提供大大增强的 协作能力。

【参考方案4】：

MQ 是管理并发开发的绝佳工具。来自我自己answer的明目张胆的自我抄袭和自我推销：

3 每个项目使用一个补丁（或多个连续补丁）的 MQ。

优点：简单易行。 缺点：必须在切换之前 qrefresh 并在之后重建；棘手的 如果项目不 正交。

4 每个项目使用一个 MQ 分支。

优点：超灵活和可扩展（针对并发数 项目） 缺点：切换前必须 qrefresh 和 qcommit 后重建； 感觉很复杂。

【参考方案5】：

我使用 MQ 在大型 Subversion 存储库之上进行开发，我不想使用 hgsubversion 或类似的东西进行检查。在我的工作文件夹中，我启动了一个新的 .hg 存储库和一个 Mercurial Patch Queue。我用 HG 跟踪 svn 的修订，我的补丁在上面。每当我想更新 svn 状态时，我都会弹出所有补丁，运行 svn update 并再次推送和刷新补丁。当我确信我的系列可以提交时，我可以一个一个地完成我的补丁。 （目前一个新的 Subversion 功能“搁置”正在开发中，但每次我尝试时，它都不够好，所以我仍然使用那个 MQ 方法。）