Mercurial: How to synchronize multiple people with the intention to pull/merge/push from/with/to a central repository?

Question

Given a central mercurial respository and mutliple teams with access to this repository, every team for once in a while has to synchronize its changes to the centralized one.

Let's say team A and team B are in the state and have the intention to pull/merge/push to the centralized repository.

A pulls.
B pulls.
A merges
B merges.
B pushes. => A has to pull and merge again before pushing!

Is there a (maybe technical) way to avoid this conflict? Maybe some kind of lock? Or is this something one has to live with? :-)

By the way this "conflict" occures in a smaller scale within the teams, too. But since the team members are in the same room one can solve this by just "shouting" his intentions throughthe room to avoid the conflict.

Answer 1

The simplest way may to use hg pull --rebase when pulling -- this will rebase local changes on top of the changes from the main repository and avoid having too many merges (although this actually isn't a problem for Mercurial, it may be a problem for developers trying to understand the history).

In your example, if you change B merges to B rebases, then A will still have to pull and merge again, but there will be fewer unnamed branches to try to follow.

In any case, whether rebasing or merging following a pull, I would recommend doing an immediate push so that the changes are available to everybody.

But again, I would like to emphasize that this "problematic" scenario is only problematic because of the inconvenience for the developer. This is actually the workflow DVCS's like Mercurial are designed to handle. The "standard" workflow has always been to "pull and merge/rebase" before pushing -- hence Mercurial's warning about creating new heads if you try to push without merging.

Answer 2

Usually you can live with it, IMHO it is common sense to work this way.

You can have a workaround, but it misuses the meaning of branches.

• A and b creating branches, leaving the tip/default/master untouched.
• Both can commit and push their changes, but this will create branches on the central repository.
  • This could cause serious conflicts if the naming is equal, there a naming convention might help.
• Someone, mostly the build engineer or system architect has to merge the changes from the different branches.

If both working on different features on the same component, it might be a good way to do so.

I would recommend you to read this chapter http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html.