Como você gerencia pequenas alterações que deseja manter local no mercurial?

Estou pensando em migrar um repositório cvs de 14 anos (histórico intacto) para o mercurial. Acho que já reduzi todos os bits técnicos de conversão, mas ainda tenho algumas dúvidas sobre como trabalhar efetivamente em mercurial.

Uma das coisas que vejo muito nas caixas de proteção de CV de desenvolvedores individuais (incluindo a minha) são as alterações locais não confirmadas, que não estão prontas para serem enviadas à linha principal. Meu entendimento é que isso é uma coisa ruim. A maioria das minhas experiências com hg sugere que mudanças não confirmadas são uma coisa ruim de se ter. A incapacidade de se fundir com eles é suficiente para isso. Então, o que eu quero saber é como outras pessoas que usam o mercurial no dia-a-dia lidam com isso. Como você lida com alterações incompletas no código quando chega a hora de atualizar seu repositório? Como você lida com as mudanças locais que você ainda não deseja compartilhar com outros desenvolvedores?

Eu trato dessa maneira:

No meu repositório local, eu confirmo todas as alterações, mesmo se estiver experimentando. Se eu estiver bem com o experimento, e ele for testado, eu o envio ao repositório remoto. Caso contrário, ele permanece no meu repositório local (ou volte para uma revisão mais antiga).

A idéia é que o repositório remoto contenha apenas versões testadas e em funcionamento dos meus projetos.

Vou acrescentar algumas coisas.

Uma é sugerir um fluxo de trabalho que faça uso criterioso das prateleiras , que são fornecidas como padrão no TortoiseHg .

Sempre que eu quisesse confirmar parte do meu diretório de trabalho atual, arquivaria as alterações que não queria confirmar, recompilaria (para garantir que não arquivei bits que agora resultam em uma compilação interrompida) e executaria meus testes . Então eu comprometia o conjunto completo, funcional e testado. Por fim, eu executava unshelve para restaurar minhas alterações.

Se eu tivesse alterações mais permanentes, digamos que desejava que um arquivo de configuração na minha máquina de desenvolvimento sempre apontasse para a porta 3333 do host local em vez do servidor de produção, então eu usaria a extensão Mercurial Queues, que é fornecida com o Mercurial e o TortoiseHg .

Não acredito que mudanças não confirmadas sejam intrinsecamente uma coisa ruim. Você se refere a uma "incapacidade de se fundir com eles" - se você tiver uma alteração não confirmada em algum arquivo e extrair e atualizar uma alteração nesse arquivo, o Mercurial iniciará o processo de mesclagem como se você o tivesse comprometido e depois solicitou uma mesclagem. Você quis dizer algo diferente?

Portanto, para alterações locais que você ainda não deseja compartilhar com outros desenvolvedores, você tem duas abordagens. O primeiro é manter as alterações na sua cópia de trabalho, mas não forçá-las, e a outra é colocá-las de lado, fora da cópia de trabalho. A sua escolha depende se você deseja ter essas alterações disponíveis enquanto trabalha.

Se você os mantiver na cópia de trabalho, as alterações recebidas funcionarão bem, portanto, você só precisa evitar a criação de alterações de saída, o que significa evitar comprometê-las. Se os arquivos são novos, é fácil - apenas não hg addos faça. Se eles já estiverem rastreados, você poderá excluí-los especificamente de confirmações com hg commit --exclude foo.txt. Se você tiver um grande número de arquivos a serem excluídos ou os excluirá de muitas confirmações (por exemplo, para uma mudança permanente em um arquivo de configuração local), observe a extensão de exclusão .

Se você estiver preparado para afastar as alterações, terá outro conjunto de opções. A coisa mais simples é simplesmente usar hg diffnos arquivos para produzir um patch que os descreva, que você mantém em algum lugar seguro, e hg patch --no-commitreaplicar esse patch quando quiser as alterações de volta. Você pode tornar isso mais suave instalando a extensão de prateleira , a extensão do sótão ou algum outro parente. Você também pode usar a extensão de filas , mas está usando uma marreta para quebrar uma noz. Você pode apenas confirmar as alterações, depois atualizar de volta para o pai e confirmar outro trabalho lá, deixando as alterações em um ramo anônimo atarracado - hg commit -m 'temporary branch' && hg up $(hg log -r 'parents(.)' --template '{node}')(embora possa ser mais fácil fazer isso manualmente!). Você teria que tomar cuidado para não enviar esse conjunto de alterações, no entanto.

Duas abordagens básicas são usadas para separar fluxos de desenvolvimento.

• Ramos nomeados. A idéia é que você trabalhe em seu próprio ramo, o nmichaels_branch_of_awesome. Dessa forma, você pode confirmar suas alterações sem prejudicar o trabalho de outras pessoas. Depois, você se une a outras pessoas quando precisa do trabalho delas e, quando chega a hora do recurso, você passa para o ramo mais estável da integração. Eu sou a favor de ramos nomeados.

• Clone anônimo. Isso cria um repositório separado para sua sandbox. Aqui você brinca até conseguir o que deseja e, em seguida, (provavelmente) faz um patch do MQ para seus commits e avança para onde você começou. Não gosto muito dessa abordagem, pois requer gerenciamento de diretório e potencialmente trabalho de MQ, o que pode ser complicado. E com alguns repos, eles podem começar a ficar um pouco maiores para isso. Dito isto, isso parece ser preferido pelos desenvolvedores do Kiln.