Q:

Mercurial update-pull vs commit

I'm having a hard time understanding a scenario under mercurial.
Assuming i have 2 users working on the same repository. Assuming the repo is called 'Test' and it currently has files: a.txt & b.txt (both text files are currently empty with no text in them)
This is what happened:
User 1:
Modify a.txt with the sentence "Line 1"
Commit the code to the local repo (No push command issued)
User 2:
Modify b.txt with the sentence "Line 1"
Commits the code to the local repo
Issues a push command as well
User 1:
Issues a pull command
Issues an update command
RESULT: In the working directory of User 1, the file a.txt no longer contains the sentence  "Line 1" and file b.txt contains the changes of User 2. Where did the initial changes of a.txt go? overwritten? I can see them in the history logs (using TortoiseHG) but these changes aren't at the tip anymore.
What exactly happened here? My understanding is the following: When User 1 issues a pull, the changes on his local repo should somehow merge the changes coming in from User 2 with what User 1 already committed.
Can you tell me where my assumptions/understanding is wrong? If the solution to the problem above is about proper sequence of commit/push/update/pull then what's the suggested sequence of actions for an environment of multiple developers on the same code?

A:

When User1 pulls, the changeset of User2 is put at the tip of the repo. When he issues the hg update command, Mercurial updates to the most recent tip of the current branch, which is User2's changeset, without User1's modifications.
User1 now has two heads on his repo, his own changeset and User2's changeset. To obtain a combination of both changeset, he has to specifically merge the two heads, by issuing a hg merge command, which will merge the two heads of the current branch. Do not forget to commit the merged changeset, too.
The merge operation is not done automatically, Mercurial won't make decisions for you. You may want to do other things with your changeset before pushing it.
For example, a prettier alternative to this merge operation, is to use the Rebase extension, to put both changesets sequentially, and issue this command
hg rebase -s <User1-revision> -d <User2-revision>
hg update

You are basically reordering the changesets as if the modifications of User1 were made after the modifications of User2, which are already made public and part of the repo, by rebasing them on the tip. This alternative works well if User1's changeset is not yet pushed to the public.

