Organização do repositório

Question

Quando comecei a usar sistemas de controle de revisão como CVS e SVN, eu realmente não entendi os conceitos de "tronco", ramificação, fusão e marcação.Agora estou começando a entender esses conceitos e realmente entender a importância e o poder por trás deles.

Então, estou começando a fazer isso direito.Ou então eu acho...Isto é o que eu entendi até agora:A versão mais recente/estável do seu código deve ficar em /trunk/ enquanto as versões beta ou versões mais recentes ficam dentro do diretório /branches/ como diretórios diferentes para cada versão beta e, em seguida, mescladas no tronco quando você lançar.

Será esta uma visão demasiado simplista das coisas?Quais layouts de repositório vocês recomendam?Se fizer diferença, estou usando o Subversion.

Answer 1

Veja estas duas perguntas no SO para obter mais informações:

• O que branch, tag e trunk realmente significam?
• Pergunta de subversão

Answer 2

O que faço e normalmente vejo como padrão é:

O tronco deve conter sua linha principal de desenvolvimento, sua versão instável.Você deve criar ramificações de lançamento para seus lançamentos.

Algo como:

/Trunk (aqui você está desenvolvendo versão 2.0) /branches/rb-1.0 (esta é a filial de liberação para 1.0) /branches/rb-1.5

Ao encontrar um bug no 1.5, você o corrige no branch RB e depois faz o merge no trunk.

Eu também recomendo este livro.

Answer 3

Eric tem uma excelente série de artigos sobre o uso do controle de origem e práticas recomendadas organizacionais.O Capítulo 7 trata das filiais (e sim, ele recomenda os diretórios /trunk/ e /branches/ que você sugere).

Answer 4

Eu uso o Perforce há muito tempo e, portanto, meus comentários podem ser um pouco centrados no Perforce, mas os princípios básicos se aplicam a qualquer software SCM que tenha ramificações decentes.Acredito fortemente no uso de práticas de desenvolvimento ramificadas.Eu tenho um "principal" (também conhecido como "linha principal") que representa a base de código de agora até a eternidade.O objetivo é que isso seja, na maioria das vezes, estável e, se a situação for difícil, você poderá cortar uma versão a qualquer momento que reflita a funcionalidade atual do sistema.Aqueles vendedores chatos ficam perguntando....

Os desenvolvimentos acontecem em ramificações que são ramificadas do MAIN (normalmente - ocasionalmente você pode querer ramificar a partir de uma ramificação de desenvolvimento existente).Integre do MAIN às suas ramificações de desenvolvimento sempre que possível, para evitar que as coisas diverjam demais - ou você pode simplesmente fazer um orçamento para um período de integração maior posteriormente.Apenas integre seu novo recurso ao MAIN quando tiver certeza de que ele será lançado em um próximo lançamento.

Por fim, você tem a linha RELEASE, que tem a opção de diferentes ramificações para diferentes lançamentos.Existem algumas opções dependendo dos recursos de rotulagem do seu software SCM e da probabilidade de as revisões principais/secundárias serem diferentes.Portanto, você pode optar, por exemplo, por um branch de lançamento para cada lançamento pontual ou apenas para o número de rotação principal.Sua milhagem pode variar.

Geralmente, ramifique de MAIN para liberar o mais tarde possível.Correções de bugs e alterações de última hora podem ir direto para RELEASE para integração posterior com MAIN, ou para MAIN para backup imediato de integração.Não existe uma regra rígida e rápida – faça o que funciona melhor.Se, no entanto, você tiver alterações que possam ser submetidas à MAIN (por exemplo,de um branch de desenvolvimento ou "pequenos ajustes" feitos por alguém no MAIN), então faça o primeiro.Depende de como sua equipe trabalha, quais são seus ciclos de lançamento, etc.

Por exemplo.Eu teria algo assim:

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main.
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work.
//MYPROJECT/RELEASE/1.0/...
//MYPROJECT/RELEASE/2.0/...

Um projeto não trivial provavelmente terá várias filiais DEV ativas ao mesmo tempo.Quando um desenvolvimento tiver sido integrado ao MAIN para que agora faça parte do projeto principal, elimine o antigo branch DEV assim que puder.Muitos engenheiros tratarão uma filial DEV como seu próprio espaço pessoal e a reutilizarão para diferentes recursos ao longo do tempo.Desencoraje isso.

Se, após o lançamento, você precisar corrigir um bug, faça isso no branch de lançamento correspondente.Se o bug foi corrigido anteriormente no MAIN, então integre, a menos que o código tenha mudado muito no MAIN, a correção é diferente.

O que realmente diferencia as linhas de código são as políticas que você usa para gerenciá-las.Por exemplo, quais testes são executados, quem analisa antes/pós uma mudança, que ação acontece se uma compilação falhar.Normalmente, as políticas - e, portanto, as despesas gerais - são mais fortes nos ramos de lançamento e mais fracas no DEV.Há um artigo aqui que passa por alguns cenários e links para outras coisas úteis.

Por fim, recomendo usar uma estrutura simples para começar e introduzir apenas estruturas extras de desenvolvimento e lançamento conforme necessário.

Espero que isso ajude e não seja muito óbvio.