CODEWITHSUNDEEP
mercurial
LoveMeSomeCode
LoveMeSomeCode

Reputation: 3937

Mercurial Rollback and Rebuild

We have 2 mercurial named branches, development and test. There have been many changes to development that were supposed to be merged up into test. At one point the changes were merged up and then rolled back. Then the merge may have been attempted in the wrong direction. The result is that we now have 2 branches with a recent common parent. And we still have changes in development that are not in test. But due to the mistakes we made and the common parent, merging development to test does nothing, i.e. it applies no changes.

If I'm willing to take test back a couple weeks, is it possible for me to switch to the test branch like this:

hg update <last good test revision>

Then 'graft to local' from dev the dozen or so changes we want to move to test, then merge in development to reset the common parent for test?

Is this a crazy plan or is there an easier way?

Upvotes: 0

Views: 79

Answers (2)

Lazy Badger
Lazy Badger

Reputation: 97285

Is this a crazy plan or is there an easier way?

Yes and yes. Short brain-powered (instead of ass-powered) plains are

Plain A

  • Clone dirty repository into new without stupid, idiotic, brainless changesets (hg clone -r LAST_GOOD_CSET)
  • Replace dirty repo by polished

Plain B

  • Clone dirty repository into new (optional)
  • Enable strip||histedit extension for repository in question (which you want to clean-up)
  • Read carefully extension-related docs in order to use commands and workflow with brain, not blindly
  • Remove erroneous changesets from repository
  • Replace (if p.1 was done) dirty repo by polished

Upvotes: 1

Vince
Vince

Reputation: 3577

If it is just a dozen or so changes, you can indeed update to good test rev to start fresh and graft to local the commits you need to recreate the perfect branch.

Once and only once you are satisfied with your new banch head, use this trick to merge the two heads and ignore the bad test head. You need to have a single head on your branch.

Now you'd be in a state that test would hold all the changes from the development branch. I suggest you use the same trick once more to merge development in, to make the common parent for test you need, but without all the pollution that may have taken place in development. If it does not work, simply make a dummy changeset on development and retry the trick again (if it makes sense).

In the end, however, you don't seem too worried about the development branch being polluted by the test branch. Is it ok in that direction?

Upvotes: 1

Related Questions