Question

Background:

I have used Mercurial myself as a single user to keep track of the changes I make to my own code, and I think I am already familiar with the fundamentals. However, I am now about to start working on a software project with somebody else in my lab and want to make sure I understand how to properly share code with somebody else using Mercurial.

Our situation is the following: We both have our own repository in a shared volume (i.e. different paths) in a Linux cluster, and we both have read and write access to our own and each other’s repositories.

We can call these two repositories: Bob‘s and Alice‘s repositories for the purpose of the discussion.

My understanding is that there are multiple ways of having Bob and Alice share their code, two of them being the following:

Option 1: Sharing via pulling

• Bob pulls from Alice whenever he wants to see her changes
• Similarly, Alice pulls from Bob whenever she wants to see his changes.

Option 2: Sharing via pushing

• Bob pro-actively pushes his changes into Alice’s repository whenever he wants to share his changes with her.
• Similarly, Alice pro-actively pushes her changes into Bob’s repository whenever he wants to share his changes with her.

Questions:

My interpretation from reading the Mercurial documentation and tutorials online is that the first option above is usually preferred over the second one. One question I have is why?

Can the second option above lead to any problems? What would happen if Bob commits into his own repository while Alice also pushes her changes simultaneously into Bob’s repository?

Thanks

Answer 1

Either works and in the end it really doesn’t matter because pushing/pulling doesn’t do the update or the merge for the recipient — it just moves changeset into the underlying repo, not into the working directory.

The first option, pulling, is more commonly done because:

• usually you don’t have write access to one another’s repos (and probably shouldn’t) and with pulling you only need read access to one another’s repos
• when you push changesets to someone there’s no notification to them that they received new changesets. They won’t discover it until they run hg summary (or hg heads or hg log) and then they’ll have to hg merge. So as long as the recipient has to take an explicit action (check and merge) to get your changes they may as well just pull and merge instead. It’s no more work for them and less for you.

As others have pointed out a repository write-look will prevent commiting during incoming push or pull operations.