Use subversão sem tronco

Question

Recentemente, minha equipe decidiu não usar o ramo "tronco", típico da maioria dos layouts de repositório de subversão. Descobrimos que, a qualquer momento, sempre havia um ramo específico que funcionava no papel tradicional que o tronco mantinha em outros repositórios. Ou seja, sempre temos um ramo mais alto que representa o próximo lançamento em que estamos trabalhando. Portanto, uma fusão para o tronco é simplesmente supérflua, por isso nos livramos do porta -malas.

Alguém mais faz isso?

Se sim, você notou algum prós/contras?

Mesmo que sua equipe não faça isso, alguém pensa nesse layout?

Answer 1

Você está falando sobre o Modelo promocional - O artigo da Perforce destaca os problemas com ele - comunicando as funções em mudança das linhas de código e o trabalho em movimento entre as filiais.

Uma expansão nos meus pontos de vista dos problemas listados:

1) Mudança de política de linhas de código:

Toda linha de código tem uma política, seja escrita e formalizada ou totalmente implícita na cabeça de um desenvolvedor. Define por exemplo:

• quem tem permissão para se comprometer com a linha de código
• Quanta teste é necessário (por exemplo, os testes de unidade precisam passar, testes de regressão, teste completo do sistema)
• Quantas pessoas têm para codificar as mudanças de revisão
• Que tipo de alterações são permitidas

Com a abordagem do porta -malas, as políticas permanecem fixas, por isso são mais fáceis de anotar, o que as torna mais fáceis de se comunicar (mais importante em uma equipe maior).

por exemplo, tronco:

• Qualquer desenvolvedor pode se comprometer
• qualquer mudança
• Os testes de unidade devem passar
• Revisão do código após comprometer

Branch de versão:

• Somente desenvolvedor de manutenção
• apenas correção de bug
• Teste de unidade + testes de regressão
• Revisão do código por 2 outros desenvolvedores antes de comprometer

Branch de tag:

• Sem compromissos depois da criação

Filial Privada do desenvolvedor:

• Somente o desenvolvedor faz o check -in
• Qualquer mudança
• Os testes só precisavam antes de se fundir para o tronco
• Revisão do código antes de se fundir para o tronco

Se você possui o modelo de promoção, possui uma política enquanto estiver no desenvolvimento principal, deve dizer a todos quando você muda a política enquanto se prepara para o lançamento, outra política (para a linha do código) assim que a linha for liberada.

O modelo de promoção é fácil de entrar, ele mapeia diretamente para a maneira de trabalhar sem fonte. Mas dói quando você começa a obter equipes grandes.

Se você olhar para o desenvolvimento do kernel Linux, poderá ver a tensão entre o modelo promocional e o modelo de tronco: a árvore de Linus 'é promocional - ela passa por ciclos entre a janela de mesclagem e o período de estabilização RC/. Mas o Linux -Next e -mm surgiram para dar uma linha mais como um porta -malas.

SCM/VCs distribuídos são um pouco diferentes de qualquer maneira, as políticas não precisam ser distribuídas a todos os desenvolvedores, porque cada desenvolvimento tem suas próprias árvores e puxa mudanças quando deseja.

Os projetos de código aberto sofrem com o problema de que eles não podem forçar as pessoas a fazer o trabalho de dudge de estabilizar um lançamento, depois de se ramificar do porta-malas. Portanto, o modelo de promoção é mais importante como uma maneira de forçar os esforços de estabilização, em vez de apenas trabalhar nos recursos.

2) Trabalho em movimento:

Um desenvolvedor pode estar trabalhando em um recurso quando a política para a linha em que ele está trabalhando apenas em alterações em fixos de bug, ele agora precisa mudar sua cópia de trabalho para uma linha de código diferente. Isso pode ser de fácil a extremamente difícil, dependendo do sistema SCM em uso. Esse problema não acontece se o desenvolvedor estiver trabalhando no porta -malas, pois seu trabalho sempre vai para o Trunk. Se o desenvolvedor estiver em uma filial privada ou de recursos, seu trabalho só afetará o tronco (e o lançamento).

Se um recurso já estiver fazendo o check -in, mas atrasar -se da versão em que está atualmente, você deve descobrir como removê -lo. Esse problema ainda existe com o modelo do tronco, mas pode ser um pouco mais fácil de resolver - escolhendo coisas do Trunk para o lançamento. É aqui que as filiais dos recursos ajudam - mas eles têm um custo de integração.

Answer 2

Meu problema com o artigo Perforce é que ele rejeita o modelo promocional sem mencionar a principal vantagem, reduzindo a fusão. De fato, o artigo afirma erroneamente que o "modelo principal da linha" impõe "nenhuma sobrecarga administrativa adicional", uma reivindicação ridícula. O modelo "sempre se fundir para o porta -malas" significa exatamente isso - você tem a sobrecarga de todos que precisam se fundir. Esta é uma sobrecarga inútil se você tiver a seguinte situação (que temos):

a) Uma pequena equipe (5 a 7 desenvolvedores), tudo a uma distância de gritos um do outro. A comunicação não é um problema quando precisamos fazer um ramo

e

b) Uma base de código em que há realmente apenas duas filiais principais - uma filial de produção e "a próxima coisa no desenvolvimento". Talvez uma vez na lua azul tenhamos 3.

Eu acho que meu ponto é - é uma coisa situacional. Dizer que o "modelo promocional tem problemas" é como dizer "nunca use um ou/m". Depende do seu ambiente.

Answer 3

A subversão permite ambas as abordagens. O porta -malas não é uma necessidade, mas uma convenção. Se você tiver, algumas ferramentas funcionam com mais facilidade (por exemplo, ferramentas de migração para o GIT). Se você não o tiver, deve fazer algumas coisas manualmente, mas não consigo pensar em algo que notará durante o seu trabalho diário.

Answer 4

Recentemente, comecei a trabalhar em um projeto que está em um repositório de subversão. Quem criou o repositório não seguiu nenhum layout em particular - eles simplesmente enfiaram tudo na raiz do repositório (sem tronco/, sem ramificações/, e certamente sem tags/). Eu queria criar uma filial para trabalhar e algumas tags para outras coisas, mas percebi o quão difícil é fazer isso em um repositório de subversão que não segue um layout adequado.

Answer 5

Nós fazemos - mais ou menos. Não usamos um porta -malas, mas criamos uma nova filial para cada lançamento de nossos projetos. Esta ramificação 'marcada' é então o tronco para cada versão, e Backport Bugfixes, mesclando alterações nas versões mais antigas.

Funciona bem para nós, mas temos muitos subprojetos em nosso projeto.

Answer 6

IME, em alguns ambientes, o porta -malas é um bom lugar para trocar as correções e as alterações de/de. Isto é, todo mundo mescla suas correções para o porta -malas e todo mundo mescla a partir de o porta malas. Descobrimos isso muito útil em um ambiente em que muito código foi compartilhado entre muitos projetos independentes e onde todos esses projetos contribuíram para o código compartilhado.

Seu ambiente pode diferir, no entanto.