6

I have a workflow question related to Mercurial (possibly applicable to other DVCS).

The repo is set up using the typical default/stable setup.

You're tasked with building a new feature and expect it to take some time (month+). While working on this feature, you come across a bug that you think should be fixed and applied to production sooner than later. Or perhaps, you notice some code that could be documented better.

My assumption is that you make the fix in default and then switch over to stable and make the fix again (by hand or by applying a patch). Is that correct or should you immediately switch to stable, do the change there and then merge stable into default?

Using a patch seems to make more sense to me. You can make a commit specifically for the bug fix and apply that patch at your convenience. I mean if the bug isn't too nasty, there is no need for urgency and breaking your flow. Right?

So, how do you handle this situation?

Thanks

jbarreiros
  • 1,103
  • 1
  • 10
  • 21
  • Note: Wim proposes an viable alternative to cherry-picking that you could consider. – VonC Jan 13 '11 at 20:24

2 Answers2

6

You can go back to the branch point (revision B), fix the bug there (revision X) and then merge the fix into both branches (M1 and M2):

-----B--o----o---M1----o---> stable
     |          /
     |---------X   bugfix
     |          \
     \--o---o----M2----o-----> feature

This way you can get your fix in each branch with normal hg merge operations; no patching, transplanting or MQ'ing required.

Taking the same idea a step further: you could instead go back to the revision that introduced the bug in the first place. By using this as the base for the fix, you'll be sure that you can merge your fix into any branch that contains the bug.

Wim Coenen
  • 66,094
  • 13
  • 157
  • 251
  • 2
    Huzzah, for the guy that understands "where" you make the change is as important as the change itself. – Ry4an Brase Jan 13 '11 at 20:13
  • I can understand why one wouldn't want to duplicate history, but for simple fixes, "transplant" seems to be the easiest method, which appears to also keep the timeline nice and linear, where a merge can kind of complicate the timeline. Am I just being lazy? – jbarreiros Jan 13 '11 at 23:12
  • 2
    @jbarreiros: This is a controversial topic. On the one hand there are people who like to keep their history "nice and linear" as you say, and they will make heavy use of things like "rebase" to achieve it. On the other hand there are people who advocate to [make all changes on feature branches from stable baselines](http://codicesoftware.blogspot.com/2010/11/linus-on-branching.html). – Wim Coenen Jan 14 '11 at 03:08
  • Thanks Wim for your answer. The link (in your comment above) and the articles it linked to were also very informative. – jbarreiros Jan 14 '11 at 15:33
  • @jbarreiros: better choice than my answer indeed. – VonC Jan 14 '11 at 18:27
0

Once you have made your small fix commit, you can use the Hg Transplant Extension and report that same fix on another branch.

If this isn't appropriate, other cherry-picking possibilities are detailed in the SO question "Mercurial cherry picking changes for commit".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you VonC, the transplant extension will do just nicely. Thanks for the link too. – jbarreiros Jan 13 '11 at 18:19
  • 1
    One can avoid this with a better workflow. Wim's solution below is preferable because you don't end up with the same change twice in your repo with different hash-ids. Making the same change in two places makes the eventual merging of those places less automatic. – Ry4an Brase Jan 13 '11 at 20:12
  • @Ry4an: I agree. Yet again, I reason too much like a Git user ;) – VonC Jan 13 '11 at 20:22
  • Heh, hey there's no "wrong" and he seems to have liked your answer. I just thought I'd trumpet the other solution to slow your eventual displacing of me as stats leader for the mercurial tag. ;) – Ry4an Brase Jan 13 '11 at 22:46
  • @Ry4an: you will always be the stat leader for Mercurial to me ;) – VonC Jan 14 '11 at 04:46