mdonovan2010
mdonovan2010

Reputation: 423

pull files from a specific revision - mercurial

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?

Upvotes: 8

Views: 13349

Answers (3)

Lstor
Lstor

Reputation: 2263

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.

Upvotes: 7

Ry4an Brase
Ry4an Brase

Reputation: 78330

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.

Upvotes: 8

Amber
Amber

Reputation: 526573

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.

Upvotes: 7

Related Questions