SVN - Como faço para interceptar e alterar ou adicionar arquivos no pré -compromisso?

Question

Primeiro de tudo, não tenho certeza se isso é possível, no entanto, preciso saber como isso pode ser feito e se não por que não?

Quero criar um aplicativo C# que seja executado no momento apropriado durante o processo de confirmação de um repositório de subversão (pré-compromisso, acredito) que adicionará outro arquivo a ser comprometido.

Por exemplo, eu faço alterações no programa.cs e main.cs, mas NÃO AssemblyInfo.cs. Quero poder forçar uma alteração no AssemblyInfo.cs ou a qualquer arquivo para esse assunto.

Escrevi um aplicativo de console usando o SharpsVN que disparou no pós-compromisso, que substituiu um arquivo, mas isso causou um incremento no número de revisão. Obviamente, isso não é o ideal.

Encontrei então o SvnLookClient dentro do Sharpsvn que funciona no pré-compromisso e comecei a escrever algo, mas acertei um beco sem saída quando percebi que o copyfrompath não quis dizer o que eu esperava:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

Como alternativa, vou me contentar em fazer isso fora do C#, mas, idealmente, gostaria de fazê -lo em um aplicativo de console C#, para que eu também possa dizer ao meu servidor de repositório para executar outras tarefas, como executar em scripts de banco de dados, etc.

Answer 1

Você não deve modificar a transação durante um script de gancho. Você pode rejeitar o commit com uma mensagem (Stderr será enviado ao cliente), ou faça-o em um compromisso separado no pós-compromisso.

Editar] Eu quero esclarecer Por quê Modificar transações é uma má idéia (SVN-technicamente):

O cliente não sabe nada sobre isso.

Exceto por "ok", "falhou" e a saída STDERR, não há canal traseiro do servidor para o cliente durante uma confirmação.

Quando o cliente compromete suas alterações e é relatado que o compromisso é bem -sucedido, ele marca seu status de arquivo e pasta local a ser sincronizado com a versão do repositório [xyz]. Quando você mais tarde muda algo, por exemplo, adicione o arquivo localmente, ele quer cometer essas mudanças, mas então ... bem, você pode tentar saber o que acontece, espero algo ao longo de "erro de soma de verificação" ou "arquivo já adicionado" . Dependendo do tipo de alterações, você provavelmente não terá melhor chance de obter um WC funcionando do que excluir a pasta e fazer uma nova finalização da peça danificada.

Essa era a parte técnica. Agora, o lado do desenvolvedor: primeiro, a fixação automática de alterações corretamente parece inteligente, mas falhará, devido ao simples fato de que, se a fonte fosse pré-computável, não precisaríamos deixá-lo escrever pelos desenvolvedores. Você quer que seus desenvolvedores façam a coisa certa.

Isso funciona melhor via educação: eles precisam conhecer Qual é a coisa certa. Boas medidas para que eles saibam que algo é, adicional para um bom treinamento antigo de qualquer tipo, dando -lhes feedback.

Uma mensagem de erro do servidor SVN, um correio automatizado após compilações quebradas ou testes unitários, resulta de uma ferramenta de análise de código de origem estática etc., também pode servir como uma boa ferramenta educacional.

Eu recomendaria usar a integração continua e validar a árvore de origem lá. Isso tem as vantagens de que um desenvolvedor não será bloqueado para cometer suas mudanças após um longo dia útil, mas você ainda conhece esse status da árvore de origem.

E agora acho que o que você deseja tentar: a árvore de origem do lado do servidor sempre deve ser "funcional". Então, o problema é que, mesmo com fixação automática de arquivo, pré-compromisso, teste de unidade, verificação de estilo e o que quer que seja, você finalmente, ainda precisa verificar se o programa realmente funciona, com teste de sistema antigo. Então, basicamente, você realmente não ganha nada.

A tecnologia pode suportar processos, as ferramentas bem pensadas suportam-a tão bem que os processos a seguir ajudam os desenvolvedores a economizar tempo e tornar seu fluxo de trabalho mais simples. Mas a tecnologia geralmente não pode substituir os processos e não pode substituir a inteligência humana (pelo menos, por enquanto). [/editar