Question

That is, in Mercurial, if Peter cloned from me by

hg clone c:\mycode e:\code

into his e:\code

let’s say there is a file code.txt and it contains the text the code is 7

Now, when I change it to the code is 11 and hg commit, then he can get my code using hg pull and hg update. Now his version says the code is 11

But if I decide the change was wrong and hg rollback, then my repository should have the 7 version, while the working directory should have the 11 version.

So when Peter does an hg pull and hg update, he should be sync’ed up to my current repository, which is the 7, but I found that it is not the case — he still gets the 11 version. Why is that? Can he get the rolled back code (the 7)? Does Git behave the same way too?

Update: I thought commit affects the repository the same way that rollback affects the repository — commit and rollback are both DB transaction words… and now we are saying commit affects the repository but rollback doesn’t? What’s the rule here?

Update 2: At this point, if Mary does an

hg clone c:\mycode e:\marycode

at this point, she actually gets the 7 version. So, Mary gets 7. Peter gets 11. And they are both “up to date”? What is this?

Answer 1

hg pull pulls down new changesets from a remote repository – but it doesn’t delete ones that don’t exist remotely. Otherwise, doing a pull would erase any of your own work that hadn’t already be pushed to the remote. Thus, pull doesn’t get rid of a changeset that was pulled, and then the remote rolled it back, because there’s no new changeset to grab.

If you make a new commit which has the rolled-back state, then that commit will get pulled down and Peter will see it.

In other words, what you need to do is first use hg revert -r <previous-rev> to check out an earlier version that you want to change back to, then use hg commit to create a new commit based on the older revision, and then have people pull that commit.