0

So I've just started to use Mercurial and ran into an issue I'm not really sure of how to handle correctly. Here's the example scenario:

Demo Branch --- Good Change 1  --- Bad Change 2  --- Good change 3  --- Good change 4
Prod Branch --- \Good Change 1 --- \Bad Change 2 --- \Good Change 3 --- \Good Change 4

So essentially a good change was committed, tested, and merged with production. Than a bad change was tested, assumed working, and pushed live to production. Finally 2 more good changes were pushed to production. We now realize "Uh-Oh" That 2nd change was actually a problem! We need to revert that, but we still wast good change 3 and 4 there.

Backout worked on the demo but not the prod because it was a merge. I eventually got everything working right, but with lots of grafts and updates and merges. It just seems like there should be a simple way to fix that one problem, while keeping everything else moving forward. Thanks!

KJ3
  • 5,168
  • 4
  • 33
  • 53
  • Would you edit your question to give more detail on what went wrong with the backout? Backout on demo, then merge to prod sounds perfectly reasonable, so it'd be good to find out why it didn't work for you. – anton.burger Apr 22 '13 at 07:09
  • My guess is the OP did not do a backout but did a rollback or strip. Backouts are pretty reliable. He may want to review: http://stackoverflow.com/questions/5371159/what-is-the-difference-between-rollback-backout-and-strip-in-the-mercurial-eclin . My other guess is that he forced push multiple heads. – Adam Gent Apr 22 '13 at 16:16

2 Answers2

0

Backout worked on the demo but not the prod because it was a merge

WTF? If changeset is ordinary changeset in repo, it will be the same changeset after pushing this changeset.

Push != merge and never will be merge. If you want to discard changeset, can do it with backout in source repository (thus - get new additional changeset) and publish this change you have to push backout-changeset to prod (dirty history, but correct state of repos after all)

Lazy Badger
  • 94,711
  • 9
  • 78
  • 110
0

My understanding is that this is how things looked to start with.

Demo   G1----B2----G3----G4
          \     \     \     \
Prod   ----M1----M2----M3----M4

...and then you backed out the bad change on the demo branch

Demo   G1----B2----G3----G4----BOB2
          \     \     \     \
Prod   ----M1----M2----M3----M4

All you need to do at this point is merge again

Demo   G1----B2----G3----G4----BOB2
          \     \     \     \      \
Prod   ----M1----M2----M3----M4-----M5

A back-out change-set is no different to any other change set. It just has the opposite effect of the original. What I think you did was try to back out the merge that included the bad change into your Prod branch (M2) but that has some strange effects, as described here.

Alternatively you could have backed-out B2 on both branches, and that should have been fine too.

Demo   G1----B2----G3----G4----BOB2
          \     \     \     \      
Prod   ----M1----M2----M3----M4-----BOB2
Paul S
  • 7,645
  • 2
  • 24
  • 36