Qual controle de revisão tem o melhor mecanismo de mesclagem? [fechadas]

8

Quando se trata de mesclar, cada versão de controle possui seu mecanismo para fazer isso. Conflitos são inevitáveis, mas a questão é - qual controle de revisão tem melhor IA para evitar conflitos.

É possível medir isso?

Mais especificamente, estamos pensando em mudar para o GIT, porque ele tem um hype e boato legais que lidam melhor com os conflitos ...

Qualquer comentário é apreciado ...

version-control

— confiq
fonte

10

Por fim, nenhum VCS pode lidar bem com "fusões fechadas" sem fazer algo de outro mundo. Se uma pessoa adiciona lógica em uma rotina que segue uma direção, e outra pessoa faz algo semelhante - mas completamente diferente -, os seres humanos precisam se envolver.

— 22411 Peter Rowell

1

Em teoria, os algoritmos de mesclagem podem ser muito bons se eles realmente compilarem o código fonte. Parece meio que lá fora, mas provavelmente é apenas uma questão de tempo.

— Karl Bielefeldt

1

@Karl: eh? compile qual código fonte - se eu alterar uma linha para dizer x = 1 e meu colega alterar a mesma linha para dizer x = 2, como o compilador descobrirá qual deles está 'correto', considerando o restante dos commits mesclados.

— Gbjbaanb

1

@gbj, você nunca poderá evitar completamente a intervenção humana, como o seu exemplo prova. No entanto, compilar o código-fonte pode mesclar com mais facilidade coisas como renomeação de variáveis ou métodos, ou fazer uma alteração de duas maneiras funcionalmente idênticas, mas textualmente diferentes.

— Karl Bielefeldt

O teste não pôde resolver alguns dos fatores "humanos". Os humanos sabem o que estão tentando produzir, para que o conflito possa ser resolvido através da compilação e execução do teste. Os testes de unidade devem estar em um nível suficientemente pequeno para que algumas atualizações do mesmo método sejam viáveis em algumas passagens, se o teste for bem-sucedido nos dois sentidos em que os seres humanos precisam se envolver, se o sistema de mesclagem determinar que há muitas variações que a compilação não é tratável, seres humanos precisarão estar envolvidos.

— Quaternion 29/07

21

Eu não acho que essa seja a pergunta certa a ser feita.

O problema é que existem muitos casos de esquina, e algoritmos "inteligentes" para mesclagem podem enganar-se a pensar que eles fizeram a fusão corretamente quando, na verdade, eles destruíram completamente seu código. Se você tiver sorte, uma mesclagem tão ruim causa uma falha no tempo de compilação. Se você não tiver sorte, pode introduzir um bug sutil que leva séculos para ser rastreado.

O Git usa um algoritmo de mesclagem bastante simples, levanta as mãos e pede ajuda se não puder fazer a mesclagem. Na minha opinião, é exatamente isso que você deseja que seu sistema de controle de versão faça. A quantidade de sofrimento que você é poupado por isso vale bem o tempo que leva para corrigir manualmente os conflitos. (Além disso, se houver conflitos em uma mesclagem, o git lista os arquivos em conflito em sua mensagem de confirmação gerada automaticamente para você - isso é uma coisa muito útil para encontrar erros quando você estiver digitando seu histórico de códigos.)

— ebneter
fonte

6

Foi dito que o melhor algoritmo é a álgebra de patch de Darcs . Codeville também possui um algoritmo interessante em desenvolvimento.
No entanto, por todos os motivos práticos, qualquer ferramenta que use mesclagem de três vias o fará. Isso inclui git (com variantes), mercurial, bazar e muitas ferramentas externas (exceções notáveis: opendiff e caleidoscópio no Mac); portanto, com boa probabilidade, você já está usando as melhores opções; como observou o Peter, há casos em que nenhum algoritmo pode ajudá-lo.

— Agos
fonte

4

Não são sutis diferenças entre os algoritmos de mesclagem de 3 vias, como quais ancestral comum é escolhida, e na qualidade das 2 vias diffs que eles usam em correspondência até as linhas, mas você está certo que os casos em que faz uma diferença prática são relativamente raros.

— Karl Bielefeldt

Não TMK Mercurial não tem uma verdadeira 3 maneira direta, você tem que fazer 2 dois sentidos fusões

— TheLQ

@TheLQ os documentos dizem o contrário: mercurial.selenic.com/wiki/MergeProgram, mas eles são um pouco fracos nos detalhes

— Agos

@ TheLQ - Há uma grande diferença entre uma diferença de três e uma mesclagem de três maneiras . Um diff de três maneiras consiste em dois arquivos a serem mesclados mais um ancestral comum, em que o ancestral comum permite que você veja como as duas fontes divergiram. Uma fusão de três vias precisaria de uma diferença de quatro vias , três arquivos divergentes e seu ancestral comum.

— Mark Booth

3

Eu uso git e mercurial, mas sua pergunta lembra de mim a teoria dos patches dos dardos. Você terá que ler a lição de casa para este fim de semana.

PD: Não me pergunte a teoria dos patches, é muito complexo para mim :)

— Rufo El Magufo
fonte

coisas interessantes, lembre-se de que o SVN se mescla aplicando patches, mas um algoritmo completo de patches que aplica letra r e m à mesma palavra não fornecerá o resultado certo - você ainda precisa de intervenção humana nesse caso.

— Gbjbaanb

3

Chamava-se Controle de Revisão Humana. (Mecanismo de fusão humana)

Usamos o Seapine Surround e, na maioria das vezes, faz um bom trabalho de mesclagem, mas a única maneira de corrigir conflitos de mesclagem que o controle de origem não pode fazer é através da intervenção humana.

Então, meu conselho é:

Tente mesclar rapidamente. Um pesadelo foi ter um ramo que não voltou à linha principal por quase 2 anos. Quando foi mesclado, muitos conflitos precisavam ser resolvidos. Um desenvolvedor ganhou o apelido "mestre de mesclagem" depois de gastar muito tempo corrigindo problemas de mesclagem.

Tenha cuidado com o código gerado automaticamente pelos assistentes, etc. Às vezes, isso pode ser uma verdadeira dor de fusão, especialmente se dois ramos gerados automaticamente mudarem no mesmo arquivo.

Tente controlar o desenvolvimento. Se o desenvolvedor A estiver dividindo os arquivos de código X e Y, não faz muito sentido que o desenvolvedor B trabalhe com X e Y em uma ramificação diferente. Parte do gerenciamento de mesclagem é tentar controlar o que está sendo modificado para evitar o potencial de conflitos de mesclagem.

Isso não quer dizer que 2 desenvolvedores não possam trabalhar no mesmo arquivo em 2 ramos diferentes. Se um desenvolvedor adicionar o método A e outro método de adição B, a mesclagem deverá ocorrer sem problemas.

No final, sempre haverá alguns conflitos que precisam de intervenção humana. Ao mantê-las no mínimo, você obterá os melhores resultados de mesclagem.

— Jon Raynor
fonte

2

Os arquivos gerados automaticamente pelo IMHO não devem estar no controle de versão. Somente os arquivos usados para gerá-los.

— Calmarius

2

O mecanismo de mesclagem perfeito entenderia a semântica do arquivo que está sendo mesclado: portanto, ele analisa e entende o código-fonte. Ainda estou para ver esse mecanismo de mesclagem / controle de versão ...

A maioria das ferramentas de mesclagem mescla arquivos como texto. Para nunca confiar neles cegamente, é sempre uma boa ideia revisar as alterações antes de enviá-las ao seu ramo.

Estamos usando o Perforce, que não se mescla automaticamente. Sempre que o arquivo de origem for alterado em relação à base comum, ele dirá que o arquivo de destino precisa ser resolvido mesmo se não houver conflito. Por isso, abro a ferramenta de mesclagem apenas para avançar rapidamente, pensando se eles se encaixam (e tenha uma ideia geral do que os outros colegas estão fazendo), na maioria das vezes eles se encaixam e aceitam o resultado.

Também assinei as notificações de alterações da linha principal para mesclar as alterações no meu ramo o mais cedo possível para evitar problemas mais tarde.

— Calmarius
fonte

1

Erm ...

Ao usar o mercurial (e o git também, tenho certeza), você escolhe seu mecanismo de mesclagem, por padrão é o kdiff3, mas você pode usar o que quiser (além de comparar, p4merge etc.).

AFAIK, o mecanismo de mesclagem e o VCS geralmente são completamente separados , como seu compilador e editor de texto. Tomemos XML x código, por exemplo, você desejará que coisas diferentes mesclem essas, elas não funcionam da mesma maneira e, portanto, não podem ser mescladas da mesma maneira.

Se você estiver alternando o controle de versão porque precisa de uma ferramenta de mesclagem melhor, por motivos errados, deve alternar o controle de versão apenas quando o que você está usando agora não se encaixa bem no seu processo (ou outro permitem que você use um processo melhor).

— Ed James
fonte

1

Todo VCS possui um algoritmo de mesclagem incorporado que ele usa - as ferramentas de mesclagem a que você se refere somente são usadas quando há conflitos que o mecanismo interno não pode resolver. A pergunta feita é: qual o algoritmo de mesclagem VCS é o "melhor", embora não tenha certeza de que seja uma pergunta bem definida. Algumas pessoas o definem como "produz o menor número de conflitos que precisam de resolução"; Eu diria, dá o menor número de erros.

— ebneter 30/07/11

1

Tenho certeza de que o mercurial realmente usa suas ferramentas diff nos bastidores, há uma configuração para que você possa alterá-la em algum lugar. Todas as ferramentas diff que eu mencionei têm um modo de mesclagem de três vias (não apenas um modo diff), e o p4merge é definitivamente a ferramenta que o perforce usa quando detecta uma colisão. Eu acho que o próprio VCS possui apenas um algoritmo de detecção de colisão (ou seja, você alterou o mesmo arquivo no mesmo local), que é um precursor da fusão.

— Ed

Por padrão, o Mercurial usa um algoritmo de mesclagem simples de três vias. No entanto, sim, você pode substituir isso. Você pode substituir a mesclagem interna na maioria das ferramentas VCS, nesse caso. No entanto, o AFAIK, todos eles usam algum algoritmo de mesclagem interno para procurar conflitos, e esse é realmente um ponto importante aqui - se o algoritmo de mesclagem interna do seu VCS for muito inteligente, ele pode não encontrar um conflito onde deveria.

— Ebneter 01/08/19

Em um DVCS, espero que sempre que um ramo seja mesclado, ele executará todos os arquivos editados nos dois ramos por meio da ferramenta principal de mesclagem. Você não precisaria procurar um conflito de mesclagem, apenas assuma que existe um, se não houver, você não perdeu nada. Eu imagino que o mesmo se aplica a um VCS padrão.

— Ed James

O que você quer dizer com "ferramenta de mesclagem principal"? O algoritmo padrão ou o que você especificou? Se você quer dizer o último, por mais justo que eu saiba, nenhum deles funciona dessa maneira. Todo VCS com o qual estou familiarizado usa seu algoritmo interno para mesclar e somente invoca a ferramenta selecionada pelo usuário se houver um conflito. Observe que alguns VCSs como o git permitem escolher entre várias estratégias integradas, e alguns VCSs têm algoritmos internos bastante sofisticados - mas isso leva ao problema que descrevi na minha resposta.

— ebneter 01/08/19

1

Conflitos são inevitáveis

O quão bem um VCS lida com conflitos dentro de um arquivo é um pouco superestimado. Por um lado, a melhor maneira de lidar com esses conflitos é não tê-los em primeiro lugar. Considerar bem o software e dividir as atribuições com premeditação reduzirá enormemente os conflitos dentro de um cluster de arquivos (quanto mais dentro de um arquivo). Faça um trabalho ruim, como jogar em muitas classes divinas, ou em um arquivo de configuração comum que todos precisam usar e que todos querem mexer, e você está pedindo conflitos no nível do arquivo.

Por outro lado, todos eles usam praticamente o mesmo algoritmo (ruim). Um exemplo: uma versão alfa do nosso projeto teve um pequeno vazamento de memória. Foi mais um gotejamento do que um vazamento, e o vazamento parou no final do tempo de inicialização. Digno de uma correção, não digno de um patch. Um de nossos clientes "corrigiu" o problema, colocando o grátis no lugar errado. O problema foi corrigido na próxima versão. Esse cliente mesclou a nova versão em vez de fazer uma substituição completa (WTF?). Não houve conflitos na fusão de três vias; as ligações para libertar estavam bem isoladas uma da outra. Portanto, agora o software está perdendo o foco devido a uma liberação dupla.

O que está faltando na discussão é o quão difícil / demorado / propenso a erros é mesclar seu trabalho de volta à linha principal do software.

Em svn, você

Confirme as alterações em sua filial.
Mesclar o tronco em seu ramo.
Se você tem um grande projeto, pode pensar em fazer uma pausa para o café ou almoçar.
Ore para que você não veja nenhum conflito de árvore ao voltar.
Confirme os resultados da mesclagem em sua ramificação.
Mesclar seu ramo no tronco.
Faça outra pausa para o café.
Mais uma vez, ore para que você não veja nenhum conflito de árvore ao voltar.
Confirme suas alterações novamente no porta-malas.
Feche a porta para evitar conflitos com seu colega de trabalho que estava tentando fazer a mesma coisa.

São muitas etapas não-atômicas, muitos lugares onde os erros podem surgir (os conflitos das árvores são desagradáveis) e leva muito tempo. Eu já vi vários projetos que desistiram de usar ramificações com subversão, graças ao processo de mesclagem ser tão demorado e propenso a erros. Já vi ainda mais projetos mudarem do subversion em grande parte por causa disso.

— David Hammen
fonte

1

Há um pequeno conjunto de testes chamado mesclagem - que compara o sistema de controle de revisão com os cenários de mesclagem do mundo real. Para cada cenário, garante que um VCS possa fazer o seguinte corretamente:

mesclar o ramo sem conflitos
produzir código que compila
produzir código que se comporte corretamente

Com base no número de testes aprovados na mesclagem, parece que existem duas camadas de desempenho:

Darcs, Git
Bazar, Mercurial

Dependendo das linguagens de programação que você está tentando mesclar, os resultados exatos dos testes podem ser importantes. Consulte o site do projeto para uma tabela de comparação detalhada.

— mndrix
fonte

1

Como não ser um spammer

— mosquito

0

Eu usei o IBM / Rational ClearCase e sua fusão de várias filiais é simplesmente incrível. Executa anéis em torno da subversão. (Nenhuma experiência de Git ou mercurial.)

— rapid_now
fonte

A mesclagem de hg é par ou melhor que cc. Eu usei os dois.

— Paul Nathan