假設我們有以下的發展設置：同步2善變庫
我怎樣才能安全地同步來自團隊1和2在中央庫沒有進入有問題的世界合併/ MULT嬉皮士等？
我會假設從其中一個存儲庫（例如位置A）到另一個存儲庫的計劃推/拉將處理此問題，但是如何處理涉及多個頭部的情況？
例如： 團隊1推送提交，同時團隊2也推送。現在當位置A的回購拉動變化時，它會得到多個頭。現在我該怎麼辦？這裏的解決方案是讓團隊1（地點A）的開發人員合併團隊頭並將他們推回到他的中央倉庫，以便下一次按位置B推送合併？如果團隊2已將其他更改推送到中央存儲庫，那麼這些會導致問題，對嗎？
這種問題還有其他解決方案嗎？
我想避免的是，球隊2必須等待其互聯網連接穩定，以推動其更改回隊1 ...
我很高興對任何形式的幫助這裏; - ）
好基本的規則，從來沒有推新的頭到遠程倉庫。因爲如果你這樣做了，你將會創造出頭腦，突然在另一個團隊的倉庫中彈出，他們必須合併，這很混亂。除非您指定--force參數，否則Mercurial會對此抱怨。
但除此之外，它是相當標準的票價;您可以指定一個或多個負責合併兩個存儲庫的人員（每天左右），然後從兩個分支中提取所有更改，合併兩個負責人，然後將結果推回到兩個存儲庫，就像任何團隊成員必須執行的操作一樣。如果在合併時推送某些內容，則必須在推送之前進行另一次合併（希望沒有衝突）。
爲了部分自動執行此操作，您可以在兩個團隊存儲庫服務器上設置推後掛鉤，這些服務器異步地將更改推送到其他服務器，並向負責合併的人員發送電子郵件，創建遠程主管。因爲服務器不同步的時間窗口不是很長，所以大部分時間都可能成功。它應該包含一些邏輯，如果它已經在推送，則不推送;如果連接已關閉，則在稍後重試。
好推拉從未遭受合併衝突。因此，兩支球隊仍然有可能獨立進行工作。最後，有人不得不從他的中心位置將多個頭部拉到自己的倉庫併合並頭部。
我預期爲很多;-)因此，推動和拖動多頭中央回購之間的默認分支不應該是一個問題，對嗎？ –
如果兩個團隊都在使用公共代碼庫（即單個祖先存在於回購中），我看不到（除了強制合併匿名分支的頭）同步過程中的任何問題 - 這是標準分支工作流之一「分支與克隆」
即
分離可幫助合併做他的工作更容易
Tnx @ mikezx6r用於修正我*太快輸入*並修復我的印刷錯誤 –
可能重複的[如何同步兩個或更多的Mercurial服務器？]（http://stackoverflow.com/questions/3262782/how-to-sync-two-or-more-mercurial-servers） – amaidment