Mercurial - merging same changeset to a repository twice?

We have these Mercurial repositories:

Trunk
|
|
|---------myapp_1_0_23 (created off release 1.0.23)    
|
|---------myapp-newstuff (created off rel 2.0.4)

Release schedule (nothing yet released):

• v1.0 from myapp_1.0.23, any add'l changes in this repo will get merged to the trunk
• v2.0 from the trunk
• v3.0 or v4.0 released based on a merge of myapp-newstuff and the trunk. At the time of the merge the trunk may have v2.0 code or some new features that we'll release from the trunk as v3.0

After making changes in myapp_1.0.23, we merge them to the trunk, but let's say we also need them in myapp-newstuff so we also merge them there. What then happens when we eventually merge myapp-newstuff code to the trunk?

The trunk already has changes made in myapp_1.0.23 so what happens when we merge those sam开发者_如何学运维e changesets from myapp-newstuff back to the trunk? Will Mercurial be smart enough to know those changesets are already in the trunk?

Mercurial will handle this situation just great -- because you're using 'merge'. When you're using export/import (or transplant), cherry picking as it's called, and you have the same changesets in there multiple times with different node ids (due to different parents) then Mercurial can't know "Oh, this one's already here". However, so long as you're merging Mercurial will do a great job of saying "oh, this repo already has that changeset so I don't need to re-apply it".

The general rule of thumb is: "Make every change with as early a parent as you can and then merge down". If I have a bug that's in version one, two, and three, I fix it in one and then merge into two and then merge into three. If instead you fix it first in three, then you have to try to get it into two without bringing all the other changes in version three with it -- which is hard and often requires the very cherry picking we're trying to avoid.