Quais são os pontos fortes e fracos relativos do Git, Mercurial e Bazaar?[fechado]
https://stackoverflow.com/questions/77485
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
O que as pessoas aqui veem como os pontos fortes e fracos relativos do Git, Mercurial e Bazaar?
Ao considerar cada um deles entre si e em relação a sistemas de controle de versão como SVN e Perforce, quais questões devem ser consideradas?
Ao planejar uma migração do SVN para um desses sistemas distribuídos de controle de versão, que fatores você consideraria?
Solução
O Git é muito rápido, escala muito bem e é muito transparente sobre seus conceitos.A desvantagem disso é que ele tem uma curva de aprendizado relativamente íngreme.Uma porta Win32 está disponível, mas não é exatamente um cidadão de primeira classe.O Git expõe hashes como números de versão aos usuários;isso fornece garantias (no sentido de que um único hash sempre se refere exatamente ao mesmo conteúdo;um invasor não pode modificar o histórico sem ser detectado), mas pode ser complicado para o usuário.O Git tem um conceito único de rastrear o conteúdo dos arquivos, mesmo quando esses conteúdos se movem entre os arquivos, e visualiza os arquivos como objetos de primeiro nível, mas não rastreia diretórios.Outro problema com o git é que ele possui muitas operações (como rebase) que facilitam a modificação do histórico (em certo sentido - o conteúdo referido por um hash nunca mudará, mas as referências a esse hash podem ser perdidas);alguns puristas (inclusive eu) não gostam muito disso.
O Bazaar é razoavelmente rápido (muito rápido para árvores com histórico superficial, mas atualmente não se adapta bem ao comprimento do histórico) e é fácil de aprender para aqueles familiarizados com as interfaces de linha de comando dos SCMs tradicionais (CVS, SVN, etc).Win32 é considerado um alvo de primeira classe pela sua equipe de desenvolvimento.Possui arquitetura conectável para diversos componentes e substitui frequentemente seu formato de armazenamento;isso lhes permite introduzir novos recursos (como melhor suporte para integração com sistemas de controle de revisão baseados em diferentes conceitos) e melhorar o desempenho.A equipe do Bazaar considera o rastreamento de diretório e o suporte para renomeação como funcionalidade de primeira classe.Embora identificadores de ID de revisão globalmente exclusivos estejam disponíveis para todas as revisões, revnos locais em árvore (números de revisão padrão, mais parecidos com aqueles usados por svn ou outros SCMs mais convencionais) são usados no lugar de hashes de conteúdo para identificar revisões.O Bazaar tem suporte para “checkouts leves”, nos quais o histórico é mantido em um servidor remoto em vez de copiado para o sistema local e é automaticamente referenciado pela rede quando necessário;atualmente, isso é único entre os DSCMs.
Ambos têm alguma forma de integração SVN disponível;entretanto, o bzr-svn é consideravelmente mais capaz que o git-svn, em grande parte devido às revisões de formato de back-end introduzidas para esse propósito. [Atualização, a partir de 2014:O produto comercial de terceiros SubGit fornece uma interface bidirecional entre SVN e Git que é comparável em fidelidade ao bzr-svn e consideravelmente mais refinada;EU fortemente recomendo seu uso em vez do git-svn quando as restrições de orçamento e licenciamento permitirem].
Eu não usei o Mercurial extensivamente e, portanto, não posso comentar sobre ele em detalhes - exceto para observar que ele, como o Git, possui endereçamento de hash de conteúdo para revisões;também como o Git, ele não trata diretórios como objetos de primeira classe (e não pode armazenar um diretório vazio).É, no entanto, mais rápido do que qualquer outro DSCM, exceto Git, e tem uma integração IDE muito melhor (especialmente para Eclipse) do que qualquer um de seus concorrentes.Dadas suas características de desempenho (que ficam apenas um pouco atrás das do Git) e seu suporte superior de plataforma cruzada e IDE, o Mercurial pode ser atraente para equipes com um número significativo de membros centrados em win32 ou vinculados a IDE.
Uma preocupação na migração do SVN é que os frontends GUI e a integração IDE do SVN são mais maduros do que aqueles de qualquer um dos SCMs distribuídos.Além disso, se você atualmente faz uso intenso da automação de scripts pré-confirmados com SVN (ou seja,exigindo que testes de unidade sejam aprovados antes que um commit possa prosseguir), você provavelmente desejará usar uma ferramenta semelhante a PQM para automatizar solicitações de mesclagem para suas filiais compartilhadas.
SVK é um DSCM que usa Subversion como armazenamento de apoio e tem uma integração muito boa com ferramentas centradas em SVN.No entanto, ele tem características de desempenho e escalabilidade dramaticamente piores do que qualquer outro DSCM importante (até mesmo Darcs) e deve ser evitado em projetos que podem crescer muito em termos de comprimento de histórico ou número de arquivos.
[Sobre o autor:Eu uso Git e Perforce para trabalho, e Bazaar para meus projetos pessoais e como biblioteca incorporada;outras partes da organização do meu empregador usam muito o Mercurial.Em uma vida anterior, desenvolvi muita automação em torno do SVN;antes disso tenho experiência com GNU Arch, BitKeeper, CVS e outros.O Git foi bastante desanimador no início - parecia o GNU Arch na medida em que era um ambiente com muitos conceitos, em oposição aos kits de ferramentas construídos para se adequar à escolha de fluxos de trabalho do usuário - mas desde então fiquei bastante confortável com isto].
Outras dicas
Steve Streeting do projeto Ogre 3D acaba de (28/09/2009) publicar uma entrada no blog sobre este tópico onde ele faz um ótimo e imparcial comparação de Git, Mercurial e Bazaar.
No final, ele encontra pontos fortes e fracos nos três e nenhum vencedor claro.Do lado positivo, ele oferece uma ótima mesa para ajudá-lo a decidir qual escolher.
É uma leitura curta e eu recomendo fortemente.
O que as pessoas aqui veem como os pontos fortes e fracos relativos do Git, Mercurial e Bazaar?
Na minha opinião Git O ponto forte é seu design subjacente limpo e um conjunto muito rico de recursos.Acho que ele também tem o melhor suporte para repositórios de várias filiais e gerenciamento de fluxos de trabalho com muitas filiais.É muito rápido e possui tamanho de repositório pequeno.
Possui alguns recursos que são úteis, mas exigem algum esforço para se acostumar com eles.Esses incluem visível ara de preparação intermediária (índice) entre a área de trabalho e o banco de dados do repositório, o que permite melhor resolução de mesclagem em casos mais complicados, commit incremental e commit com árvore suja; detecção renomeia e copia usando heurística de similaridade em vez de rastreá-los usando algum tipo de ID de arquivo, o que funciona bem e permite culpar (anotar) que pode seguir o movimento do código entre arquivos e não apenas renomeações em massa.
Uma de suas desvantagens é que o suporte do MS Windows fica para trás e não está completo.Outra desvantagem percebida é que ele não está tão bem documentado como, por exemplo, o Mercurial, e é menos amigável que a concorrência, mas muda.
Na minha opinião Mercurial o ponto forte está em seu bom desempenho e pequeno tamanho de repositório, em seu bom suporte ao MS Windows.
A principal desvantagem é, na minha opinião, o fato de que as filiais locais (múltiplas filiais em um único repositório) ainda são cidadãs de segunda classe e, de maneira estranha e complicada, implementam tags.Além disso, a maneira como ele lida com a renomeação de arquivos não era ideal (mas isso pode ter mudado).O Mercurial não suporta mesclagens de polvo (com mais de dois pais).
Pelo que ouvi e li principal Bazar as vantagens são o fácil suporte para fluxo de trabalho centralizado (o que também é uma desvantagem, com conceitos centralizados visíveis onde não deveria), rastreando renomeações de arquivos e diretórios.
Sua principal desvantagem é o desempenho e o tamanho do repositório para repositórios grandes com longo histórico não linear (o desempenho melhorou pelo menos para repositórios não muito grandes), o fato de que o paradigma padrão é um rancho por repositório (embora você possa configurá-lo para compartilhar dados) e conceitos centralizados (mas isso também, pelo que ouvi, muda).
Git é escrito em C, shell scripts e Perl, e é programável;Mercurial é escrito em C (núcleo, para desempenho) e Python e fornece API para extensões;Bazaar é escrito em Python e fornece API para extensões.
Ao considerar cada um deles entre si e em relação a sistemas de controle de versão como SVN e Perforce, quais questões devem ser consideradas?
Sistemas de controle de versão como Subversion (SVN), Perforce ou ClearCase são centralizado sistemas de controle de versão.Git, Mercurial, Bazaar (e também Darcs, Monotone e BitKeeper) são distribuído sistemas de controle de versão.Os sistemas de controle de versão distribuídos permitem uma gama muito mais ampla de fluxos de trabalho.Eles permitem usar "publicar quando estiver pronto".Eles têm melhor suporte para ramificações e mesclagens e para fluxos de trabalho com muitas ramificações.Você não precisa confiar em pessoas com acesso de commit para poder obter contribuições delas de maneira fácil.
Ao planejar uma migração do SVN para um desses sistemas distribuídos de controle de versão, que fatores você consideraria?
Um dos fatores que você pode querer considerar é o suporte para interação com SVN;Git tem git-svn, Bazaar tem bzr-svn e Mercurial tem extensão hgsubversion.
Isenção de responsabilidade: Sou usuário do Git e contribuidor pequeno, e assisto (e participo) da lista de discussão do git.Conheço o Mercurial e o Bazaar apenas por sua documentação, várias discussões sobre IRC e listas de discussão, e postagens de blog e artigos comparando vários sistemas de controle de versão (alguns dos quais estão listados em Comparação Git página no Git Wiki).
InfoQ tem uma bela comparação.
Mercurial e Bazaar se parecem muito na superfície.Ambos fornecem controle de versão distribuído básico, como no commit offline e na fusão de várias ramificações, são escritos em python e são mais lentos que o git.Existem muitas diferenças quando você se aprofunda no código, mas, para suas tarefas rotineiras do dia a dia, elas são efetivamente as mesmas, embora o Mercurial pareça ter um pouco mais de impulso.
Git, bem, não é para os não iniciados.É muito mais rápido que o Mercurial e o Bazaar e foi escrito para gerenciar o kernel Linux.É o mais rápido dos três e também o mais poderoso dos três, por uma boa margem.As ferramentas de manipulação de log e commit do Git são incomparáveis.No entanto, é também o mais complicado e perigoso de usar.É muito fácil perder um commit ou arruinar um repositório, especialmente se você não entende o funcionamento interno do git.
Dê uma olhada na comparação feita recentemente pelos desenvolvedores Python: http://wiki.python.org/moin/DvcsComparison.Eles escolheram a Mercurial com base em três razões importantes:
A escolha da Mercurial foi feita por três motivos importantes:
- De acordo com uma pequena pesquisa, os desenvolvedores do Python estão mais interessados em usar mercurial do que no bazar ou no Git.
- Mercurial é escrito em Python, o que é congruente com a tendência do python-dev de 'comer sua própria comida de cachorro'.
- O Mercurial é significativamente mais rápido que o bzr (é mais lento que o git, embora por uma diferença muito menor).
- Mercurial é mais fácil de aprender para usuários de SVN do que Bazaar.
Eu estava usando o Bazaar há um tempo e gostei muito, mas eram apenas projetos menores e mesmo assim era bem lento.Tão fácil de aprender, mas não muito rápido.É uma plataforma muito x.
Atualmente uso Git, que gosto muito, pois a versão 1.6 o tornou muito mais parecido com outros VCS em termos de comandos a serem usados.
Acho que as principais diferenças para minha experiência no uso de DVCS são estas:
- Git tem a comunidade mais vibrante e é comum ver artigos sobre Git
- GitHub realmente arrasa.Launchpad.net está ok, mas nada como o prazer do Github
- O número de ferramentas de fluxo de trabalho para Git tem sido grande.Está integrado em todo o lugar.Existem alguns para Bzr, mas não tantos ou tão bem conservados.
Em resumo, o Bzr era ótimo quando eu estava começando no DVCS, mas agora estou muito feliz com o Git e o Github.
Esta é uma grande questão que depende muito do contexto e levaria muito tempo para você digitar em uma dessas pequenas caixas de texto.Além disso, todos os três parecem substancialmente semelhantes quando usados para as coisas usuais que a maioria dos programadores faz, portanto, mesmo a compreensão das diferenças requer algum conhecimento bastante esotérico.
Você provavelmente obterá respostas muito melhores se puder dividir sua análise dessas ferramentas até o ponto em que tenha perguntas mais específicas.
Bazaar é IMHO mais fácil de aprender do que git.Git tem um bom suporte em github.com.
Acho que você deveria tentar usar os dois e decidir qual combina mais com você.
O que as pessoas aqui veem como os pontos fortes e fracos relativos do Git, Mercurial e Bazaar?
Esta é uma questão muito aberta, beirando o flamebait.
O Git é mais rápido, mas todos os três são rápidos o suficiente.O Bazaar é o mais flexível (possui suporte transparente de leitura e gravação para repositórios SVN) e se preocupa muito com a experiência do usuário.Mercurial está em algum lugar no meio.
Todos os três sistemas têm muitos fanboys.Pessoalmente, sou um fanboy do Bazar.
Ao considerar cada um deles entre si e em relação a sistemas de controle de versão como SVN e Perforce, quais questões devem ser consideradas?
Os primeiros são sistemas distribuídos.Estes últimos são sistemas centralizados.Além disso, o Perforce é proprietário enquanto todos os outros são gratuitos como na fala.
Centralizado versus descentralizado é uma escolha muito mais importante do que qualquer um dos sistemas que você mencionou em sua categoria.
Ao planejar uma migração do SVN para um desses sistemas distribuídos de controle de versão, que fatores você consideraria?
Primeiro, a falta de um bom substituto para o TortoiseSVN.Embora o Bazaar esteja trabalhando por conta própria Variante tartaruga, mas ainda não chegou lá, em setembro de 2008.
Em seguida, treinar as pessoas-chave sobre como o uso de um sistema descentralizado afetará seu trabalho.
Por fim, integração com o restante do sistema, como rastreadores de problemas, sistema de build noturno, sistema de teste automatizado, etc.
Seu principal problema será que estes são Distribuído SCMs e, como tal, exigem uma pequena mudança na mentalidade do usuário.Depois que as pessoas se acostumarem com a ideia, os detalhes técnicos e os padrões de uso se encaixarão, mas não subestime esse obstáculo inicial, especialmente em um ambiente corporativo.Lembre-se de que todos os problemas são problemas pessoais.
ddaa.myopenid.com mencionou isso de passagem, mas acho que vale a pena mencionar novamente:O Bazaar pode ler e gravar em repositórios SVN remotos.Isso significa que você pode usar o Bazaar localmente como uma prova de conceito enquanto o resto da equipe ainda usa o Subversion.
EDITAR:Praticamente todas as ferramentas agora têm alguns maneira de interagir com SVN, mas agora tenho experiência pessoal que git svn funciona extremamente bem.Estou usando há meses, com soluços mínimos.
Há um bom vídeo de Linus Torvalds no git.Ele é o criador do Git, então é isso que ele promove, mas no vídeo ele explica o que são SCMs distribuídos e por que eles são melhores que os centralizados.Há muitas comparações entre git (mercurial é considerado OK) e cvs/svn/perforce.Também há dúvidas do público em relação à migração para SCM distribuído.
Achei este material esclarecedor e estou vendido para SCM distribuído.Mas apesar dos esforços de Linus, minha escolha é inconstante.O motivo é bitbucket.org, achei melhor (mais generoso) que o github.
Preciso dizer aqui uma palavra de advertência:Linus tem um estilo bastante agressivo, acho que ele quer ser engraçado mas não ri.Além disso, o vídeo é ótimo se você é novo em SCMs distribuídos e está pensando em migrar do SVN.
Os sistemas de controle de versão distribuídos (DVCSs) resolvem problemas diferentes dos VCSs centralizados.Compará-los é como comparar martelos e chaves de fenda.
VCS centralizado os sistemas são projetados com a intenção de que exista Uma Fonte Verdadeira que é Abençoada e, portanto, Boa.Todos os desenvolvedores trabalham (checkout) a partir dessa fonte e, em seguida, adicionam (confirmam) suas alterações, que então se tornam abençoadas de forma semelhante.A única diferença real entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe e todos os outros CVCSes está no fluxo de trabalho, desempenho e integração que cada produto oferece.
VCS distribuído os sistemas são projetados com a intenção de que um repositório seja tão bom quanto qualquer outro e que as fusões de um repositório para outro sejam apenas outra forma de comunicação.Qualquer valor semântico sobre qual repositório deve ser confiável é imposto de fora pelo processo, e não pelo software em si.
A verdadeira escolha entre usar um tipo ou outro é organizacional – se o seu projeto ou organização deseja controle centralizado, então um DVCS é um fracasso.Se espera-se que seus desenvolvedores trabalhem em todo o país/mundo, sem conexões seguras de banda larga a um repositório central, então o DVCS é provavelmente a sua salvação.Se você precisar de ambos, você está perdido.
