Como atualizar corretamente uma filial de recursos do Trunk?

StackOverflow https://stackoverflow.com/questions/2146426

  •  23-09-2019
  •  | 
  •  

Pergunta

SVN Book diz:

...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

Acho essa abordagem muito pouco prática em grandes desenvolvimentos, por várias razões, principalmente relacionadas à etapa de reintegração.

  1. De Svn v1.5, a fusão é feita Rev-By-Rev. A escolha das áreas a serem mescladas nos levaria a resolver os conflitos do ramo do porta-malas duas vezes (um ao mesclar revisões do tronco para o FB e mais uma vez ao se fundir).
  2. Tamanho do repositório: as alterações do tronco podem ser significativas para uma base de código grande e copiar os arquivos de diferenças (diferentemente da cópia do SVN) do tronco em outros lugares pode ser uma sobrecarga significativa.

Em vez disso, fazemos o que chamamos de "re-ramo". Nesse caso, quando é necessária uma parte significativa de mudanças no tronco, uma nova ramificação de recursos é aberta do tronco atual e a mesclagem é sempre para baixo (ramificações de recursos -> tronco -> ramos estáveis). Isso não acompanha as diretrizes e desenvolvedores do livro SVN como dor extra.

Como você lida com essa situação?

Foi útil?

Solução 2

Depois da pesquisa:

Após muitas sessões de brainstorming no VisionMap, as discussões da F2F, incluindo o Artyom, abrindo uma caixa de livros SVN, etc. - parece que isso não é possível fazer. Uma filial de recursos não é totalmente como cópia de trabalho. A única maneira de funcionamento de atualizá -lo é recriar uma nova filial, conforme descrito acima.

Outras dicas

De Svn v1.5, a fusão é feita Rev-By-Rev. Escolher as áreas a serem mescladas nos levaria a resolver os conflitos do galho do porta-malas duas vezes (um ao mesclar revisões do tronco para o FB e mais uma vez ao se fundir de volta)

Então você está fazendo algo errado!

Vamos ver:

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

Geralmente, se você deseja alterações feitas em 11-20, as melhores práticas é mesclar 1-20 para o FB e obter tudo lá.

Então, quando o FB terminar, mescla 20-30 e depois cópia de FB para tronco (sem fusão!).

Se você decidir mesclar apenas R11: 20, OK, no final, você precisará mesclar R1: 10 e R20: 30 e então cópia de fb para tronco.

Não há como fundir mudanças duas vezes!

Presumo que você provavelmente faça seguidores:

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

Você não pode fazer isso porque se fundiria 11:20 duas vezes. Você sempre deve mesclar o código apenas em uma direção.

Maneira correta:

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

Editar

Portanto, as etapas corretas são:

  1. Criar ramo de recursos (FB) do tronco (copiar tronco para ramo de recursos com svn-copy)

    FB_0=trunk_0

  2. Trabalhe no FB.

    FB_1=FB_0 + change_a

  3. Mesclar todas as mudanças futuras do tronco para o FB.

    trunk_1=trunk_0 + tr_change_a;
FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a

  4. Trabalhe no FB

    FB_3 = FB_2 + change_b

  5. Mesclar tudo o próximo alterações não ridicularizadas Do porta -malas a fb.

    trunk_2=trunk_1 + tr_change_n;
FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b

  6. Neste ponto, temos um ramo de recursos que consiste em tudo novos recursos etudo mudanças no tronco. Então, apenas copiamos a diferença entre duas ramificações.

    trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b

    Agora, o FB excluído como o Trunk tem todas as alterações de que precisamos.

    O último passo é executado por:

    svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
svn ci

    Ou, na linguagem comum, pegue a diferença entre o tronco e o ramo e os coloque no tronco, tornando -os equivalentes.

Este padrão é descrito em http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature

Agora, se isso não funcionar para você, não entendo a pergunta.

Edit2: Para SVN-1.5

Ao trabalhar com SVN-1.5, você pode mesclar muito mais simples:

Quando você trabalha na filial de recursos, basta mesclar mudanças de tronco de tempos em tempos:

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

Ele alinhará seu FB com todas as mudanças no tronco. No final do FB, você executa este procedimento mais uma vez para garantir que tudo esteja atualizado. Você vai para o tronco e correr

$ svn merge --reintegrate /path/to/fb
$ svn ci

No último, não deve haver conflitos se você estiver trabalhando como mostrado.

Somos uma empresa pequena, então não sei se nossa solução se aplicará à sua situação. O que fazemos é uma rev-by-rev que se fundindo do porta-malas para o ramo estável. Podemos fazer isso de duas maneiras diferentes: - Realmente precisamos de correção, mesclamos logo após nos comprometermos com o Trunk - correção/mudança perigosa. Esperamos alguns dias até que a mudança seja prova no tronco e depois nos fundimos

Com essa fusão contínua, evitamos toneladas de conflitos.

Meus 2 centavos.

Infelizmente, tudo mencionado pode ser pensado como hacks. A atualização do Trunk em uma filial pode levar a problemas muito sérios ao trazê -lo de volta ao porta -malas e abre a possibilidade de o pior de todos os conflitos, conflitos de árvores. Isso ocorre porque os diretórios não são tratados como cidadãos de primeira classe. A melhor abordagem é usar o Mercurial com a extensão SVN como seu cliente SVN padrão. Ele permite que você continue usando o SVN enquanto obtém o poder do manuseio de pastas da Mercurial.

Em seguida, no lado WWorkStation, você pode usar várias abordagens que fornecem uma variedade de recursos para se adequar a muitas situações sobre o único SVN. Você pode usar patches regulares, filas de patch, atualizando a partir de uma cópia local do Trunk sem afetar o porta -malas compartilhadas e várias outras abordagens.

Essa abordagem funciona em torno de todos os lados Downn da SVN. Eu tinha mudado para essa abordagem por causa de circunstâncias semelhantes. Mesmo se você não usar essa abordagem imediatamente, deve pelo menos experimentar o mais rápido possível.

Eu acho que tenho que pegar os cudgels para @artyom aqui. Eu também acho que se você tiver que

Resolva os conflitos de trombas duas vezes

algo está errado. E acho que o argumento/solução @artyoms é bastante sólido.

Eu acredito fb para trunk você não usa svn copy mas svn merge (ou svn merge --reintegrate). Este pode ser o motivo pelo qual você não encontra o padrão de "cópia-merge" em Padrões de ramificação comuns.

Enquanto estou lutando para entender o que você está fazendo até agora, não tenho certeza do que mais dizer.

Aqui está o que eu ouço:

Em vez disso, fazemos o que chamamos de "re-ramo". Nesse caso, quando é necessária um pedaço significativo de mudanças no tronco, uma nova filial de recursos é aberta do tronco atual, ...

Agora você tem um novo ramo (vamos chamá -lo de B2) que é equivalente ao porta -malas, certo? E Onde O "pedaço significativo das mudanças no tronco é necessário"? Eu presumo no FB?

... e a mesclagem é sempre para baixo (ramificações de características -> tronco -> ramos estáveis).

Mas, como você acabou de criar B2 do tronco, não há nada para se fundir no porta -malas, não? E você não está mesclando alterações de B2 para FB (pois isso seria o mesmo que a fusão do tronco para o FB ...). Então, como os "pedaços significativos de mudanças" entram no FB? E uma vez que eles estão lá, por que você deseja mesclá -los de volta ao Trunk (já que é daí que eles vieram em primeiro lugar)?

Na verdade, os seguintes links A seção chamada “rastreamento se fundem manualmente” e/ou A seção chamada “Mesclagem de um ramo inteiro para outro" Fornecido na documentação SVN 1.4 (eu sei, você não usa o SVN 1.4, mas acredito que se aplica de qualquer maneira) em Padrões de ramificação comuns Pode ajudar a esclarecer algumas coisas. Esses links estão "ausentes" na documentação 1.5 (provavelmente por causa do novo --reintegrate opção em merge).

Você realmente parece estar fundindo as mesmas mudanças duas vezes e eu realmente acho que você não deveria (precisar) fazer isso.

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