best practices in mercurial: branch vs. clone, and partial merges?

Question

...so I've gotten used to the simple stuff with Mercurial (add, commit, diff) and found out about the .hgignore file (yay!) and have gotten the hang of creating and switching between branches (branch, update -C).

I have two major questions though:

1. If I'm in branch "Branch1" and I want to pull in some but not all of the changes from branch "Branch2", how would I do that? Particularly if all the changes are in one subdirectory. (I guess I could just clone the whole repository, then use a directory-merge tool like Beyond Compare to pick&choose my edits. Seems like there ought to be a way to just isolate the changes in one file or one directory, though.)

2. Switching between branches with update -C seems so easy, I'm wondering why I would bother using clone. I can only think of a few reasons (see below) -- are there some other reasons I'm missing?

   a. if I need to act on two versions/branches at once (e.g. do a performance-metric diff)

   b. for a backup (clone the repository to a network drive in a physically different location)

   c. to do the pick&choose merge like I've mentioned above.

Solution 1

I use clone for:

• Short-lived local branches
• Cloning to different development machines and servers

The former use is pretty rare for me - mainly when I'm trying an idea I might want to totally abandon. If I want to merge, I'll want to merge ALL the changes. This sort of branching is mainly for tracking different developers' branches so they don't disturb each other. Just to clarify this last point:

• I keep working on my changes and pull my fellow devs changes and they pull mine.
• When it's convenient for me I'll merge ALL of the changes from one (or all) of these branches into mine.

For feature branches, or longer lived branches, I use named branches which are more comfortably shared between repositories without merging. It also "feels" better when you want to selectively merge.

Basically I look at it this way:

• Named branches are for developing different branches or versions of the app
• Clones are for managing different contributions to the same version of the app.

That's my take, though really it's a matter of policy.

Solution 2

For question 1, you need to be a little clearer about what you mean by "changes". Which of these do you mean:

1. "I want to pull some, but not all, of the changesets in a different branch into this one."
2. "I want to pull the latest version of some, but not all, of the files in a different branch into this one."

If you mean item 1, you should look into the Transplant extension, specifically the idea of cherrypicking a couple of changesets.

If you mean item 2, you would do the following:

• Update to the branch you want to pull the changes into.
• Use hg revert -r <branch you want to merge> --include <files to update> to change the contents of those files to the way they are on the other branch.
• Use hg commit to commit those changes to the branch as a new changeset.

As for question 2, I never use repository clones for branching myself, so I don't know. I use named branches or anonymous branches (sometimes with bookmarks).

Solution 3

I have another option for you to look into: mercurial queues.

The idea is, to have a stack of patches (no commits, "real" patches) ontop of your current working directory. Then, you can add or remove the applied patches, add one, remove it, add another other one, etc. One single patch or a subset of them ends up to be a new "feature" as you probably want to do with branches. After that, you can apply the patch as usual (since it is a change). Branches are probably more useful if you work with somebody else... ?

Comments

[Draemon]

I have to say that despite wanting to love MQ and it seeming like a great idea, in practice I found them completely unworkable. Working on two different machines was a pain - taking away one major plus of source control.

[bobpaul]

This has been my complaint. You still can't add the ./.hg/patches repo in your ./.hgsub file. I use MQ when I have customizations for a specific client on top of something generic, but then I end up with multiple named patch folders (patch-clienta, patch-clientb, etc). This is fine for me working alone, but I still struggle to see how we could workably integrate MQ at my day job. Cloning could mean cloning the main repo and 3 or 4 patch-queue repos.

[mare]

why was this ever accepted and upvoted so many times when it clearly missed the point of the question? It doesn't answer 1 and it doesn't answer 2 neither while Steve's answer is actually right to the point.

[Draemon]

@mare hopfully because the OP found it useful. Sometimes there's more than one perspective on a question, and stackoverflow is designed to let the answer that most addresses the OP's problem get credit (by being accepted) and the answer most useful to the community get credit (through upvotes). A useful answer isn't always the most direct answer, so long as it addresses the underlying reason behind the question. In this case, people have asked me similar questions in real life and the information I've shared here is what they found most helpful, so I thought it might also be helpful here.

[Chen Levy]

@mare, I voted this up because I landed on this page via Google, and it resolved my question.