O que as pessoas aqui veem como pontos fortes e fracos do Git, Mercurial e Bazaar?
Ao considerar cada um deles entre si e em relação aos sistemas de controle de versão como SVN e Perforce, quais questões devem ser consideradas?
Ao planejar uma migração de SVN para um desses sistemas de controle de versão distribuídos, quais fatores você consideraria?
Respostas:
Git é muito rápido, escala 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 é bem um cidadão de primeira classe. Git expõe hashes como números de versão para os usuários; isso fornece garantias (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 incômodo para o usuário. 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 rastreia os diretórios. Outro problema com o git é que 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 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 raso, mas atualmente não é bem dimensionado com o comprimento do histórico) e é fácil de aprender para aqueles familiarizados com as interfaces de linha de comando de SCMs tradicionais (CVS, SVN, etc). O Win32 é considerado um alvo de primeira classe por sua equipe de desenvolvimento. Ele tem uma arquitetura que pode ser conectada a diferentes componentes e substitui seu formato de armazenamento com frequência; isso permite que eles introduzam novos recursos (como melhor suporte para integração com sistemas de controle de revisão baseados em conceitos diferentes) e melhorem o desempenho. A equipe do Bazaar considera o rastreamento de diretório e renomeação de funcionalidade de primeira classe. Enquanto identificadores de id de revisão globalmente únicos estão disponíveis para todas as revisões, revisões de árvore local (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 referido pela rede quando necessário; no momento, isso é único entre os DSCMs.
Ambos têm alguma forma de integração SVN disponível; entretanto, bzr-svn é consideravelmente mais capaz do que git-svn, em grande parte devido às revisões de formato de backend 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 polida; Eu recomendo fortemente seu uso ao invés do git-svn quando o orçamento e as restrições de licenciamento permitir].
Não usei o Mercurial extensivamente e, portanto, não posso comentar sobre ele em detalhes - exceto para observar que, como o Git, tem endereçamento 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 do que qualquer outro DSCM, exceto para 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 sua plataforma cruzada superior e suporte IDE, o Mercurial pode ser atraente para equipes com um número significativo de membros centrados em win32 ou ligados a IDE.
Uma preocupação na migração do SVN é que as interfaces GUI 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 faz uso intenso de automação de script de pré-confirmação com SVN (ou seja, exigindo que os testes de unidade passem antes que uma confirmação possa prosseguir), provavelmente desejará usar uma ferramenta semelhante ao PQM para automatizar solicitações de mesclagem para seus ramos compartilhados.
SVK é um DSCM que usa Subversion como seu 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 principal (mesmo Darcs) e deve ser evitado para 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 uma biblioteca incorporada; outras partes da organização do meu empregador usam fortemente o Mercurial. Em uma vida anterior, criei uma grande automação em torno do SVN; antes disso tenho experiência com GNU Arch, BitKeeper, CVS e outros. Git foi bastante desconcertante no início - parecia GNU Arch, visto que era um ambiente com muitos conceitos, em oposição a kits de ferramentas construídos para se conformar com a escolha de fluxo de trabalho do usuário - mas desde então fiquei bastante confortável com isto].
Steve Streeting do projeto Ogre 3D acaba de (28/09/2009) publicou um post no blog sobre este tópico onde ele faz uma comparação excelente e equilibrada de Git, Mercurial e Bazaar .
No final, ele encontra pontos fortes e fracos com os três e nenhum vencedor claro. No lado positivo, ele oferece uma ótima tabela para ajudá-lo a decidir qual escolher.
É uma leitura curta e eu recomendo.
O que as pessoas aqui veem como pontos fortes e fracos do Git, Mercurial e Bazaar?
Na minha opinião, o ponto forte do Git é seu design básico limpo e um conjunto muito rico de recursos. Acho que também tem o melhor suporte para repositórios de vários ramos e gerenciamento de fluxos de trabalho com muitos ramos. É muito rápido e tem um repositório pequeno.
Possui alguns recursos que são úteis, mas requerem algum esforço para serem usados. Isso inclui ara (índice) intermediário visível entre a área de trabalho e o banco de dados do repositório, que permite uma melhor resolução de mesclagem em casos mais complicados, comutação incremental e comutação com árvore suja; detectar renomeações e cópias usando heurística de similaridade em vez de rastreá-los usando algum tipo de id de arquivo, o que funciona bem e permite a culpa (anotar) que pode seguir o movimento do código entre os arquivos e não apenas renomeações no atacado.
Uma de suas desvantagens é que o suporte do MS Windows fica para trás e não está completo. Outra desvantagem percebida é que não é tão bem documentado como, por exemplo, o Mercurial e é menos amigável do que a concorrência, mas muda.
Na minha opinião, a força do Mercurial está em seu bom desempenho e pequeno tamanho do repositório, em seu bom suporte a MS Windows.
A principal desvantagem é, na minha opinião, o fato de que branches locais (vários branches em um único repositório) ainda são cidadãos de segunda classe, e de forma estranha e complicada implementa tags. Além disso, a maneira como ele lida com renomeações de arquivo era subótima (mas isso 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 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 grandes repositórios 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 (você pode configurá-lo para compartilhar dados, no entanto) , e conceitos centralizados (mas isso também pelo que ouvi mudanças).
Git é escrito em C, scripts de shell e Perl, e pode ser usado em scripts; 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 aos 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 sistemas de controle de versão centralizados . Git, Mercurial, Bazaar (e também Darcs, Monotone e BitKeeper) são sistemas de controle de versão distribuídos . Os sistemas de controle de versão distribuída permitem uma gama muito mais ampla 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 com muitas ramificações. Você não precisa confiar em pessoas com acesso de commit para obter contribuições delas de maneira fácil.
Ao planejar uma migração de SVN para um desses sistemas de controle de versão distribuídos, quais fatores você consideraria?
Um dos fatores que você pode querer considerar é o suporte para retração com SVN; Git tem git-svn, Bazaar tem bzr-svn e Mercurial tem extensão hgsubversion.
Isenção de responsabilidade: eu sou um usuário Git e um pequeno contribuidor, e assisto (e participo) da lista de e-mails do git. Eu conheço Mercurial e Bazaar apenas por sua documentação, várias discussões no IRC e listas de e-mail, e postagens de blog e artigos comparando vários sistemas de controle de versão (alguns dos quais estão listados na página GitComparison no Git Wiki).
InfoQ tem uma boa comparação .
Mercurial e Bazaar se parecem muito na superfície. Ambos fornecem controle básico de versão distribuída, como no commit offline e mesclagem de vários branches, são ambos escritos em python e são mais lentos que 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 do que Mercurial e 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 commit do Git são incomparáveis. No entanto, é também o mais complicado e o mais 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 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, os desenvolvedores Python estão mais interessados em usar o Mercurial do que no Bazaar ou Git.
- O Mercurial é escrito em Python, o que é congruente com a tendência 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 por um tempo, do qual 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 o Git, que gosto muito, pois a versão 1.6 o tornou muito mais semelhante a 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:
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 que levaria muito tempo para 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, então até mesmo entender as diferenças requer algum conhecimento bastante esotérico.
Provavelmente, você obterá respostas muito melhores se puder quebrar 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ê deve tentar usar os dois e decidir o que é mais adequado para você.
O que as pessoas aqui veem como pontos fortes e fracos do Git, Mercurial e Bazaar?
Esta é uma questão muito aberta, beirando o flamebait.
Git é mais rápido, mas todos os três são rápidos o suficiente. O Bazaar é o mais flexível (tem 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 Bazaar.
Ao considerar cada um deles entre si e em relação aos sistemas de controle de versão como SVN e Perforce, quais questões devem ser consideradas?
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 livres como se expressassem .
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 de SVN para um desses sistemas de controle de versão distribuídos, quais fatores você consideraria?
Em primeiro lugar, falta de um bom substituto para o TortoiseSVN. Embora o Bazaar esteja trabalhando em sua própria variante do Tortoise , ele 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 resto do sistema, como rastreadores de problemas, o sistema de compilação noturna, o sistema de teste automatizado, etc.
Seu maior problema será que esses são SCMs distribuídos 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 está usando o Subversion.
EDIT: Praticamente todas as ferramentas agora têm alguma forma de interagir com o SVN, mas agora tenho uma experiência pessoal que git svnfunciona extremamente bem. Estou usando há meses, com o mínimo de soluços.
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 do que os centralizados. Existem 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 sou vendido para um SCM distribuído. Mas, apesar dos esforços de Linus, minha escolha é inconstante. O motivo é bitbucket.org, achei melhor (mais generoso) do que github.
Preciso deixar aqui um aviso: 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 pensa em mudar de SVN.
Os sistemas de controle de versão distribuída (DVCSs) resolvem problemas diferentes dos VCSs centralizados. Compará-los é como comparar martelos e chaves de fenda.
Os sistemas VCS centralizados são projetados com a intenção de que haja 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 igualmente abençoadas. 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 as mesclagens de um repositório a 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, não pelo próprio software.
A escolha real entre usar um tipo ou outro é organizacional - se 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 de banda larga seguras a um repositório central, então o DVCS é provavelmente a sua salvação. Se você precisar de ambos, está fsck'd.