Use cases for the Mercurial Queue

Question

I use mercury plasters in the following cases: -

• When I need to pull from a remote repository and have outstanding uncommitted changes . Then I just create the patch, qpop it, pull it from the remote repository, and then import the patch again.
• When do I need to upload patches to review pages . I just make a patch and download it.

How else do you use Mercurial Patch Queues? I feel that this is a very powerful Mercurial extension and that I am not using it fully.

Answer 1

The Mercurial wiki has a nice section in use cases:

In short:

• Saving the current state of the working copy so you can easily return to it later
• Preventing a "confusing working copy" - if you are halfway through a change and want to change something else
• Provide mutable, regrouped commits so you can get a “story” right before clicking.

Answer 2

You really don't need Mercurial fixes. If you have outstanding unmanageable changes when you pull, they will be merged with the tip.

Example:

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 

At this point, we clone the database and commit the changes that we can pull.

 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. 

Back to source database ...

 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 moral, you can just pull and update, even with uncommitted changes. If there are merge conflicts, the usual merge behavior also occurs.

To export hg export <rev> patches, patches will be exported for viewing.

Answer 3

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

Patch queues are good for:

• Develop features that you intend to submit for an upstream review

  Because patches in patch queues can be modified, they provide an ideal way to develop a feature into a trackable history, allowing you to easily include feedback

• Experimenting with the addition of a new feature

  The queues of patches do not interfere with your project history, so you can safely use them as a way to quickly try out an idea and keep it in a control version, without cluttering up the project history with an excursion error. If you decide to keep the experiment, you can easily turn the queue of patches into a set of traditional Mercurial commits

• Maintaining private settings for another project

  Because the update queues are not part of the official change log for the project, they are ideal for customizing the upstream project. For example, you can maintain a patch queue that makes the program better integrates with your company workflow.

Patch queues are not suitable for

• Long Term Branches

  Because patch queues are inefficient, they do not keep track of the long-term history of your source code. For this reason, for a long time branches, such as those that correspond to product releases, must be stored in repositories or branches.

• Team Development

  The patch queues do not track the merging of the story, which makes them a poor choice for developing a group where you really want to see when this feature set has been merged into a repository. When in doubt, you should stick with the traditional plug, but harnessing the power of the patch queue will give you amazing flexibility in your workflow and provide collaboration opportunities.

Answer 4

MQ is a great concurrency management tool. Explicit self-plagiarism and self-promotion from my own answer :

3 Use MQ with one patch (or multiple consecutive fixes) for each project.

• Pros: simple and easy.
• Cons: qrefresh must be performed before switching and restoring; confusing and risky if the projects are not orthogonal.

4 Use one MQ branch for each project.

• Pros: ultra flexible and scalable (for the number of simultaneous projects)
• Cons: qrefresh and qcommit are necessary before switching and recovery after; feels complicated.