Gerenciamento de controle de versão de grandes projetos

4

Estou acostumado a controlar a versão, em especial uso atualmente o Mercurial. Eu tenho algumas dúvidas sobre como fazê-lo funcionar em grandes equipes, onde há uma boa probabilidade de ter mais pessoas trabalhando no mesmo arquivo.

Deixe-me fazer um exemplo com o Mercurial (mas qualquer sistema descentralizado será mais ou menos o mesmo). Digamos que temos um servidor central e três desenvolvedores Alice, Bob e Carl. Os três decidem começar a trabalhar no mesmo momento e todos eles saem do servidor. Por acaso acontece que eles estão trabalhando no mesmo arquivo.

Alice termina primeiro e empurra as alterações para o servidor. Então Bob e Carl terminam, mais ou menos ao mesmo tempo. Antes de empurrar, eles verificam se há algo novo e encontram o commit de Alice. Então eles puxam, e cada um mescla as mudanças localmente. Então Bob empurra e Carl empurra suas mudanças.

O que acontece aqui é que no servidor há duas cabeças: uma de Bob e outra de Carl, e ambas incluem fusões com o trabalho de Alice. Quem puxar agora do servidor vai encontrar uma pequena bagunça. É claro que se pode simplesmente fundir as cabeças de Bob e Carl, mas isso pode não ser tão simples. Bob e Carl podem ter idéias diferentes sobre como se fundir com o trabalho de Alice.

Assim que mais pessoas começarem a trabalhar no projeto, as coisas podem piorar ainda mais. Então, enquanto na teoria eu entendo como as fusões devem funcionar, não está claro para mim como tornar as coisas gerenciáveis em um grande projeto.

How do people manage to resolve conflicts when there are many people working on the same file, possibly having done different merges in different orders?

    
por Andrea 29.04.2011 / 10:34
fonte

7 respostas

5

A maneira como isso é feito é que cada desenvolvedor deve mesclar as alterações antes de confirmar um arquivo. Eu nunca usei o Mercurial, então eu não sei os comandos ou o processo exato, mas em qualquer ferramenta séria de gerenciamento de configuração você será avisado se tentar fazer o check-in "por cima" de outra pessoa. Quando você receber esse aviso, você deverá mesclar as outras alterações na sua cópia com check-out, verificar a compilação e os testes, etc. e, em seguida, fazer check-in.

Este é um problema muito comum, e a fusão dessa maneira pode ser uma PITA real, mas é a vida. A abordagem alternativa de bloquear todos os arquivos com check-out evita esse problema, mas tem a séria desvantagem de bloquear todos os outros enquanto você trabalha em um arquivo, o que, por sua vez, leva as pessoas a editar versões descontroladas. >     

por 29.04.2011 / 10:40
fonte
5

Não tenho certeza se o Mercurial é diferente, mas o git simplesmente não permite * que você envie para um destino que tenha divergido da sua filial (por exemplo, no seu caso, se o Bob empurrar primeiro , então o servidor divergiu do ramo de Carl). Carl deve derrubar as mudanças de Bob, comprometê-las e depois empurrar.

* bem, se você usar a opção --force. Mas se você tem que usar isso, você deve saber o porquê.

    
por 29.04.2011 / 12:05
fonte
5

Com o mercurial, você só pode ter várias cabeças no repositório upstream se Carl forçar seu push. O que deve acontecer é que depois que Bob e Carl fizerem a fusão das mudanças de Alice, Bob, que deve empurrar primeiro, deve ser Ok, mas Carl receberá uma mensagem dizendo que seu empurrão criaria novas cabeças remotas e que seu empurrão seria cancelado. / p>

A solução, é claro, é para Carl puxar as mudanças do Bobs, juntá-las e depois empurrar de volta essa fusão também, para que você acabe com todos os três conjuntos de mudanças.

A freqüência com que você vê esse tipo de problema dependerá do tamanho do seu repositório e da frequência com que os desenvolvedores trabalham nas mesmas coisas simultaneamente. Também depende se os desenvolvedores têm o hábito de forçar os push (ou configurar suas ferramentas para fazê-lo automaticamente). Se este for o caso, eu recomendaria strongmente contra ele.

Se você vê pessoas trabalhando no mesmo código com muita frequência, talvez você deva verificar se seu aplicativo tem excesso de acoplamento (digamos, um super-singleton que precisa ser editado sempre que alguém mudar alguma coisa em qualquer outro lugar no código) ou se você precisa dividir seu repositório em um grupo de sub-repositórios.

    
por 29.04.2011 / 12:30
fonte
2

Algo está errado com sua configuração do Mercurial (ou não sei como esse sistema deve funcionar). Não deveria permitir o surgimento de "duas cabeças". Deve ser Alice - & nbsp; Bob - & Carl - Alice & Alice - & nbsp; Carl & Bob; Foi assim que funcionou no Subversion em ambas as equipes em que trabalhei, e sempre conseguimos resolver os conflitos. A mesclagem contínua ajuda muito. Tentar mesclar o trabalho de dois meses de vários desenvolvedores em um ramo diferente geralmente dói.

    
por 29.04.2011 / 10:42
fonte
2

Não é tão ruim quanto você pensa que seria na prática.

Na teoria , se duas pessoas estivessem trabalhando no mesmo arquivo nas mesmas linhas , então é um problema que precisa de intervenção manual.

No entanto, na prática , essa situação é muito rara. É mais provável que eles estejam trabalhando no mesmo arquivo, mas em locais diferentes. Se os dois (ou três, ou quatro) desenvolvedores estão trabalhando em seções diferentes do arquivo, a mesclagem automática é geralmente inteligente o suficiente para descobrir isso.

Há ocasiões em que modifiquei uma linha de código e um colega de trabalho modificou a linha mesmo para que, quando eu puxar o mais recente do controle de origem, eu precise mesclar manualmente. Mas isso é raro e geralmente só acontece se eu fizer uma alteração grande que toque um grande número de linhas de qualquer maneira (por exemplo, se eu tiver modificado algumas APIs usadas por muitos clientes).

    
por 29.04.2011 / 13:00
fonte
0

Seu cenário - três pessoas - um arquivo - é um sintoma de arquitetura deficiente e gerenciamento inadequado.

Este não é um problema de ferramenta.

    
por 29.04.2011 / 14:02
fonte
0

Eu não sei se o mercurial suporta isso, mas em uma pequena equipe coesa, o fluxo de trabalho centralizado pode ser o melhor. Neste fluxo de trabalho, os desenvolvedores precisam atualizar / extrair o servidor central antes de poderem enviar um novo commit.

Em projetos maiores ou distribuídos, recomendo o fluxo de trabalho do gatekeeper :

  • Os desenvolvedores não se mesclam. O gatekeeper mescla as ramificações do desenvolvedor em um ramo designado como o ramo oficial.
  • Os desenvolvedores trabalham em ramos de recursos e, quando um recurso é feito, eles propõem ao gatekeeper a mesclagem.
  • O gatekeeper tem uma boa compreensão geral do projeto. Se a fusão de uma ramificação resultar em conflitos, ele pode precisar da ajuda do desenvolvedor para resolvê-los, mas talvez não, já que os conflitos devem ser causados por uma proposta de mesclagem que ele recentemente aprovou.
  • O gatekeeper também é responsável pela qualidade do código e pelas práticas recomendadas em todo o projeto. Ele rejeita propostas de mesclagem que tenham algum problema, o desenvolvedor original deve executar as correções necessárias e reenviar sua ramificação.
  • Ser um gatekeeper é uma atividade em tempo integral.
  • À medida que o projeto cresce, pode haver mais gatekeepers, formando uma hierarquia.
por 14.07.2012 / 14:14
fonte