tags:

views:

43

answers:

2

If just to see how a program behave, an

hg up -r 1000

is done, while the current revision is 1020.

Then some changes are made to 2 files, and accidentally, the files are committed.

So now there are changes made from revision 1000 to 1020, and also some changes that is from 1000 directly to 1021...

In this case, how should it be handled?

At least one possibility maybe

hg backout -r 1021
hg up tip

and make changes as if nothing happened with 1021. Is the other option to do an hg merge and need to be careful about how the code is merged? (because all changes from 1000 to 1021 are all related to the same feature and same files). Or is there any other option besides these two?

+3  A: 

Have you looked at the rebase extension? It should handle this nicely:

hg up 1020
hg rebase -s tip

The result of this is that the changes you accidentally made against revision 1000 are moved to 1020. I'm assuming that you want to keep the changes, and the accident was just that you made them against an old revision. If you really want to get rid of the changes, your backout approach is good. You can also use the strip command from the MQ extension to remove them from history. Both rebase and strip rewrite your local history, making them unsuitable if you've pushed the changesets you're trying to edit to someone else's repository.

brendan
+5  A: 

Just do the merge. It won't be painful.

The backout people are suggesting will still leave you with multiple heads. Currently your history looks like this:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]

After a backout of 1021 it would look like:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]---[1022]

where 1021 and 1022 would logically undo one another but you'd still have the two heads.

After a merge you'll have

---[1000]---[1001]--....--[1019]--[1020]---[1022]
      \                                   /
       \----[1021]-----------------------/

You could do a 'hg commit --close-branch' after updating to 1021, which will still leave that head in place but will stop it from showing up on listings, but the merge is a better choice.

If you've not yet push 1021 anywhere you could leave it behind entirely like:

hg clone -r 1020 myrepo trimmedrepo

and then you'll have a new repo, trimmedrepo, that has everything up to and including 1020 (but no 1021).

I like the merge.

Ry4an
@Ry4an: Thanks a lot. Removing my answer as it will be misleading
pyfunc
You're a class act, pyfunc. I'm a huge fan of backout in general, but in this case it just wasn't going to undo this particular mistake.
Ry4an