How to pull/merge selective changesets

[Stuart W. Marks]

Bruce Frederiksen wrote:
> I would like to set up two shared hg repos for the same project: 
> release_1 and dev.
> 
> Then after the following sequence of events:
> 
>    1. Push a changeset to release_1 that should only ever be seen in
>       release_1.
>    2. Push a changeset to dev that should only ever be seen in dev.
> 
> Now I want to push a changeset to both repos.
> 
> My understanding is that if I start with either repo (say release_1) and 
> simply clone, commit and push back to that repo, and then push/pull, 
> merge from that repo to the other repo (dev), that _all_ of the prior 
> changesets from the first repo are copied over and merged into the 
> second repo (including those from step 1).

We've run into a situation like this at work. The use case is as follows. The 
dev repo was cloned from release_1 at some point in the past, implying that 
there is a changeset that is common to both. Then (in my example) release_1 is 
a bugfix release, and dev is a repo for longer-term feature development. In our 
case release_1 isn't a subset of dev, because sometimes we want to put a quick 
patch or workaround into release_1 and independently implement the "real" fix 
in dev. However, for other bugs we will want to put the same fixes into both 
repos. Is this similar to your situation?

Here's what I've done in this situation.

1. Clone release_1 and update to a common ancestor changeset that I know is 
also in dev. Usually this changeset is the tag for the previous release.

2. Implement the bugfix, commit, merge with the tip, and push to release_1.

3. Export the bugfix changeset (not including the merge changeset).

4. Clone dev and update to the common ancestor.

5. Import the exported changeset into my dev clone using "hg import --exact". 
Merge to tip and push.

The clones at steps #1 and #4 don't have to be fresh clones. Usually when we're 
running concurrent releases I have my private work clones lying around already; 
I just use them.

This is a bit involved, but it enables one to "cherry-pick" individual 
changesets, with *identical* changesets appearing in both repos, while 
maintaining the repos as independent lines of development. This way you can say 
"fixed by changeset 9117c6561b0b" and verify that this changeset appears in 
both repos.

s'marks