4

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

  1. 当我需要从远程存储库中提取并有未提交的更改时。然后我简单地创建一个补丁，qpop 它，从远程存储库中拉取，然后再次导入补丁。
  2. 当我需要将补丁上传到 reviewboards 时。我只是制作一个补丁并上传它。

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

4

5 回答 5

7

The Mercurial wiki has a good section on use cases:

In summary:

  1. Saving the current state of the working copy so you can easily revert to it later on
  2. Preventing a "tangled working copy" - if you're halfway through a change and want to change something else
  3. Provide mutable, rearrangeable commits so you can get 'history' looking just right before pushing.
于 2010-11-05T11:00:08.717 回答
4

您实际上并不需要 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

So the moral is, you can just pull and update, even with uncommitted changes. If there are merge conflicts, normal merge behavior occurs as well.

For patch exporting hg export <rev> will export patches for review.

于 2010-11-05T07:15:01.920 回答
4

When you create a patch queue on Bitbucket, it lists some of the common uses for patch queues in the right pane. Their explanation is very good and answers your question directly. Quotes from it are below.

Patch queues are good for:

  • Developing features you intend to submit for upstream review

    Because patches in patch queues can be modified, they provide an ideal way to develop a feature in a history-tracked manner, while still allowing you to easily incorporate feedback

  • Experimenting with adding a new feature

    Patch queues don't clutter your project's history, so you can safely use them as a way to quickly try out an idea, and keeping it in version control, without cluttering up your project's history with failed excursions. If you decide to keep the experiment, you can easily turn a patch queue into a set of traditional Mercurial commits

  • Maintaining private customizations for another project

    Because patch queues are not part of the official change log for a project, they are ideal for maintaining private customizations for an upstream project. For example, you might maintain a patch queue that makes program better integrate with your company's workflow

Patch queues are not good for

  • Long-running branches

    Because patch queues are highly volatile, they do a poor job tracking the long-term history of your source code. For this reason, long-running branches, such as those that correspond to product releases, should be kept in repositories or named branches.

  • Group development

    Patch queues do not track merge history, which makes them a poor choice for doing group development, where you really wish to see when a given set of features was merged into a repository. When in doubt, you should stick to a traditional fork, but mastering the power of patch queues will give you tremendous flexibility in your workflow, and provide you with greatly enhanced collaboration abilities.

于 2011-02-16T12:49:57.060 回答
1

MQ is a great tool to manage concurrent development. Blatant self-plagiarism and self-promotion from my own answer:

3 Use MQ with one patch (or multiple consecutive patches) per project.

  • Pros: simple and easy.
  • Cons: must qrefresh before switching and rebuild after; tricky and risky if projects are not orthogonal.

4 Use one MQ branch per project.

  • Pros: ultra flexible and scalable (for the number of concurrent projects)
  • Cons: must qrefresh and qcommit before switching and rebuild after; feels complicated.
于 2010-11-05T17:52:16.597 回答
0

I use MQ for developing on top of a big Subversion repository I don't want to checkout with hgsubversion or something similar. In my working folder I initiate a new .hg repo and a Mercurial Patch Queue. I track the svn revisions with HG and my patches are on top. Whenever I feel to update the svn state, I pop all the patches, run svn update and push and refresh the patches again. When I'm confident my series is okay for commit, I can qfinish my patches one by one. (Currently a new Subversion feature "shelve" is under development, but every time I tried that, it did not work well enough, so I still use that MQ approach.)

于 2020-06-24T19:38:12.710 回答