Bei dieser Frage geht es um transparente Replikation, und ich vermute, dass es noch keine Antworten gibt, da die Leute möglicherweise auf Transparenz aus sind. Ich werde mir erlauben, Transparenz für den Moment beiseite zu legen, um mich auf die Replikation zu konzentrieren. Ich werde mich später mit (oder Finesse) Transparenz befassen, und tatsächlich denke ich nicht, dass es in einem DVCS so wichtig ist.
Lassen Sie mich zunächst einige wichtige Punkte zur Funktionsweise von Repositorys in einem DVCS erläutern. (Ich bin mit Mercurial am besten vertraut, daher werde ich das als Beispiel verwenden, aber ich glaube, dass alles, was ich sage, auch für Git gilt.)
A. In einem DVCS enthält jeder Klon denselben Dateiinhalt und Verlauf wie das Original.
Vorausgesetzt, Sie halten die Repos ordnungsgemäß synchron, können Sie normale Replikationsvorgänge für DVCS-Änderungen (Klonen, Drücken, Ziehen) und normale Repos verwenden, um ein Replikationssystem zu erstellen.
B. Neue Änderungen müssen nicht an den Ort weitergegeben werden, von dem sie stammen.
Insbesondere wenn ich Änderungen von einem bestimmten Repo erhalten und einige eigene Änderungen hinzufügen möchte, müssen meine Änderungen nicht auf dieses bestimmte Repo zurückgehen. Sie können woanders hingehen. Der Nutzen davon sollte anhand der Beispiele deutlich werden, die ich unten zeigen werde.
C. Änderungen können durch Drücken oder Ziehen weitergegeben werden.
In einem zentralisierten System können neue Änderungen (glaube ich) so gut wie nur in das Repo übernommen werden. In einem DVCS ist es möglich, eine Vielzahl von Änderungsausbreitungstopologien einzurichten, von denen einige nur das Ziehen umfassen. Dies bietet mehr Flexibilität bei der Einrichtung.
Beispiele
Nehmen wir zur Diskussion an, Ihre verteilten Teams verwenden Systeme in den Domänen duke.de, duke.us, duke.cn und duke.mx. Außerdem möchten wir in duke.de das "gesegnete" Repo haben. Lassen Sie mich unter diesen Voraussetzungen einige Beispiele für verschiedene Topologien erläutern, die Sie unter Berücksichtigung der drei oben genannten wichtigen DVCS-Punkte einrichten können.
0. Zentrales Push-Modell
Haben Sie ein einziges Repo auf hg.duke.de und lassen Sie die Entwickler an allen Standorten von hier aus klonen und ziehen und Änderungen hier pushen. Dies könnte für die Menschen in Deutschland funktionieren, aber es wäre wahrscheinlich ein Problem für die Menschen im Rest der Welt. Alle Klon-, Pull- und Push-Vorgänge würden über langsame Langstrecken-Netzwerkverbindungen erfolgen. Dies verwendet ein DVCS genau wie ein zentrales System. Dies ist das Problem, das Sie lösen möchten.
1. Zentraler Push mit Replikation
Haben Sie das gesegnete Repo bei hg.duke.de und Repliken bei hg.duke.cn, hg.duke.mx und hg.duke.us. Entwickler klonen von ihrem lokalen Replikat und übertragen Änderungen an hg.duke.de. Immer wenn neue Änderungen in hg.duke.de angezeigt werden, wird ein Hook ausgeführt, der sie an die Replikate weitergibt. Die Replikate sind ansonsten schreibgeschützt, sodass es niemals zu Zusammenführungen oder Konflikten kommt.
Wenn ich zum Beispiel ein Entwickler in Mexiko bin, klone ich von hg.duke.mx, drücke aber Änderungen an hg.duke.de. Wenn andere Änderungen in hg.duke.de übertragen werden, bevor ich meine Änderungen übertragen kann, wird mein Push blockiert. Die anderen Änderungen werden in hg.duke.mx repliziert, daher werde ich diese Änderungen lokal abrufen, zusammenführen und dann versuchen, erneut auf hg.duke.de zu pushen.
Dies sollte einige Vorteile bieten, da die großen Klonvorgänge alle lokal ausgeführt werden. Das Verschieben in das zentrale Repo an einem anderen Ort ist möglicherweise nicht schlecht, da Änderungen relativ selten übertragen werden und inkrementelle Änderungen im Allgemeinen relativ gering sind. (Insbesondere Mercurial sendet im Wesentlichen komprimierte Diffs, nicht ganze Dateien und deren Verlauf.)
In Mercurial können Sie ein lokales Repo einrichten, um von einem Ort zum anderen zu wechseln, indem Sie Folgendes in die .hg/hgrcDatei einfügen:
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Einfaches Pull-Modell
Wenn wir mit hg.duke.de als gesegnetem Repo und den anderen als Replik fortfahren, können wir Änderungen per Pull statt Push weitergeben. Entwickler klonen und ziehen wie gewohnt von ihrem lokalen Replikat. Wenn eine Änderung fertig ist, sendet ein Entwickler eine Pull-Anfrage an einen zentralen Dienst, der vom Entwickler-Repo in hg.duke.de zieht. Für Zusammenschlüsse muss eine Richtlinie festgelegt werden. Wenn beispielsweise Zusammenführungskonflikte auftreten, wird die Anforderung möglicherweise abgelehnt, sodass der Entwickler die Pull-Anforderung abrufen (vom lokalen Replikat) zusammenführen und erneut senden muss.
Dieser Ansatz hat den Vorteil, dass der Entwickler nicht warten muss, während Änderungen weitergegeben werden. Natürlich muss der Entwickler noch warten, bis die Pull-Anfrage bearbeitet wird, aber zumindest kann er oder sie während dieser Zeit an zusätzlichen Änderungen arbeiten.
Variationen
Es gibt eine Reihe von Variationen, die angewendet werden können.
Die Übermittlung einer Pull-Anfrage ist der perfekte Zeitpunkt für die Codeüberprüfung. Die Änderungen werden in dem Sinne veröffentlicht, dass sie allen zur Verfügung stehen, aber noch nicht in das gesegnete Repo integriert wurden.
Pull-Anforderungen können manuell oder von einem automatisierten System bearbeitet werden. Durch die Verarbeitung einer Pull-Anforderung werden Änderungen möglicherweise nicht direkt in das gesegnete Repo eingefügt, sondern in einen temporären Staging-Bereich, in dem ein Build- und Testzyklus durchgeführt wird. Erst nach Bestehen aller Tests wird das Änderungsset in das gesegnete Repo integriert.
Diejenigen, die mit einem Push-Modell besser vertraut sind, möchten möglicherweise an jedem Ort neben dem Replikat ein lokales Staging-Repo einrichten, z. B. hg-stage.duke.mx, hg-stage.duke.cn usw. Dies erfordert etwas mehr Arbeit. Entwickler müssen sich jedoch nicht nur mit anderen lokalen Änderungen zusammenschließen, sondern jemand muss dafür verantwortlich sein, Änderungen aus den Staging-Repos in das gesegnete Repo zusammenzuführen. Dies kann jedoch unter den richtigen Umständen funktionieren und durch Automatisierung unterstützt werden.
"Transparenz"
Nun zum Thema der transparenten Replikation.
Angesichts der oben genannten Szenarien sehe ich keine Notwendigkeit für eine transparente Replikation. Alle Repos sind für alle sichtbar, und es gibt Konventionen zum Abrufen / Klonen von der lokalen Replik und zum Verschieben zu einem gesegneten Repo oder einem lokalen Staging-Bereich.
Wenn Sie Transparenz wünschen, können Benutzer DNS-Suchdomänen entsprechend ihrem Standort einrichten. Das lokale Replikat und die Staging-Repos würden einfach als "hg" und "hg-stage" bezeichnet, und das DNS-Setup würde diese für Entwickler in China und entsprechend für hg.duke.cn und hg-stage.duke.cn auflösen Entwickler an anderen Standorten. Aber das ist ein bisschen magisch und kann verwirrend sein, und ich denke wirklich nicht, dass es viel hinzufügt.
Ich hoffe das beantwortet deine Frage. Ich habe mir bei der Antwort eine Reihe von Freiheiten genommen, aber es scheint mir, dass Ihre Situation durch den Einsatz der oben beschriebenen Techniken behoben werden könnte.