pull files from a specific revision - mercurial

Question

I have 3 repositories, each created with the same code base but different enough to warrant different repositories. My "dream" work flow would be to do work in the development repository and then pull these changes into the other repositories. I know I can do this with something like:

hg pull -r X -f repo

but this will give me all changesets up to X. Is it possible to just pull all the changesets from a specific revision or even from a range of revisions?

Solution 1

If you want to grab the contents of certain changesets and apply them to an arbitrary checkout (note: the resulting changesets will be different changesets, even if they make the same changes), take a look at the transplant extension.

Solution 2

There is no good way to cherry pick revisions in mercurial (that's what your proposed workflow is called). There are some not-so-great ways to do it: export+import (or the convenience wrapper around export+import called transplant), but the draw back there is you have the same changeset with different hashes in multiple repositories, with no good way to represent that if/when you try to move changes across again.

Better is to modify your workflow so that when you want to move over a change you're okay with moving over all of its ancestors, and you do this by consciously picking a changeset's ancestors.

For example, if you're fixing a bug that's in the development repository, and all three "other" repositories don't just change the change's parent revision the tip of the development repository. First do a hg update -r THE_REVISION_WHERE_THE_BUG_WAS_ADDED, then fix your bug, and then commit. You'll see a message saying new head created, which is expected.

Now you'd got that fix as a changesets whose only parent is the changeset in which the bug was introduced -- which must exist in the 3 other repositories or they wouldn't have the bug. So now you can pull that new changeset into the "3" other repositories without bringing everything else in development with them. And then you do a quick hg merge in each of those four repositories blending the bug fix into their deployable tip.

Getting a handle of how to structure repositories with common functionality but customizations in each, can be a little tricky, but if you structure things right you can do all of your intra-repo migrations using using push, pull, and merge, and never have to fix a bug twice, have the same code in different changesets, or re-do a repository's customization.

As a note, the bisect command, does a great job of answering the "where was this bug introduced" question before one starts fixing it.

Solution 3

Updated answer: From Mercurial 2 onwards, you can use the 'graft' command that works nicely. It uses some internal merging capabilities to make sure you can handle any conflicts manually. If there are no conflicts that Mercurial can't resolve itself, the new changeset is automagically cherrypicked and committed on top of your current revision.

Comments

[mdonovan2010]

If I'm understanding this correctly, this workflow works if all repositories can be traced to a common changeset? In my situation this isn't the case.

[mdonovan2010]

This is almost giving me what I want except that when a conflict occurs I get those .rej files instead of taking me a merge tool. Do you know of any easy way to handle those .rej instead of manually parsing them and resolving conflicts?

[Ry4an Brase]

Yeah, I recognize it isn't, but and I mean this without sounding "judgemental" they should. No matter how customized your deployments are if they have some code in common they should be clones with their own changesets that do the customization -- or should share subrepos if you have some common library code between them. It would be a re-factor, but it would get you to the ";dream' work flow" you reference above.

[mdonovan2010]

Yes your right. I'm late to the gate with version controlling these websites though...mercurial seems like the perfect choice for what I've had to do but refactoring everything just to achieve my dreams might not make my employer very happy ;) Thank you for your input, it definitely helped me better understand how Mercurial works )

[Lstor]

For newer readers looking to solve the problem: See my updated answer below for a built-in, well-working solution.

[ekhumoro]

This doesn't seem to work at all, because graft copies between branches, rather than repos.