この質問は透過的なレプリケーションについて尋ねていますが、人々は透過性に夢中になっている可能性があるため、まだ答えはないと思います。とりあえず、透明性を脇に置いてレプリケーションに焦点を当てます。透明性については後で説明します（実際、DVCSではそれほど重要ではないと思います）。
まず、DVCSでリポジトリが機能する方法について、いくつかの重要なポイントを説明します。（私はMercurialに最も慣れているので、それを例として使用しますが、私が言うことはすべてgitにも当てはまると思います。）
A. DVCSでは、どのクローンにもオリジナルと同じファイルの内容と履歴が含まれています。
リポジトリを適切に同期させておけば、通常のDVCS変更伝播操作（クローン、プッシュ、プル）と通常のリポジトリを使用してレプリケーションシステムを構築できます。
B.新しい変更を元の場所に反映させる必要はありません。
特に、特定のリポジトリから変更を取得し、独自の変更を追加する場合、私の変更はその特定のリポジトリに戻る必要はありません。彼らはどこかに行くことができます。これの有用性は、以下に示す例から明らかになります。
C.変更は、プッシュまたはプルを介して伝播できます。
一元化されたシステムでは、新しい変更はほとんど（おそらく）リポジトリにプッシュされるだけです。DVCSでは、さまざまな変更伝播トポロジを設定できます。その一部はプルのみを含みます。これにより、セットアップの柔軟性が向上します。
例
議論のために、分散チームがドメインduke.de、duke.us、duke.cn、およびduke.mxのシステムを使用しているとします。さらに、duke.deには、「祝福された」リポジトリを配置したいとします。これらの前提を踏まえて、上記の3つの主要なDVCSポイントを念頭に置いて、設定できるさまざまなトポロジのいくつかの例を示します。
0.集中型プッシュモデル
hg.duke.deに単一のリポジトリを用意し、すべての場所の開発者にここからクローンを作成してプルし、変更をここにプッシュします。これはドイツの人々にとってはうまくいくかもしれませんが、他の世界の人々にとってはおそらく問題になるでしょう。すべてのクローン、プル、プッシュ操作は、低速の長距離ネットワークリンクを通過します。これは、集中型システムのようにDVCSを使用しています。これはあなたが解決しようとしている問題です。
1.レプリケーションによる集中型プッシュ
祝福されたレポをhg.duke.deに、レプリカをhg.duke.cn、hg.duke.mx、およびhg.duke.usに用意します。開発者はローカルレプリカからクローンを作成し、変更をhg.duke.deにプッシュします。新しい変更がhg.duke.deに表示されるたびに、それらの変更をレプリカに伝達するフックが実行されます。それ以外の場合、レプリカは読み取り専用であるため、マージや競合は発生しません。
たとえば、メキシコの開発者であれば、hg.duke.mxからクローンを作成しますが、変更をhg.duke.deにプッシュします。変更をプッシュする前に、他の変更がhg.duke.deにプッシュされると、プッシュがブロックされます。その他の変更はhg.duke.mxにレプリケートされるので、これらの変更をローカルでプルし、マージしてから、もう一度hg.duke.deにプッシュしようとします。
大きなクローン操作はすべてローカルで行われるため、これにはいくつかの利点があります。別の場所にある中央レポジトリにpushしてもそれほど変わらない可能性があります。変更が比較的頻繁にpushされることはないため、増分変更は一般にかなり小さいからです。（特に、Mercurialは本質的に、ファイル全体とその履歴ではなく、圧縮された差分を送信します。）
Mercurialでは、.hg/hgrcファイルに次のように入力することで、ある場所からプルし、別の場所にプッシュするようにローカルリポジトリを設定できます。
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2.単純なプルモデル
祝福されたレポとしてhg.duke.deを続け、レプリカとして他のリポジトリを続けると、プッシュの代わりにプルを介して変更を伝播できます。開発者は通常どおり、ローカルレプリカのクローンを作成してプルします。変更の準備ができると、開発者はプルリクエストをいくつかの中央サービスに送信し、中央サービスは開発者のリポジトリからhg.duke.deにプルします。マージにはポリシーを確立する必要があります。たとえば、マージの競合がある場合、要求は拒否され、開発者はプル（ローカルレプリカから）、マージ、およびプル要求の再送信を要求されます。
このアプローチには、変更が伝播されている間、開発者を待たせないという利点があります。もちろん、開発者はプルリクエストが実行されるのを待つ必要がありますが、少なくともその間、追加の変更に取り組むことができます。
バリエーション
適用できるバリエーションはたくさんあります。
プルリクエストの送信は、コードレビューに最適なタイミングです。変更はすべての人が利用できるという意味で公開されていますが、まだ祝福されたリポジトリに統合されていません。
プルリクエストは、手動または自動システムで実行できます。プルリクエストを処理しても、変更をblessされたリポジトリに直接マージするのではなく、ビルドとテストサイクルが行われる一時的なステージング領域にマージする場合があります。すべてのテストに合格した後でのみ、変更セットは祝福されたレポに統合されます。
プッシュモデルに慣れている方は、hg-stage.duke.mx、hg-stage.duke.cnなどのレプリカとともに、各場所にローカルステージングリポジトリをセットアップすることをお勧めします。これには、もう少し作業が必要です。ただし、開発者は他のローカルの変更に対してマージする必要があるだけでなく、誰かがステージングリポジトリから祝福されたリポジトリに変更をマージする責任を負う必要があるためです。ただし、これは適切な状況で機能し、自動化によって支援できます。
「透明性」
次に、透過的なレプリケーションの問題について説明します。
上記のシナリオを考えると、透過的なレプリケーションの必要性は実際にはわかりません。すべてのリポジトリは誰でも見ることができ、ローカルレプリカからプル/クローニングし、祝福されたレポまたはステージングエリアにプッシュするための規則があります。
透明性が必要な場合は、場所に応じてDNS検索ドメインを設定することができます。ローカルレプリカとステージングリポジトリは単に「hg」および「hg-stage」と呼ばれ、DNSセットアップはこれらを中国の開発者向けにhg.duke.cnおよびhg-stage.duke.cnに解決します。他の場所の開発者。しかし、これはちょっとした魔法であり、混乱を招く可能性があります。
これがあなたの質問に答えてくれることを願っています。私は多くの自由をもって対応しましたが、私が上で説明したテクニックを使用することであなたの状況が改善されるように思えます。