Using Mercurial (Hg), after checking in rev 100, 101, and 102, do we need to back them out one by one?

After reducing the code to the simplest form, as revision 100, 101, and then 102, when the problem is found, can an

hg backout -r 100

be done to back all changes out? Or do we need to backout 102, 101, and then 100 (ie, one 开发者_开发知识库by one)?

Your command won't do what you want -- backout does only a single changeset.

There are, however, quite a few ways to backout three contiguous changesets, and it really all depends what you want left in your history graph.

The quickest way would be:

hg diff -r 102 -r 99 | hg import --no-commit -

which says "take the difference between 102 and 99 (notice the reversed order) and apply it as a patch. After that you'd check out the working directory and if you like it do a hg commit --addremove.

The drawback there is that your history graph will look like:

--[99]---[100]---[101]---[102]---[103]

Where 103 is the negative of the combined changed of 100, 101, and 102. That doesn't show what really happened.

Better would be to hg update 99 do a commit, any commit, so now your history looks like:

--[99]---[100]---[101]---[102]
     \
      [103]---

and then do hg --config ui.merge=internal:local merge 102 which merged 102 into 103 and but takes none of the changes from 100, 101, 102.

That will leave your history looking like:

--[99]---[100]---[101]---[102]
     \                       \
      [103]-------------------[104]

which to me more clearly says what happened. Either works, though.

Or you could probably just do:

hg backout 102
hg backout 101
hg backout 100

which makes your history:

--[99]---[100]---[101]---[102]---[103]---[104]---[105]

Where 103, 104, and 105, are the inverses of 102, 101, and 100, respectively, but that's just silly.

Assuming you no longer want anything from revs 100, 101, or 102, a similar answer to Ry4an's second suggestion is the following:

• From the tip, use hg commit --close-branch - this removes the branch from the list of heads and tells the world, in effect, I'm not going to develop on top of this anymore. (This corresponds to commit 103 in the below graph)
• Update to the last good revision (hg update 99), continue work as normal, and make new commits (commit 104, 105 in the below graph)

The resulting graph appears like:

--[99]---[100]---[101]---[102]---[103]---X
     \                       
      [104]---[105]---...

The subtle difference is that there is no "fake merge" (where you take only the changes from one parent).

You need to back them out individually as backout only removes the changes for the changeset that you backout.

See

http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html

From http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html:

The hg backout command takes a single changeset ID as its argument; this is the changeset to back out.

At least from the information above, it takes only a single changeset to back out.

One approach is hg up -r mygoodandawesomerev, then commit against that, creating, in essence, an unnamed branch waving in the breeze.

Do you really want to back out the bad changesets, so that you continue working from changeset 99, but you see 100 - 102 in the history?

Or do you want to completely get rid of them (so that they even disappear from the history)?
If yes, you can just clone the repository, but exclude the bad changesets:

Mercurial: Fix a borked history