it-swarm-pt.tech

Quais são os pontos fortes e fracos de Git, Mercurial e Bazaar?

O que as pessoas aqui veem como os pontos fortes e fracos de Git, Mercurial e Bazaar?

Ao considerar cada um deles um com o outro e contra sistemas de controle de versão como SVN e Perforce, que problemas devem ser considerados?

Ao planejar uma migração do SVN para um desses sistemas de controle de versão distribuído, que fatores você consideraria?

135
Jordan Dea-Mattson

O Git é muito rápido, dimensiona muito bem e é muito transparente sobre seus conceitos. O lado negativo disso é que ele tem uma curva de aprendizado relativamente íngreme. Uma porta Win32 está disponível, mas não é um cidadão de primeira classe. O Git expõe hashes como números de versão para os usuários; isso fornece garantias (na medida em 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 do arquivo, mesmo quando esse conteúdo se move entre os arquivos e visualiza os arquivos como objetos de primeiro nível, mas não controla os diretórios. Outro problema com o git é que ele tem muitas operações (como rebase), que facilitam a modificação do histórico (em certo sentido - o conteúdo referido por um hash nunca muda, 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 raso, mas atualmente varia muito pouco com o tamanho do histórico) e é fácil de aprender para aqueles familiarizados com as interfaces de linha de comando dos SCMs tradicionais (CVS, SVN, etc.). O Win32 é considerado um destino de primeira classe por sua equipe de desenvolvimento. Possui uma arquitetura conectável para diferentes componentes e substitui seu formato de armazenamento com frequência; isso lhes permite introduzir novos recursos (como melhor suporte à integração com sistemas de controle de revisão com base em diferentes conceitos) e melhorar o desempenho. A equipe do Bazaar considera o rastreamento de diretório e renomeia o suporte à funcionalidade de primeira classe. Embora estejam disponíveis identificadores de revisão globalmente exclusivos para todas as revisões, os revnos locais da árvore (números de revisão padrão, mais parecidos com os usados ​​pelo svn ou outros SCMs mais convencionais) são usados ​​no lugar dos hashes de conteúdo para identificar as 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 referido na rede quando necessário; no momento, isso é único entre os DSCMs.

Ambos têm alguma forma de integração SVN disponível; no entanto, 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 fim. [Atualização a partir de 2014: o produto comercial de terceiros SubGit fornece uma interface bidirecional entre o SVN e o Git, que é comparável em fidelidade ao bzr-svn, e consideravelmente mais polido; Eu fortemente recomende seu uso em vez do git-svn quando restrições de orçamento e licenciamento permitirem].

Eu não usei o Mercurial extensivamente e, portanto, não posso comentar sobre isso em detalhes - exceto para observar que, como o Git, possui um endereço de hash de conteúdo para revisões; também como o Git, ele não trata os diretórios como objetos de primeira classe (e não pode armazenar um diretório vazio). É, no entanto, mais rápido que qualquer outro DSCM, exceto o Git, e possui uma integração IDE muito melhor (especialmente para o Eclipse) do que qualquer um de seus concorrentes. Dadas suas características de desempenho (que estão um pouco atrás das do Git) e sua plataforma cruzada e suporte IDE superiores, o Mercurial pode ser atraente para equipes com número significativo de membros centrados no win32 ou vinculados ao IDE.

Uma preocupação na migração do SVN é que as interfaces de interface gráfica do usuário do SVN e a integração IDE são mais maduras do que as de qualquer um dos SCMs distribuídos. Além disso, se você atualmente usa intensamente a automação de script de pré-confirmação com o SVN (por exemplo, exigindo que os testes de unidade sejam aprovados antes que uma confirmação possa prosseguir), provavelmente desejará usar uma ferramenta semelhante a PQM para automatizar solicitações de mesclagem em suas ramificações compartilhadas.

O SVK é um DSCM que usa o Subversion como loja de suporte e possui uma integração muito boa com ferramentas centradas no SVN. No entanto, possui características de desempenho e escalabilidade dramaticamente piores do que qualquer outro DSCM principal (mesmo Darcs), e deve ser evitado para projetos que possam crescer muito em termos de tamanho do histórico ou número de arquivos.

[Sobre o autor: Eu uso Git e Perforce para o trabalho, e Bazaar para meus projetos pessoais e como uma biblioteca incorporada; outras partes da organização de meu empregador usam muito o Mercurial. Em uma vida anterior, construí muita automação em torno do SVN; antes disso eu tenho experiência com GNU Arch, BitKeeper, CVS e outros. O Git foi bastante desanimador no começo - parecia que o Arch GNU era na medida em que era um ambiente pesado de conceito, em oposição a kits de ferramentas criados para se adequar à escolha de fluxos de trabalho do usuário - mas desde então fique bastante confortável com isso].

142
Charles Duffy

Steve Streeting, do projeto Ogre 3D, acaba de (28/09/2009) publicar uma entrada de blog sobre esse tópico, onde ele faz um ótimo e imparcial comparação de Git, Mercurial e Bazaar .

No final, ele encontra pontos fortes e fracos com todos os três e nenhum vencedor claro. No lado positivo, ele oferece uma ótima mesa para ajudá-lo a decidir com o que escolher.

alt text

É uma leitura curta e eu recomendo.

19
Michael La Voie

O que as pessoas aqui veem como os pontos fortes e fracos relativos de Git, Mercurial e Bazaar?

Na minha opinião Git a força é seu design subjacente limpo e um conjunto muito rico de recursos. Também acho que é o melhor suporte para repositórios com várias ramificações e para gerenciar fluxos de trabalho com muita ramificação. É muito rápido e possui um tamanho pequeno de repositório.

Possui alguns recursos que são úteis, mas exigem algum esforço para serem usados ​​com eles. Isso inclui visible ara intermediário de intermediação (índice) entre a área de trabalho e o banco de dados do repositório, o que permite uma melhor resolução de mesclagem em casos mais complicados, confirmação incremental e confirmação com árvore suja; detectando renomeia e copia usando heurística de similaridade, em vez de rastreá-las usando algum tipo de ID de arquivo, que funciona bem e permite culpar (anotar) que pode seguir o movimento do código nos arquivos e não apenas no atacado renomeia.

Uma de suas desvantagens é que o suporte ao MS Windows fica para trás e não está cheio. Outra desvantagem percebida é que ela não é tão bem documentada quanto a Mercurial, e é menos amigável que a concorrência, mas muda.

Na minha opinião , a força do Mercurial reside no bom desempenho e no tamanho pequeno do repositório, no bom suporte ao MS Windows.

A principal desvantagem é, na minha opinião, o fato de que as filiais locais (várias filiais no repositório único) ainda são cidadãos de segunda classe e, de maneira estranha e complicada, implementam tags. Além disso, a maneira como lida com as renomeações de arquivos foi abaixo do ideal (mas essa migração mudou). O Mercurial não suporta fusões de polvo (com mais de dois pais).

Pelo que ouvi e li, as principais vantagens do Bazaar são o suporte fácil ao 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 grandes repositórios com histórico não linear longo (o desempenho melhorou pelo menos para repositórios não muito grandes), o fato de que o paradigma padrão é uma fazenda por repositório (você pode configurá-lo para compartilhar dados) e conceitos centralizados (mas também pelo que ouvi mudanças).

O Git é escrito em C, scripts Shell e Perl, e é programável; O Mercurial é escrito em C (core, para desempenho) e Python, e fornece API para extensões; O Bazaar é escrito em Python e fornece API para extensões.


Ao considerar cada um deles um com o outro e contra sistemas de controle de versão como SVN e Perforce, que problemas devem ser considerados?

Sistemas de controle de versão como Subversion (SVN), Perforce ou ClearCase são centralizados sistemas de controle de versão. Git, Mercurial, Bazaar (e também Darcs, Monotone e BitKeeper) são distribuídos sistemas de controle de versão. Os sistemas de controle de versão distribuídos permitem uma gama muito maior de fluxos de trabalho. Eles permitem usar "publicar quando estiver pronto". Eles têm melhor suporte para ramificação e mesclagem, e para fluxos de trabalho pesados ​​para ramificação. Você não precisa confiar nas pessoas com acesso de confirmação para poder obter contribuições delas de maneira fácil.


Ao planejar uma migração do SVN para um desses sistemas de controle de versão distribuídos, que fatores você consideraria?

Um dos fatores que você pode querer considerar é o suporte à invasão com o SVN; O Git possui git-svn, o Bazaar possui bzr-svn e o Mercurial possui a extensão hgsubversion.

Isenção de responsabilidade: Sou usuário do Git e pequeno colaborador de tempo, e assisto (e participo da) lista de discussão do git. Conheço o Mercurial e o Bazaar apenas pela documentação, várias discussões sobre IRC e listas de discussão e postagens e artigos de blog comparando vários sistemas de controle de versão (alguns dos quais estão listados em GitComparison página no Git Wiki).

15
Jakub Narębski
14
Pat Notz

Mercurial e Bazaar se parecem muito com a superfície. Ambos fornecem controle básico de versão distribuída, como no commit offline e na mesclagem de várias ramificações, ambos são escritos em python e são mais lentos que o git. Existem muitas diferenças quando você mergulha no código, mas , para as tarefas rotineiras do dia-a-dia, elas são efetivamente as mesmas, embora o Mercurial pareça ter um pouco mais de força.

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 do 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 confirmação do Git são incomparáveis. No entanto, é também o mais complicado e mais perigoso de usar. É muito fácil perder um commit ou arruinar um repositório, especialmente se você não entender o funcionamento interno do git.

7
Herge

Dê uma olhada na comparação feita recentemente pelos desenvolvedores Python: http://wiki.python.org/moin/DvcsComparison . Eles escolheram o Mercurial com base em três razões importantes:

A escolha de ir com o Mercurial foi feita por três razões importantes:

  • De acordo com uma pequena pesquisa, Python desenvolvedores estão mais interessados ​​em usar o Mercurial do que no Bazaar ou no Git.
  • Mercurial é escrito em Python, que é congruente com a tendência python-dev de "comer seu próprio alimento para cães".
  • Mercurial é significativamente mais rápido que bzr (é mais lento que git, embora por uma diferença muito menor).
  • O Mercurial é mais fácil de aprender para os usuários do SVN do que o Bazaar.

(from http://www.python.org/dev/peps/pep-0374/ )

6
Martin Geisler

A Sun fez uma avaliação de git , Mercurial e Bazaar como candidatos para substituir o Sun Teamware VCS pela base de código do Solaris. Achei muito interessante.

5
DGentry

Uma coisa muito importante que falta no Bazaar é cp. Você não pode ter vários arquivos compartilhando o mesmo histórico, como no SVN, veja por exemplo aqui e aqui . Se você não planeja usar o cp, o bzr é um ótimo (e muito fácil de usar) substituto para o svn.

2
Davide

Eu estava usando o Bazaar por um tempo que gostei muito, mas eram apenas projetos menores e, mesmo assim, era bem lento. Tão fácil de aprender, mas não super rápido. É muito x-plataforma embora.

Atualmente, uso o Git, que gosto muito desde a versão 1.6, que o tornou muito mais semelhante a outros VCS em termos de comandos a serem usados.

Penso que as principais diferenças da minha experiência no uso do DVCS são as seguintes:

  1. O Git tem a comunidade mais vibrante e é comum ver artigos sobre o Git
  2. GitHub realmente arrasa. Launchpad.net está ok, mas nada como o prazer do Github
  3. O número de ferramentas de fluxo de trabalho para o Git tem sido grande. Está integrado em todo o lugar. Existem alguns para o Bzr, mas não quase tantos ou bem conservados.

Em resumo, o Bzr foi ótimo quando eu estava cortando os dentes no DVCS, mas agora estou muito feliz com o Git e o Github.

2
sh1mmer

Seu principal problema será que esses são distribuídos SCMs e, como tal, exigem uma pequena alteração na mentalidade do usuário. Quando as pessoas se acostumam com a idéia, os detalhes técnicos e os padrões de uso se encaixam, mas não subestimam esse obstáculo inicial, especialmente em ambientes corporativos. Lembre-se, todos os problemas são problemas das pessoas.

1
David Plumpton

Bazar é IMHO mais fácil de aprender do que git. O Git tem um suporte agradável no github.com.

Eu acho que você deve tentar usar os dois e decidir qual combina mais com você.

1
Rafał Rawicki

Essa é uma grande pergunta que depende muito do contexto que 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 fazem, portanto, mesmo o entendimento das diferenças requer algum conhecimento bastante esotérico.

Você provavelmente obterá respostas muito melhores se puder analisar sua análise dessas ferramentas até o ponto em que tiver perguntas mais específicas.

1
jfm3

O que as pessoas aqui veem como os pontos fortes e fracos de Git, Mercurial e Bazaar?

Esta é uma pergunta muito aberta, na fronteira com flamebait.

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. Eu sou pessoalmente um fanboy do Bazaar.

Ao considerar cada um deles um com o outro e contra sistemas de controle de versão como SVN e Perforce, que problemas devem ser considerados?

Os primeiros são sistemas distribuídos. Os últimos são sistemas centralizados. Além disso, o Perforce é proprietário, enquanto todos os outros são gratuitos como no discurso .

Centralizado versus descentralizado é uma escolha muito mais importante do que qualquer um dos sistemas que você mencionou nessa categoria.

Ao planejar uma migração do SVN para um desses sistemas de controle de versão distribuído, que fatores você consideraria?

Primeiro, falta de um bom substituto para o TortoiseSVN. Embora o Bazaar esteja trabalhando por conta própria variante da tartaruga , mas ainda não está lá, em setembro de 2008.

Em seguida, treinar as pessoas-chave sobre como o uso de um sistema descentralizado afetará seu trabalho.

Por fim, a integração com o restante do sistema, como rastreadores de problemas, o sistema noturno de construção, o sistema de teste automatizado etc.

1
ddaa

o 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 restante da equipe ainda está usando o Subversion.

EDIT: Praticamente toda a ferramenta agora tem alguma maneira de interagir com o SVN, mas agora tenho uma experiência pessoal que git svn funciona extremamente bem. Uso-o há meses, com o mínimo de soluços.

1
Hank Gay

Há um bom vídeo de Linus Torvalds no git. Ele é o criador do Git, e é 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 (o Mercurial é considerado bom) e cvs/svn/perforce. Também há perguntas da audiência sobre a migração para o SCM distribuído.

Achei esse material esclarecedor e sou vendido para SCM distribuído. Mas, apesar dos esforços de Linus, minha escolha é Mercurial. O motivo é o 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 eu não ri. Além disso, o vídeo é ótimo se você é novo nos SCMs distribuídos e pensa em mudar do SVN.

http://www.youtube.com/watch?v=4XpnKHJAok8

1
k1udge

Os sistemas de controle de versão distribuído (DVCSs) resolvem problemas diferentes dos VCSs centralizados. Compará-los é como comparar martelos e chaves de fenda.

VCS centralizados os sistemas são projetados com a intenção de que haja uma única fonte verdadeira que é abençoada e, portanto, boa. Todos os desenvolvedores trabalham (fazem checkout) a partir dessa fonte e adicionam (confirmam) suas alterações, que depois se tornam abençoadas da mesma forma. 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.

Os sistemas VCS distribuídos são projetados com a intenção de que um repositório seja tão bom quanto qualquer outro, e que se mesclem de um repositório para outro sejam apenas outra forma de comunicação. Qualquer valor semântico de qual repositório deve ser confiável é imposto de fora pelo processo, não pelo próprio software.

A escolha real entre usar um tipo ou outro é organizacional - se o seu projeto ou organização deseja controle centralizado, um DVCS não é iniciante. Se você espera que seus desenvolvedores trabalhem em todo o país/mundo, sem conexões seguras de banda larga a um repositório central, o DVCS provavelmente é sua salvação. Se você precisar dos dois, está fsck'd.

0
Craig Trader