1

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 same changesets from myapp-newstuff back to the trunk? Will Mercurial be smart enough to know those changesets are already in the trunk?

Marcus Leon
  • 55,199
  • 118
  • 297
  • 429
  • I ask mostly same question: http://stackoverflow.com/questions/6709365/how-to-move-bugfixes-across-branches-in-dvcs – gavenkoa Jul 18 '11 at 14:46

1 Answers1

5

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.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Thanks Ry4an, how does Mercurial keep track of changesets merged in from other repositories? Does it use the changeset hash id? Is this id unique across all repositories? – Marcus Leon Feb 02 '11 at 21:31
  • As always, the best way to learn Mercurial is to make a local clone or just a copy, and experiment, observing the results. – Lasse V. Karlsen Feb 02 '11 at 21:31
  • Yeah, the node id (hash) is global and used to keep track of what is already there. @Lasse is correct -- just play around with it on the command line. You can use dir to dir pushes to test all of this w/o any real effort. – Ry4an Brase Feb 02 '11 at 22:18