Esta pergunta é sobre replicação transparente , e eu suspeito que ainda não há respostas porque as pessoas podem estar se preocupando com a transparência. Tomei a liberdade de deixar de lado a transparência no momento para focar na replicação. Lidarei com (ou sutileza) a transparência mais tarde e, na verdade, não acho tão importante em um DVCS.
Primeiro, deixe-me examinar alguns pontos-chave sobre como os repositórios funcionam em um DVCS. (Eu estou mais familiarizado com o Mercurial, então é isso que vou usar como exemplo, mas acredito que tudo o que digo também se aplica ao git.)
R. Em um DVCS, qualquer clone contém o mesmo conteúdo e histórico de arquivos que o original.
Desde que você mantenha os repositórios adequadamente em sincronia, isso significa que você pode usar operações comuns de propagação de alterações do DVCS (clonar, empurrar, puxar) e repositórios comuns para criar um sistema de replicação.
B. Novas mudanças não precisam ser propagadas para onde elas vieram.
Em particular, se eu quiser obter alterações de um repositório específico e adicionar algumas alterações, minhas alterações não precisarão retornar a esse repositório específico. Eles podem ir para outro lugar. A utilidade disso deve ficar clara nos exemplos que mostrarei abaixo.
C. As alterações podem ser propagadas via push ou pull.
Em um sistema centralizado, as novas mudanças podem praticamente (eu acho) apenas ser introduzidas no repositório. Em um DVCS, é possível configurar uma variedade de topologias de propagação de alterações, algumas das quais envolvem apenas puxar. Isso oferece mais flexibilidade na configuração.
Exemplos
Para fins de discussão, digamos que suas equipes distribuídas usem sistemas nos domínios duke.de, duke.us, duke.cn e duke.mx e, além disso, é nesse ponto que queremos que o repositório seja "abençoado". Dadas essas suposições, deixe-me apresentar vários exemplos de diferentes topologias que você pode configurar, tendo em mente os três pontos principais do DVCS acima.
0. Modelo de envio centralizado
Tenha um único repositório em hg.duke.de e faça com que os desenvolvedores em todos os locais clonem, extraam daqui e enviem alterações aqui. Isso pode funcionar para o pessoal da Alemanha, mas provavelmente seria um problema para as pessoas no resto do mundo. Todas as operações de clonagem, extração e envio passariam por links de rede de longo curso lentos. Isso está usando um DVCS como um sistema centralizado. Este é o problema que você está tentando resolver.
1. Push centralizado com replicação
Tenha o repo abençoado em hg.duke.de e réplicas em hg.duke.cn, hg.duke.mx e hg.duke.us. Os desenvolvedores clonam sua réplica local e enviam as alterações para hg.duke.de. Sempre que novas alterações aparecem no hg.duke.de, é executado um gancho que as propaga para as réplicas. Caso contrário, as réplicas são somente leitura, portanto, nunca haverá fusões ou conflitos.
Se eu sou desenvolvedor no México, por exemplo, clonarei hg.duke.mx, mas transferirei as alterações para hg.duke.de. Se outras alterações forem enviadas para hg.duke.de antes que eu possa enviar minhas alterações, meu envio será bloqueado. As outras alterações serão replicadas para hg.duke.mx, portanto, puxarei essas alterações localmente, mesclarei e tentarei enviar para hg.duke.de novamente.
Isso deve fornecer algumas vantagens, pois as operações de grande clone são feitas localmente. Enviar para o repositório central em outro local pode não ser muito ruim, uma vez que as alterações são enviadas com pouca frequência, as alterações incrementais geralmente são pequenas. (O Mercurial em particular envia essencialmente diffs compactados, não arquivos inteiros e seus históricos.)
No Mercurial, você pode configurar um repositório local para extrair de um local e enviar para outro, colocando algo como o seguinte no .hg/hgrcarquivo:
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Modelo de tração simples
Continuando com hg.duke.de como o repo abençoado e os outros como réplicas, podemos propagar alterações por meio de pull em vez de push. Os desenvolvedores clonam e extraem da réplica local, como de costume. Quando uma alteração está pronta, o desenvolvedor envia uma solicitação de recebimento a algum serviço central, que é transferido do repositório do desenvolvedor para hg.duke.de. Uma política precisará ser estabelecida para mesclagens. Por exemplo, se houver conflitos de mesclagem, a solicitação poderá ser rejeitada, exigindo que o desenvolvedor retire (da réplica local), mescle e reenvie a solicitação de retirada.
Essa abordagem tem a vantagem de não fazer o desenvolvedor esperar enquanto as alterações estão sendo propagadas. Obviamente, o desenvolvedor ainda precisa aguardar a solicitação de recebimento, mas pelo menos ele ou ela pode trabalhar em alterações adicionais durante esse período.
Variações
Há várias variações que podem ser aplicadas.
O envio de uma solicitação pull é um momento perfeito para a revisão do código. As mudanças são publicadas, no sentido de que estão disponíveis para todos, mas ainda não foram integradas ao repo abençoado.
As solicitações de recebimento podem ser acionadas manualmente ou por algum sistema automatizado. O processamento de uma solicitação pull pode não mesclar as alterações diretamente no repositório abençoado, mas em uma área temporária de preparação, onde é feito um ciclo de construção e teste. Somente depois de passar em todos os testes, o changeset seria integrado ao repositório abençoado.
Os que se sentem mais à vontade com um modelo push podem querer configurar um repositório de armazenamento temporário local em cada local, juntamente com a réplica, por exemplo, hg-stage.duke.mx, hg-stage.duke.cn, etc. Isso requer um pouco mais de trabalho, no entanto, como os desenvolvedores não apenas precisam se unir a outras alterações locais, mas alguém deve ser responsável por mesclar as alterações dos repositórios de teste no repositório abençoado. Porém, isso pode funcionar nas circunstâncias certas e pode ser auxiliado pela automação.
"Transparência"
Agora, para a questão da replicação transparente.
Dado os cenários acima, eu realmente não vejo a necessidade de replicação transparente. Todos os repositórios são visíveis para todos e existem convenções para obter / clonar da réplica local e enviar para um repositório abençoado ou uma área de preparação local.
Se você deseja transparência, é possível que as pessoas configurem domínios de pesquisa DNS de acordo com a localização. A réplica local e os repositórios de armazenamento temporário seriam simplesmente referidos como "hg" e "hg-stage" e a configuração do DNS os resolveria em hg.duke.cn e hg-stage.duke.cn para desenvolvedores na China, e correspondentemente para desenvolvedores em outros locais. Mas isso é um pouco de mágica e pode ser confuso, e eu realmente não acho que isso adicione muito.
Espero que isso responda à sua pergunta. Tomei várias liberdades com a resposta, mas parece-me que sua situação poderia ser remediada através do uso das técnicas que descrevi acima.