Estou trabalhando em um ambiente que está usando um servidor subversion em um local central, que precisa alimentar seu conteúdo em 4 ambientes diferentes (prod, test, etc ...). Nesses ambientes, não precisamos da funcionalidade de subversão de todo, meramente para poder acessar o conteúdo de todas as / tags / mantidas dentro do repositório por http e sistema de arquivos local.
Para fazer isso, temos duas abordagens possíveis:
1) espelhos de subversão em todos os ambientes, atualizados usando o svnsync e disponibilizados em cada local via svn - > web_dav_svn - > davfs (acesso FS aqui) - > apache (acesso HTTP aqui)
2) svn exportação de / tags em um local central e, em seguida, rsyncing os arquivos para os outros locais, possivelmente depois de ter hardlinked a estrutura de arquivos exportados anteriormente.
Embora a opção 1 pareça "mais flexível" em muitos aspectos (apesar de passar pelo apache duas vezes ???), ela empurra muito do risco para um ambiente de execução ao vivo, em vez de mantê-la de volta no local central, que é essencialmente " offline "na medida em que nunca está sendo usado na execução desses ambientes. Eu também estaria preocupado em colocar um projeto de fusível praticamente descartável e ignorado como davfs tão profundamente no projeto. O rsync é entediante e estável, e visto que tudo o que queremos é o acesso a arquivos em nossos próprios termos, podemos obter isso com um conjunto de ferramentas realmente básico e confiável.
Quaisquer pensamentos realmente apreciados.
Seus instintos estão corretos. A opção 1 parece introduzir muita complexidade para um ganho relativamente pequeno.
A opção 2 seria fácil de implementar com um gancho post-commit que atualiza uma cópia de trabalho do repositório e, em seguida, usa o rsync para enviar o repositório para os destinos necessários. Atualizar uma cópia de trabalho local - em vez de usar svn export - será muito mais eficiente se seu repositório for grande.
O gancho post-commit pode funcionar, mas leva a possíveis danos se houver atividade de gravação no meio do rsync. Além disso, as atualizações locais seriam eficientes, mas não garantiriam uma compilação impecável de cada tag, pois poderia haver alterações locais introduzidas.
Você pode querer considerar um produto comercial como o Subversion MultiSite que manterá uma réplica exata dos repositórios em cada local . Essas réplicas locais são atualizadas automaticamente conforme as alterações são feitas e fornecem o desempenho da LAN em cada nó.
1) subversion mirrors in all environments, updated using svnsync and then made available within each location via svn -> web_dav_svn -> davfs (FS access here) -> apache (HTTP access here)
Você não precisa executar o apache para ter acesso ao repositório svn, especialmente quando apenas um usuário terá acesso a ele. O repositório pode ser acessado pelo protocolo file:// se estiver armazenado na unidade local.
O uso do svnsync pode ser complexo, mas uma vez configurado, você raramente terá que lidar. Sobre o único problema que eu tive com o uso do svnsync em vários locais é o bloqueio ocasional do svnsync que não é liberado, que pode ser rapidamente corrigido e então tudo é mais uma vez atualizado rapidamente. Eu teria que acontecer uma vez ou duas vezes por ano com três servidores sincronizados do servidor central.
A outra vantagem do svnsync, se você precisar do outro código, está lá. Você não precisa passar por outro processo de configuração para obter o conteúdo adicional.
E a última, mas provavelmente a melhor razão para vários locais svnsync, prontos para serem executados no failover se o seu repositório central mergulhar de maneira dura e irrecuperável.
Tags rsync svn apache-2.2