mercurial - Mercurial Patch Queue用例

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

当我需要从远程存储库中提取并具有未完成的未提交更改时。然后我只需创建一个补丁，qpop，从远程存储库中提取，然后再次导入补丁。
当我需要将补丁上传到评论板时。我只是制作补丁并上传。

您如何使用Mercurial Patch Queues？我觉得它是一个非常强大的Mercurial扩展，我并没有充分利用它。

Mercurial wiki有一个good section用例：

总结：

保存工作副本的当前状态，以便日后轻松恢复
预防“纠缠不清的工作副本” - 如果你正在改变中途并希望改变别的东西
提供可变的，可重新排列的提交，这样您就可以在推送之前让“历史”看起来正确。

你真的不需要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>，将导出修补程序以供审核。

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

补丁队列适用于：

开发您打算提交以进行上游审核的功能

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



尝试添加新功能

补丁队列不会让你感到困惑   项目的历史，所以你可以安全   使用它们作为快速尝试的方法   一个想法，并保持其版本   控制，而不会弄乱你的   项目的历史失败   游览。如果你决定保留   实验，你可以轻松转一个   补丁队列成一套传统   Mercurial提交



维护其他项目的私人自定义

因为补丁队列不属于   项目的官方更改日志，   他们是保持私人的理想选择   上游的自定义   项目。例如，你可能   维护一个补丁队列   程序更好地与您的整合   公司的工作流程

补丁队列不适合

长期分支

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



小组发展

补丁队列不跟踪合并   历史，这使他们变得贫穷   做团队发展的选择，   在哪里你真的希望看到什么时候   给定的一组功能被合并到   存储库。当有疑问时，你   应该坚持传统的叉子，   但掌握补丁的力量   队列会给你巨大的   灵活的工作流程，以及   为您提供极大的增强   协作能力。

MQ是管理并发开发的绝佳工具。从我自己的answer：

中肆无忌惮的自我剽窃和自我推销

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


优点：简单易行。

缺点：在切换和重建之后必须进行qrefresh;狡猾   如果没有项目则有风险   正交。


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


优点：超灵活且可扩展（针对并发数量）   项目）

缺点：切换和重建之前必须qrefresh和qcommit;   感觉很复杂。

我使用MQ在大型Subversion存储库上进行开发，我不想使用hgsubversion或类似的东西进行签出。在我的工作文件夹中，启动一个新的.hg存储库和一个Mercurial补丁队列。我用HG跟踪svn修订版，并且我的补丁在最上面。每当我感觉要更新svn状态时，我都会弹出所有补丁，运行val f2 = lift2(f1) val optionSum = f2(f2(option1, option2), option3)，然后再次推送并刷新补丁。当我确信自己的系列可以提交时，可以逐个完成补丁。（当前正在开发一个新的Subversion功能“ shelve”，但是每次尝试时，它都不能很好地起作用，因此我仍然使用该MQ方法。）

Mercurial Patch Queue用例

5 个答案:

实施例

补丁队列适用于：

补丁队列 不适合

补丁队列不适合