Pergunta

Estou aprendendo mercurial como meu software de solo SCM. Com outro software de gerenciamento, você pode colocar comentários mudança no cabeçalho do arquivo através de tags. Com hg você comentar o conjunto de mudanças, e que não entra a fonte. Eu estou mais utilizado para controle central como VSS.

Por que eu deveria colocar o histórico do arquivo no cabeçalho do arquivo de origem? Devo deixar mercurial gerenciar a história com os meus comentários da alteração?

Foi útil?

Solução

Deixe a alça do sistema de controle de origem-lo.

Se você colocar detalhes da mudança no cabeçalho em breve se tornará pesado e sobrecarregar o código real.

Além disso, se o SCM tem o conceito de changelists (onde muitos arquivos são agrupados em uma única mudança), então você vai ser capaz de escrever o comentário para que se aplique a toda a mudança e não apenas as edições no arquivo de um (se isso faz sentido), dando-lhe uma imagem mais clara de por que a edição foi necessário.

Outras dicas

Sim; deixar que o sistema de controle de origem lidar com seus comentários changeset. A justificativa para isso é que faz muito mais sentido quando você estiver visualizando o log de alterações depois, tentando descobrir o que está acontecendo entre duas versões de um arquivo - o sistema de controle de origem pode apresentar um comentário de alteração para tentar esclarecer a situação .

Não há nenhuma razão para manter manualmente um arquivo histórico quando o software de SCM é muito mais adequado para resolver este problema. Todos os históricos de arquivos Muitas vezes eu vejo parcialmente concluídas na fonte, o que realmente dói, porque as pessoas supõem incorretamente que é preciso.

A diferença não é se é um centralizados ou distribuídos VCS, é mais sobre o que está sendo alterado.

Quando me mudei para .Net, o número de arquivos atualizados para qualquer mudança individual parecia foguete. Se eu tivesse que o log de alterações em cada arquivo, eu nunca obter qualquer trabalho real feito. Ao comentar sobre o conjunto de mudanças, não importa quantos arquivos eu tinha de atualização.

Se algum dia eu necessária para identificar todas as mudanças para uma mudança particular, eu posso diff entre as duas versões do projeto.

A maior diferença (e vantagem) eu vi quando alternar longe de SourceSafe foi a troca de arquivos baseado commits base para projeto. Assim que eu me acostumei a isso, eu parei de adicionar comentários do tipo change-log para todos os meus arquivos.

(Como efeito colateral, eu descobri que o meu processo Mais Comentários ter começado melhor)

Eu não sou um grande defensor de jogar lixo o código com comentários de mudança. No caso eles são necessários podem ser consultados no SCM (pelo menos para o SCM variantes eu usei). Se você quer que eles no arquivo, considere colocá-los no final, em vez do início. Dessa forma, você não terá que se deslocar para baixo após o (desinteressante, pelo menos para mim) comentários antes de chegar ao código real.

Outro voto para deixar a alça do sistema SCM os comentários check-in, mas eu tenho uma coisa a acrescentar.

Alguns sistemas permitem que você use tags de RCS em seu código fonte onde o SCM pode inserir o histórico de alterações diretamente no arquivo de origem a ser cometido automaticamente. Soa como um bom equilíbrio, porque a história é, então, no sistema de SCM e, em seguida, colocar automaticamente no próprio código-fonte.

O problema é que este processo altera do arquivo de origem. Eu acho que é uma má idéia, porque o arquivo não pode ser alterado no disco até depois é inserido você comentários. Se você fosse um bom engenheiro, você deve ter construído e testado alterações antes de o cometer. Se a sua fonte alterações após a confirmação, então você essencialmente tem uma construção que poderia ser quebrado - mas a maioria dos engenheiros não vai construir após uma confirmação -? Por que deveriam

Mas é apenas um comentário que você diz! É verdade, mas eu tive um caso em que não havia código no meu arquivo de origem que curiosamente tinha motivos para olhar como um tag de cabeçalho RCS e que seção do código foi substituído no check-in, munging assim meu código . Fácil o suficiente para fix, mas ruim que uma compilação ficou quebrado por mais de 20 usuários

Muito mais fácil de se esquecer de manter a história na fonte, como um sempre (imo) deve comentar commits ao sistema de controle de origem que dissappers problemas. Além disso, se mudando lotes de arquivos antes de cometer, mudando a história em cada arquivo vai ser um trabalho chato. Este é realmente um dos pontos com ter SCM.

Eu tenho experiência com isso. Eu tive a história de arquivo nos comentários, que era terrível . Nada além de lixo, às vezes, você teria que rolar para baixo quase 1k linhas de alterações no código antes de finalmente conseguiu o que queria. Para não mencionar, você está a abrandar outros aspectos do seu processo de construção, adicionando mais kb a sua árvore de código-fonte.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top