esta é a minha primeira pergunta aqui e, na verdade, uma mudança do StackOverflow, pois acho que este site estará mais em sincronia com o tópico.
Configurei o espelhamento do meu repositório e ele funciona bem, mas tive um problema recentemente.
O repositório de destino foi deixado com um bloqueio não liberado de alguma forma - pelo que eu li isso pode ser causado por um aborto para a operação svnsync e eu suspeito que pode ser porque no meu gancho post-commit estou executando o svnsync no modo de bloqueio em vez de empurrá-lo para o fundo via &.
Eu faço isso para que o usuário possa ter certeza de que, se o commit terminou, então ele está em todos os repositórios agora, mas talvez ele apresente o risco deles cancelarem e pararem o hook de commit?
Não consigo encontrar diretrizes ou sugestões claras sobre qual é a melhor ou qual é a melhor prática, ou mesmo se clicar em cancelar pode causar um aborto do gancho post commit e a sincronização executada a partir dele - na maioria dos lugares, vejo pessoas usando & chutar da sincronização em segundo plano - isso evita a corrupção do bloqueio no caso de um usuário pressionar cancelar a sua confirmação enquanto a sincronização está em andamento? Como você certifica-se de que ambos os repositórios estão realmente em sincronia ou reportam problemas? Você precisa de um mecanismo de notificação separado para isso?
Atualização:
Das duas opções acima decidi escolher o terceiro;)
Estou chamando o svnsync em segundo plano, mas ao mesmo tempo faço o hook esperar que ele termine:
svnsync ... &
wait $!
Acho que isso se junta ao melhor dos dois mundos, mas o tempo mostrará o quão eficiente será - por favor, deixe-me saber o que você pensa sobre o assunto e quais sugestões você pode ter para compartilhar sobre isso.
Update2: Isso não resolveu o problema - aparentemente, quando o gancho é morto, ele também mata seus processos filhos: (
Alguém teria alguma dica sobre como lidar com isso? Eu realmente gostaria que meus usuários pudessem saber e confiar que, quando eles virem o commit completo, significa que todos os sites estão em sincronia.
Update3: O tempo passa e os problemas aparecem - por ~ 2 anos minha abordagem funcionou muito bem - eu disparei da sincronização sem bloqueio e não esperei por ela - e na semana passada nosso espelho explodiu provavelmente devido a 2 commits diferentes executados pelos usuários no mesmo segundo (ambos sucedendo no master :)) - o resultado foi que o svnsync não copiou as propriedades de revisão corretamente mas também criou algumas revisões estranhas (basicamente copiou um commit e criou uma revisão separada dele e o atribuiu ao usuário svnsync). E então reclamou sobre "alguém" fazendo alterações diretamente no repositório de espelhos. Com nenhuma maneira de remover commits no SVN eu tive que ir de 0 para HEAD-2, que para um repositório strong de 162GB levou um bom tempo. Agora - depois de alguns dias restaurando ações - modifiquei minha sincronização um pouco como sugerido abaixo.
Isso garante que o sistema seja razoavelmente responsivo e que o svnsync nunca seja chamado mais de uma vez - eu atualizarei isso com informações uma vez que o tempo forneça mais dados.
Eu consideraria mover isso de um gancho post-commit para uma tarefa incrond, que usaria inotify para monitorar o repositório para mudanças e então executar a tarefa svnsync.
Como uma configuração mais modular, ele me forneceria mais flexibilidade com uma configuração unificada - ou seja, eu não precisaria continuar atualizando os ganchos pós-confirmação de vários usuários.
Tags svn