BTW, gostaria de ver a porcentagem de uso de diferentes sistemas DVCS.
sergiol
Respostas:
145
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].
Ei. Só quero que você saiba que o cscvs ainda está sendo usado para executar importações de código do Launchpad e eu tive a versão Canonical lançada quando trabalhei lá.
ddaa
19
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.
@gavenkoa, bazaar é intuitivo para quem vem do SVN. Se você está vindo do git, então tem um modelo mental que está mais próximo dos fundamentos do bazar, mas muito, muito longe de sua interface. (... ter uma camada tão espessa de abstração entre os fundamentos e a interface é o que torna possível para o bzr ser amigável para pessoas familiarizadas com o modelo SVN).
Charles Duffy,
2
@CharlesDuffy Mercurial também tem nomes intuitivos para comandos e não mortos (o desenvolvimento do Bazaar foi paralisado há 2 anos e a Canonical o rejeitou, sim, Git + github ganham o jogo DVCS ). Eu nunca entendi o esquema de nomenclatura git, então pessoalmente prefiro HG. É muito difícil lutar com caras amantes do Git ((
gavenkoa
@gavenkoa, os nomes dos comandos básicos do bzr correspondem aos SVNs, então, novamente, não vejo o que poderia ser não intuitivo sobre eles (para um usuário SVN). Sim, claro, o desenvolvimento morreu. Não estou argumentando que o bzr é prático para uso - apenas que a crítica específica feita foi incorreta.
Charles Duffy,
1
@gavenkoa, ... Eu também sou conhecido por defender aspectos do BitKeeper, apesar de ter um grande rancor contra os desenvolvedores / proprietários do software (sua base documentada publicamente ... embora Larry tenha me ligado uma vez para descrever o fim do que aconteceu, e admito que agora entendo os dois lados). Só porque eu defendo um SCM não significa que realmente recomendo que as pessoas o usem. :)
Charles Duffy,
15
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).
Para sua informação - bzr-svn é muito mais capaz do que git-svn, no sentido de que é bidirecional: posso executar "bzr branch svn: // ..." e, posteriormente, mesclar minhas alterações de volta ao servidor svn - onde elas será armazenado com metadados que outros clientes bzr reconhecerão.
Charles Duffy
2
Sou um hg dev e estive olhando um pouco para o design do Git. Fico feliz em ver que ambos tratam o histórico da única maneira sensata para uma configuração distribuída: em um alto nível eles são ambos um gráfico acíclico de commits e em um nível inferior eles permitem que os commits referenciem manifestos que fazem referência aos arquivos (blobs no Git ) Mercurial tem branches anônimos (que, AFAIK não existe no Git), ele tem branches marcados (muito parecidos com branches do Git, mas sem push / pull) e ele tem branches (o nome do branch é registrado no commit - aqueles também não são) no Git).
Esta resposta seria melhorada por um resumo da referida comparação.
lindes
7
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.
O Mercurial está realmente no mesmo nível do Git. O desempenho não é grande diferença. Mas o bazar é muuuuito mais lento que o Mercurial e o Git.
Joshua Partogi
@jpartogi - Os números de desempenho do Bazaar têm melhorado muito mais rápido do que seus concorrentes, então eu seria cauteloso ao fazer esse tipo de afirmação - particularmente com a refatoração de armazenamento que está disponível como prévia nas versões atuais e programada para se tornar padrão na 2.0.
Charles Duffy
7
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.
Mozilla e Sun também usam Mercurial pelo mesmo motivo.
Joshua Partogi
2
O bzr também é escrito em Python, é de fato mais lento do que o hg, mas por uma margem que se estreita rapidamente - e como um usuário do Bazaar e do Mercurial, eu discordo fortemente da afirmação "mais fácil de aprender".
Charles Duffy
1
Todos eles ainda estão evoluindo. Decidi pelo Bazaar para um DCVS para começar porque achei que era mais fácil (mas não muito nele) e o Launchpad.net. Foi bem lento. Git no OSX parece bom, mas o suporte ao Windows é ruim. Como os projetos Python e Google agora o adotaram, e por causa do TortoiseHg, estou trocando para o Mercurial. Acho que o Mercurial está ganhando massa crítica em relação ao Bazaar e vai lá. E Git fará seu próprio trabalho, sempre focado em Posix, então nunca será verdadeiramente dominante.
Nick
5
A Sun fez uma avaliação de git , Mercurial e Bazaar como candidatos para substituir o Sun Teamware VCS para a base de código Solaris. Achei muito interessante.
essas avaliações estão um pouco desatualizadas, as versões mais recentes mudaram algumas das desvantagens aqui mencionadas.
hayalci
2
Uma coisa que falta muito importante no bazar é o cp. Você não pode ter vários arquivos compartilhando o mesmo histórico, como você tem 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.
Isso está faltando por design - cp não pode ser adicionado sem criar uma série de casos onde é difícil ou impossível ter certeza de fazer a coisa certa ao mesclar entre um branch onde uma cópia e mudanças aconteceram e outro branch com alterações, mas nenhuma cópia .
Charles Duffy
Claro, mas é algo a ter em conta - e seria um recurso muito útil para muitos casos de uso (como dividir um arquivo em dois diferentes e preservar o histórico para ambos). Na verdade, é a única razão pela qual eu ainda uso o subversion para certos projetos - onde a fusão é irrelevante, mas a cópia não é
Davide
2
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:
Git tem a comunidade mais vibrante e é comum ver artigos sobre Git
O 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.
Você quer dizer "agora" muito feliz, em oposição a "não" muito feliz, certo?
Charles Duffy
Obrigado Charles! Um lapso freudiano aqui :)
sh1mmer
1
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.
O Mercurial é tão fácil quanto o Bazaar, relativamente rápido em comparação com o git e tem um bom suporte no Bitbucket. Então, o que mais você poderia perguntar?
Joshua Partogi
1
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.
Para o registro, a página atual afirma: "Desde a versão 1.6 do Bazaar, o TortoiseBZR está incluído no instalador oficial", então parece ter amadurecido.
PhiLho
1
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.
Existem diferenças muito significativas entre CVS, SVN e VisualSourceSafe (para citar apenas 3) que têm um sério impacto em sua utilidade - e não são apenas problemas de fluxo de trabalho e / ou integração.
Murph
Usei todos os três deles e, tecnicamente, você está correto, mas de uma perspectiva de alto nível, minha resposta também é válida. O controle de versão para mais de um desenvolvedor é uma ferramenta organizacional; contanto que a ferramenta atenda às necessidades da organização, isso é tudo que importa no longo prazo.
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].
fonte
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.
fonte
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.
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.
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).
fonte
InfoQ tem uma boa comparação .
fonte
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.
fonte
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:
fonte
A Sun fez uma avaliação de git , Mercurial e Bazaar como candidatos para substituir o Sun Teamware VCS para a base de código Solaris. Achei muito interessante.
fonte
Uma coisa que falta muito importante no bazar é o cp. Você não pode ter vários arquivos compartilhando o mesmo histórico, como você tem 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.
fonte
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.
fonte
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.
fonte
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ê.
fonte
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.
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.
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.
fonte
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.
fonte
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.fonte
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.
http://www.youtube.com/watch?v=4XpnKHJAok8
fonte
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.
fonte