Say we have the following development setup:
- Team 1 in location A with a central mercurial repo where all of this teams work gets pushed
- Team 2 in location B (halfway around the world from team 1 and with a flaky internet connection) with its own central mercurial repo where all of this teams work gets pushed
How can I safely synchronize the central repositories from team 1 and 2 without getting into problems with merges/multiple heads etc.?
I would assume that a scheduled push/pull from one of the repositories (in location A for example) to/from the other would handle this, but how do I handle situations where there are multiple heads involved?
For example:
Team 1 pushes a commit, in the mean time team 2 also pushes. Now when the repo in location A pulls the changes, it get’s multiple heads. Now what do I do? Would the solution here be to let a developer from team 1 (in location A) merge the heads and push them back to his central repo so that the next scheduled push to location B pushes the merge? These would lead to problems if team 2 already pushed other changes to its central repository, correct?
Is there any other solution for this kind of problem?
What I want to avoid is that team 2 has to wait for its internet connection to stabilize to push its changes back to team 1 …
I’d be glad about any kind of help here 😉
Well the basic rule is, never push new heads to a remote repository. Because if you do that, you will be creating heads that suddenly pop up in the other team’s repository that they have to merge, and that’s confusing. Mercurial will complain about this if you try to do it unless you specify the –force parameter.
But other than that it is pretty standard fare; you designate one or more persons responsible for merging the two repositories (daily or so), then pull all changes from both branches, merge the two heads, and then push the result back to both repositories, just like any team member would have to do. If something is pushed while you are merging, you have to do another merge (hopefully without conflicts) before you push.
To partially automate this, you could set up a post-push hook on the two team repository servers which asynchronously pushes the changes to the other server, and sends an email to the person responsible for merging if it fails because it would create remote heads. Because the time window where the servers are out of sync is not very long, this will probably succeed most of the time. It should include some logic to not push if it is already pushing, and to retry later if the connection is down.