CODEWITHSUNDEEP
mercurialrepository
Daniel Rosendorf
Daniel Rosendorf

Reputation: 407

Synchronize 2 mercurial repositories

Say we have the following development setup:

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 ;-)

Upvotes: 2

Views: 3286

Answers (3)

Laurens Holst
Laurens Holst

Reputation: 21076

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.

Upvotes: 0

Lazy Badger
Lazy Badger

Reputation: 97375

If both teams are working on a common codebase (i.e single ancestor exist in repo), I can't see (except mandatory merging heads from anonymous branches) any troubles in sync process - it's one of standard branching workflow "Branching with clone"

I.e

  • SyncMaster from Team2 create own repo with 2 URLs in [paths] section of hgrc: RepoTeam1 and RepoTeam2
  • He pulls from both repos, merge heads (R2 with R1) from all existing branches (if they exist)
  • push merge results to R1 and R2

Separation on branch level between repos may help merger do his work more easy

Upvotes: 2

jmg
jmg

Reputation: 7414

Well pushing and pulling never suffers from merge conflicts. Therefore it is still possible to for both teams to work on their own. In the end someone has to pull the multiple heads from his central location to his own repository and merge the heads.

Upvotes: 1

Related Questions