Usando o Subversion com o Modelo Promocional

Question

no momento usamos o Subversion para controle de origem, mas todo o trabalho de fusão de nossas versões é feito manualmente.Lançamos várias vezes por ano, então crie um branch para cada lançamento.Todo o trabalho das filiais anteriores deve ser transferido para as posteriores.O trabalho em filiais posteriores não deve ser feito em filiais anteriores (isso está em nossos contratos).Acredito que isso é conhecido como Modelo Promocional.

Acho que o diagrama a seguir ilustra melhor nosso fluxo de trabalho desejado, com ramificações sendo criadas sempre que o trabalho começa em uma nova versão e mudanças fluindo das ramificações anteriores para as posteriores.

|
1
|
|\
| \ 
| 2 
3 | 
|\| 
4 |
| |\
5 | \
| 6 |
| | 7
|\|\|
| |\|
8 9 |\
| | | \
|\| | 10
x |\| |
  | |\|
  | | | 

a b c d

• Este modelo funcionaria perfeitamente usando o Subversion apesar da falta de um tronco significativo?
• O rastreamento automatizado de mesclagem funcionaria para as atualizações das filiais anteriores para as posteriores?
• Seria correto fechar/excluir/ignorar um branch (neste exemplo, liberar branch 'a') sem reintegrar?
• Seria correto criar ramificações de recursos a partir de cada ramificação de lançamento e o rastreamento de mesclagem funcionaria para elas?(Eles seguiriam o modelo recomendado de criação/mesclagem/reintegração.)

Editar - adicione mais informações.

A razão pela qual o modelo tradicional de Tronco Instável pode não ser adequado é ilustrada pelo diagrama a seguir.Os recursos de cada versão não são necessariamente concluídos na ordem de lançamento (alguns clientes podem demorar para confirmar os requisitos).Queremos propagar as alterações dos ramos anteriores para os posteriores o mais rápido possível.

    a
    |
    1
    |
   b|\ a
    | \ 
    |  2
    3  |
    |  |
    4  |
  b/|c |
  / 5  |
 |  |  6
 7  |  |
 b  c  a

Neste caso, queremos o recurso 2 (concluído no branch a) no branch b, mas como esta é uma fusão filho-pai e, portanto, não suportada pelo Subversion, terá que ser feito manualmente.Da mesma forma, o recurso 6 teria que ser mesclado manualmente duas vezes.Prevejo que este seja um processo relativamente lento e sujeito a erros em comparação com mesclagens rastreadas automaticamente.

Answer 1

Se entendi sua situação, não há nada em seus requisitos que torne as coisas tão complexas quanto você parece.Você também está colocando muita ênfase nos méritos do automático vs.fusão manual (mais sobre isso mais tarde).As ramificações do CVS teriam sido outra questão, mas não com a maneira como o SVN lida com as "filiais" (ou seja, não o faz).

Você poderia ter uma linha de desenvolvimento primária (instável ou estável) e criar ramificações para cada cliente ou versão (ou ambos).À medida que os recursos são validados, eles são mesclados de volta à linha principal para que ramificações posteriores possam incluir essas alterações ou você sempre mescla unidirecionalmente a partir de uma ramificação pai.Nada exige que você feche a ramificação e a mesclagem não é menos automatizada do que seria para dar suporte ao seu primeiro diagrama (caótico), já que você tem várias linhas de desenvolvimento simultâneas.

O requisito de mesclar apenas para frente parece que você só precisa mesclar revisões de subconjunto da linha principal, revisões após uma determinada revisão de ramificação.Fazer suas mesclagens dessa maneira permitirá que você mescle as alterações de ramificações arbitrárias de volta à linha principal com a frequência que desejar (conforme confirmadas com seus clientes) e poderá ser aplicada com a confiança de que apenas as alterações validadas serão aplicadas.Você pode configurar a mesclagem automática para rastrear a revisão da cópia (consulte --stop-on-copy e mesclagens baseadas em intervalo).As ramificações de liberação então selecionam conjuntos de alterações confirmadas que ocorreram de um determinado ponto em diante.

O SVN não "rastreia mesclagens" mais do que suporta ramificações (o que não acontece, são apenas cópias leves).Você informa (ou o svnmerge informa) os intervalos para mesclar e ele aplica essas alterações.Você pode obter o efeito que é contratualmente obrigado a apoiar, independentemente.

Para responder às suas perguntas:

• Não creio que o modelo que você propôs seja muito eficaz.Pelo contrário, aumentou o potencial para o caos no rastreamento de recursos, pois pode ser necessário verificar as ramificações em busca de alterações e mesclar várias vezes.Além disso, sem dúvida confundirá os desenvolvedores familiarizados com o SVN e as estruturas organizacionais mais tradicionais do SVN.

• Claro.Isso também deve ser bastante independente da estrutura que você escolheu.Você precisará/desejará acompanhar seus pontos de revisão de qualquer maneira (talvez por meio de alguns scripts simples, na pior das hipóteses).

• Claro.As filiais efetivamente não têm nenhum custo em SVN no lado do servidor.O lado do cliente tem um custo se você fizer verificações raiz inteiras, mas isso geralmente é uma coisa estúpida de se fazer de qualquer maneira.Da mesma forma, não há problema em ignorar/excluir uma ramificação.É apenas mais uma mudança na hierarquia de revisão global como qualquer outra cópia/exclusão/renomeação/etc.

• Isso deveria funcionar independentemente da estrutura organizacional “ramificada” implementada.Parece que talvez haja um pequeno mal-entendido sobre o que significa ser uma "ramificação" no SVN.Você deve ser capaz de configurar o que deseja e executar mesclagens "manuais" com relativa facilidade e, posteriormente, configurar a mesclagem automática após algumas atualizações do cliente para que possa entender um pouco melhor as etapas de mesclagem.

Saúde!

Answer 2

Você diz:

Todos os trabalhos de ramos anteriores devem transformá -lo em posterior. O trabalho em filiais posteriores não deve transformá -lo em anteriores (isso está em nossos contratos)

Aqui, se substituirmos as filiais por lançamentos (duvido que seus clientes saibam ou se importem com "ramos"), obtemos:

Todos os trabalhos de lançamentos anteriores devem transformá -lo em posterior. Trabalho em lançamentos posteriores não deve entrar em contato com os anteriores (isso está em nossos contratos)

Não vejo nada nesse requisito para sugerir o esquema de ramificação muito complexo que você está propondo - você pode fazer isso com o clássico estilo de desenvolvimento "tronco instável". Ou você tem mais requisitos sobre os quais não nos contou ou está engenharia demais.