Questa domanda pone domande sulla replica trasparente , e sospetto che non ci siano ancora risposte perché le persone potrebbero essere bloccate dalla trasparenza. Mi prenderò la libertà di mettere da parte la trasparenza per il momento per concentrarmi sulla replica. Mi occuperò della (o finezza) trasparenza in seguito, e in realtà non penso che sia così importante in un DVCS.
Prima di tutto, lasciatemi scorrere alcuni punti chiave sul modo in cui i repository funzionano in un DVCS. (Conosco molto bene Mercurial, quindi è quello che userò per gli esempi, ma credo che tutto ciò che dico sia vero anche per Git.)
R. In un DVCS, qualsiasi clone contiene lo stesso contenuto e cronologia del file dell'originale.
Se si forniscono i repository correttamente sincronizzati, ciò significa che è possibile utilizzare le normali operazioni di propagazione delle modifiche DVCS (clone, push, pull) e repository ordinari per creare un sistema di replica.
B. Le nuove modifiche non devono essere propagate da dove provengono.
In particolare, se dovessi ottenere modifiche da un determinato repository e aggiungerne alcune, le mie modifiche non devono tornare a quel repository specifico. Possono andare altrove. L'utilità di questo dovrebbe diventare chiara dagli esempi che mostrerò di seguito.
C. Le modifiche possono essere propagate tramite push o pull.
In un sistema centralizzato, i nuovi cambiamenti possono (quasi credo) essere inseriti nel repository. In un DVCS, è possibile impostare una varietà di topologie di propagazione del cambiamento, alcune delle quali comportano solo l'estrazione. Ciò offre una maggiore flessibilità nell'impostazione.
Esempi
Per motivi di discussione, supponiamo che i vostri team distribuiti utilizzino i sistemi nei domini duke.de, duke.us, duke.cn e duke.mx, e inoltre che duke.de è il luogo in cui desideriamo avere il repository "benedetto". Alla luce di questi presupposti, lasciatemi presentare una serie di esempi di diverse topologie che è possibile impostare, tenendo conto dei tre punti DVCS chiave sopra.
0. Modello push centralizzato
Avere un singolo repository su hg.duke.de e fare clonare gli sviluppatori di tutte le posizioni, estrarre da qui e inviare modifiche qui. Questo potrebbe funzionare per la gente in Germania, ma probabilmente sarebbe un problema per le persone nel resto del mondo. Tutte le operazioni di clonazione, pull e push passerebbero attraverso collegamenti di rete a lungo raggio lenti. Questo sta usando un DVCS proprio come un sistema centralizzato. Questo è il problema che stai cercando di risolvere.
1. Push centralizzato con replica
Avere il repository benedetto su hg.duke.de e repliche su hg.duke.cn, hg.duke.mx e hg.duke.us. Gli sviluppatori clonano dalla loro replica locale e inviano le modifiche a hg.duke.de. Ogni volta che appaiono nuove modifiche in hg.duke.de, viene eseguito un hook che le propaga alle repliche. Le repliche sono altrimenti di sola lettura, quindi non ci saranno mai fusioni o conflitti.
Se sono uno sviluppatore in Messico, ad esempio, clonerò da hg.duke.mx ma invierò le modifiche a hg.duke.de. Se altre modifiche vengono inserite in hg.duke.de prima che io possa inviarle, la mia spinta verrà bloccata. Le altre modifiche verranno replicate in hg.duke.mx, quindi estrarrò queste modifiche localmente, unirò e quindi tenterò di inviare nuovamente a hg.duke.de.
Ciò dovrebbe fornire alcuni vantaggi, dal momento che le operazioni di clonazione di grandi dimensioni sono tutte eseguite localmente. La spinta al repository centrale in un'altra posizione potrebbe non essere troppo negativa, poiché le modifiche vengono inviate relativamente di rado, le modifiche incrementali sono generalmente piuttosto piccole. (In particolare Mercurial invia essenzialmente differenze compresse, non interi file e le loro storie.)
In Mercurial, puoi impostare un repository locale per estrarre da una posizione e passare a un'altra inserendo nel .hg/hgrcfile qualcosa di simile al seguente :
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Modello Pull semplice
Continuando con hg.duke.de come repository benedetto e gli altri come repliche, possiamo propagare le modifiche tramite pull anziché push. Gli sviluppatori clonano ed estraggono dalla loro replica locale come al solito. Quando una modifica è pronta, uno sviluppatore invia una richiesta pull a un servizio centrale, che passa dal repository dello sviluppatore a hg.duke.de. Sarà necessario stabilire una politica per le fusioni. Ad esempio, in caso di conflitti di unione, la richiesta potrebbe essere respinta, richiedendo allo sviluppatore di estrarre (dalla replica locale), unire e inviare nuovamente la richiesta di pull.
Questo approccio ha il vantaggio di non far attendere lo sviluppatore durante la propagazione delle modifiche. Ovviamente, lo sviluppatore deve ancora attendere che la richiesta pull venga eseguita, ma almeno lui o lei può lavorare su ulteriori modifiche durante quel periodo.
variazioni
Esistono diverse varianti che possono essere applicate.
L'invio di una richiesta pull è un momento perfetto per la revisione del codice. Le modifiche sono pubblicate, nel senso che sono disponibili per tutti, ma non sono ancora state integrate nel repository benedetto.
Le richieste pull possono essere gestite manualmente o tramite un sistema automatizzato. L'elaborazione di una richiesta pull potrebbe non unire le modifiche direttamente nel repository benedetto, ma invece in un'area di gestione temporanea temporanea in cui viene eseguito un ciclo di generazione e test. Solo dopo aver superato tutti i test, il changeset sarebbe stato integrato nel repository benedetto.
Quelli più a proprio agio con un modello push potrebbero voler impostare un repository di gestione temporanea locale in ogni posizione, insieme alla replica, ad esempio hg-stage.duke.mx, hg-stage.duke.cn, ecc. Ciò richiede un po 'più di lavoro, tuttavia, poiché gli sviluppatori non devono solo fondersi con altri cambiamenti locali, ma qualcuno deve essere responsabile della fusione dei cambiamenti dai repository di gestione temporanea al repository benedetto. Tuttavia, può funzionare nelle giuste circostanze e può essere aiutato dall'automazione.
"Trasparenza"
Ora al problema della replica trasparente.
Dati gli scenari precedenti, non vedo davvero la necessità di una replica trasparente. Tutti i repository sono visibili a tutti e ci sono convenzioni per estrarre / clonare dalla replica locale e spingerli verso un repository benedetto o un'area di stadiazione locale.
Se si desidera la trasparenza, è possibile che le persone configurino i domini di ricerca DNS in base alla loro posizione. La replica locale e i repository di gestione temporanea verrebbero semplicemente denominati "hg" e "hg-stage" e l'installazione DNS li risolverà in hg.duke.cn e hg-stage.duke.cn per gli sviluppatori in Cina e, di conseguenza, per sviluppatori in altre località. Ma questo è un po 'di magia e può essere fonte di confusione, e davvero non penso che aggiunga molto.
Spero che questo risponda alla tua domanda. Mi sono preso alcune libertà con la risposta, ma mi sembra che la tua situazione possa essere risolta attraverso l'uso delle tecniche che ho descritto sopra.