Por que ramificar e mesclar é mais fácil no Mercurial do que no Subversion?

Question

Lidar com múltiplas mesclagens em ramificações no Subversion ou CVS é ​​apenas uma daquelas coisas que precisam ser experimentadas.É extremamente mais fácil acompanhar ramificações e mesclagens no Mercurial (e provavelmente em qualquer outro sistema distribuído), mas não sei por quê.Alguém mais sabe?

Minha dúvida decorre do fato de que com o Mercurial você pode adotar uma prática de trabalho semelhante à do repositório central do Subversions/CVSs e tudo funcionará perfeitamente.Você pode fazer várias mesclagens no mesmo branch e não precisará de intermináveis ​​pedaços de papel com números de commit e nomes de tags.

Eu sei que a versão mais recente do Subversion tem a capacidade de rastrear mesclagens em ramificações para que você não tenha o mesmo grau de aborrecimento, mas foi um desenvolvimento enorme e importante da parte deles e ainda não faz tudo o que a equipe de desenvolvimento faria gostaria de fazer.

Deve haver uma diferença fundamental na forma como tudo funciona.

Answer 1

No Subversion (e no CVS), o repositório é o primeiro e mais importante.Em Git e Mercurial, não existe realmente o conceito de repositório da mesma maneira;aqui as mudanças são o tema central.

+1

O incômodo no CVS/SVN vem do fato de que esses sistemas não nãolembre-se da paternidade das mudanças.No Git e Mercurial, não apenas um compromisso pode ter vários filhos, mas também pode ter vários pais!

Isso pode ser facilmente observado usando uma das ferramentas gráficas, gitk ou hg view.No exemplo seguinte, o ramo nº 2 foi bifurcado no número 1 no Commit A e, desde então, foi mesclado uma vez (em M, fundido com o Commit B):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

Observe como A e B têm dois filhos, enquanto M tem dois pais.Esses relacionamentos são gravado no repositório.Digamos que o mantenedor da filial nº 2 agora queira mesclar as últimas alterações da filial nº 1, eles podem emitir um comando como:

$ git merge branch-1

e a ferramenta saberá automaticamente que o base é b-porque foi registrado em Commit M, um ancestral da ponta do #2-e que precisa mesclar o que quer que aconteça entre B e C.O CVS não registra essas informações, nem o SVN antes da versão 1.5.Nesses sistemas, o gráfico seria:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

onde M é apenas um comando gigantesco "esmagado" de tudo o que aconteceu entre A e B, aplicado no topo de M.Observe que após a escritura ser feita, há Nenhum rastro esquerdo (exceto potencialmente em comentários legíveis pelo homem) de onde M se originou, nem de quantos Os compromissos foram colapsados-criando um histórico muito mais impenetrável.

Pior ainda, realizar uma segunda mesclagem se torna um pesadelo:é preciso descobrir qual era a base de mesclagem no momento da primeira mesclagem (e um tem para saberque houve uma mesclagem em primeiro lugar!), depois apresente essas informações à ferramenta para que ela não tente repetir a..b em cima de M.Tudo isso é difícil o suficiente ao trabalhar em estreita colaboração, mas é simplesmente impossível em um ambiente distribuído.

Um problema (relacionado) é que não há como responder à pergunta:"X contém B?" onde B é uma correção de bug potencialmente importante.Então, por que não apenas registrar essa informação no compromisso, pois é conhecido na hora da mesclagem!

P.-S.- Não tenho experiência com as habilidades de gravação de mesclagem SVN 1.5+, mas o fluxo de trabalho parece ser muito mais artificial do que nos sistemas distribuídos.Se esse é realmente o caso, provavelmente é porque-como mencionado no comentário acima-o foco é colocado na organização do repositório e não nas próprias mudanças.

Answer 2

Porque o Subversion (pelo menos versão 1.4 e inferior) não rastreia o que foi mesclado.Para o Subversion, a fusão é basicamente igual a qualquer commit, enquanto em outro controle de versão como o Git, o que foi mesclado é lembrado.

Answer 3

Intocado por qualquer uma das respostas já fornecidas, o Hg ofereceu recursos de mesclagem superiores porque usa mais informações ao mesclar alterações (hginit.com):

Por exemplo, se eu mudar uma função um pouco e depois movê -la para outro lugar, a subversão não se lembra realmente dessas etapas; portanto, quando chega a hora de se fundir, pode pensar que uma nova função apareceu do Blue .Considerando que o Mercurial se lembrará dessas coisas separadamente:A função foi alterada, a função movida, o que significa que, se você também alterar essa função, é muito mais provável que o Mercurial mescie com sucesso nossas alterações.

É claro que lembrar o que foi mesclado pela última vez (o ponto abordado pela maioria das respostas fornecidas aqui) também é uma grande vitória.

Ambas as melhorias, no entanto, são questionáveis, uma vez que o Subversion 1.5+ armazena informações adicionais de mesclagem na forma de propriedades do Subversion:Com essas informações disponíveis, não há nenhuma razão óbvia para que o merge do Subversion não possa implementar o merge com tanto sucesso quanto o Hg ou o Git.Não sei se isso acontece, mas certamente parece que os desenvolvedores do Subversion estão a caminho de contornar esse problema.

Answer 4

Suponho que isso possa ocorrer parcialmente porque o Subversion tem a ideia de um servidor central junto com um cronograma absoluto de revisões.O Mercurial é verdadeiramente distribuído e não tem referência a uma linha de tempo absoluta.Isso permite que os projetos Mercurial formem hierarquias mais complicadas de ramificações para adicionar recursos e ciclos de teste por subprojeto, no entanto, as equipes agora precisam se manter muito mais ativamente no topo das fusões para se manterem atualizadas, já que não podem simplesmente clicar em atualizar e pronto. .

Answer 5

No Subversion (e no CVS), o repositório é o primeiro e mais importante.No git e no mercurial não existe realmente o conceito de repositório da mesma maneira;aqui mudanças são o tema central.

Também não pensei muito sobre como você implementaria, mas minha impressão (com base na experiência amarga e em muita leitura) é que essa diferença é o que torna a fusão e a ramificação muito mais fáceis em sistemas não baseados em repositórios.

Answer 6

Eu só tenho experiência com o Subversion, mas posso dizer que a tela de mesclagem no TortoiseSVN é terrivelmente complicada.Felizmente, eles incluem um botão de simulação para que você possa ver se está fazendo certo.A complicação está na configuração do que você deseja mesclar para onde.Depois de configurar a mesclagem, a mesclagem geralmente funciona bem.Então você precisa resolver todo e qualquer conflito e então enviar sua cópia de trabalho mesclada para o repositório.

Se o Mercurial puder facilitar a configuração da mesclagem, posso dizer que isso tornaria a mesclagem 100% mais fácil do que o Subversion.