No Mercurial, como posso vincular vários commits a um único problema em nosso bugtracker?

Question

Atualmente, usamos svn e, através do usuário de hooks, podemos garantir que toda mensagem de commit seja prefixada por um número de bug (que liga os commits a um relatório de problema em nosso rastreador de problemas do Bugzilla.)

Queremos mudar para o mercurial com toda a sua bondade distribuída. Mas um dos benefícios do hg é que os desenvolvedores não precisam necessariamente estar on-line para confirmar as alterações, portanto, não queremos que scripts de gancho validem números de bugs em relação ao nosso recurso central do Bugzilla.

Eu posso estar vindo de uma perspectiva svn demais, mas o que eu acho que eu quero é que os desenvolvedores possam especificar um número de bug no momento em que o desenvolvedor decide empurrar sua mudança para um repo de teste central. O principal requisito aqui é que queremos poder vincular os commits a um bug do Bugzilla, mas não queremos dar aos desenvolvedores um fluxo de trabalho complexo e manual (que a extensão do Attic, por exemplo, parece impor).

Alguma idéia?

    

Answer 1

O importante a lembrar é que changesets são (quase) imutáveis, o que significa que é tarde demais para adicionar um número de bug quando os desenvolvedores estão executando hg push . O comando push está apenas movendo as mudanças ao redor, não alterando-as.

No entanto, hg push é, claro, um bom momento para atualizar o Bugzilla, já que os desenvolvedores estão online ao enviar para o repositório central. Então você poderia pedir aos desenvolvedores para instalar um gancho como

[hooks]
pre-push.bugzilla = pick-bug-number.sh

O script pick-bug-number.sh deve primeiro checar se os desenvolvedores estão empurrando para o seu repositório central (e não, digamos, para algum outro repositório em seu laptop) e então pedir um número de bug. Quando o desenvolvedor digita o número do bug, o script pode olhar para hg outgoing e associar os changesets de saída com o bug no Bugzilla.

Essa é uma maneira de associar conjuntos de alterações a um rastreador de problemas externo. Não haverá nada nos changesets que os ligam a um bug do Bugzilla - é apenas o Bugzilla que sabe que changesets pertencem a quais bugs.

Outra forma seria incorporar os números de bugs nos conjuntos de alterações. Isso pode ser feito com ramos nomeados no Mercurial. Já seus desenvolvedores executam

$ hg branch bug-123

antes de começar a trabalhar no bug número 123. Os seguintes commits conterão o rótulo "bug-123" dentro deles. Ao enviar para o servidor, é fácil analisar os changesets enviados (em um changegroup hook) e atualizar o Bugzilla.

Você também pode pedir aos desenvolvedores para colocar o número do bug na mensagem de commit, assim como no Subversion. Não haverá qualquer validação online, mas eles podem seguir praticamente o mesmo fluxo de trabalho do Subversion. A validação da mensagem de confirmação é melhor configurando ui.editor . Faça um script personalizado que peça um número de bug, coloque-o em um modelo de mensagem de commit e então inicie e edite para permitir que os desenvolvedores digam a mensagem de commit.

Usar mensagens de confirmação é melhor do que usar ramificações nomeadas se você planeja ter milhares de números de bugs. O próprio Mercurial é bastante escalável com o número de ramificações nomeadas, mas muitas ferramentas esperam poder mostrar todas as ramificações em um único menu suspenso. Isso funciona bem quando você tem 10 ou 20 deles, mas falha quando você tem 5.000 deles. É realmente mais uma coisa de interface do usuário, mas pode voltar e te morder por muito tempo depois de ter iniciado este sistema.

    

Answer 2

Você pode, por exemplo, executar o script cron no lado do servidor, verificando o log mercurial (usando o log hg) e atualizando o Bugzilla com o número do problema encontrado no log. Por exemplo, o parâmetro --date 2011-01-26 para hg log fornece apenas mensagens de log durante um dia específico, que é muito mais rápido processar do que todas as entradas de log de cada vez.

Você não pode adicionar mensagens ao enviar para o servidor, somente ao confirmar.