Melhores da InfoQ em 07: Sistemas de Controle de Versão Distribuído: Um Guia não tão rápido

Este artigo foi originalmente publicado em 07 de maio de 2007 e faz parte da coleção dos melhores artigos de 2007 publicados na InfoQ

Desde que Linus Torvalds apresentou na Google o git em Maio de 2007, a adoção e o interesse por Sistemas de Controle de Versão Distribuído têm crescido constantemente. Nós vamos fazer uma introdução ao conceito de Controle de Versão Distribuído, ver quando utilizá-los, porque ele pode melhor do que o que você está utilizando atualmente, e dar uma olhada em três opções no mercado: git, Mercurial e Bazaar.

O que?

Um Sistema de Controle de Versão (ou SCV) é responsável por manter o histórico de diversas revisões de uma mesma unidade de informação. Ele é comumente utilizado em desenvolvimento de software para gerenciar o código fonte de um projeto. O primeiro e histórico projeto SCV de escolha foi o CVS que foi iniciado em 1986. Desde então, muitos outros SCV tem aparecido cada um com suas vantagens específicas sobre o CVS: Subversion (2000), Perforce (1995), CVSNT (1998),  ...

Em Dezembro de 1999, para gerenciar os fontes principais do kernel, Linus escolheu o BitKeeper descrito como "a melhor ferramenta para o trabalho". Antes desta escolha Linus estava integrando cada patch manualmente. Enquanto todos os seus predecessores estavam trabalhando em um modelo Client-Server(Central), BitKeeper foi o primeiro SCV a permitir um verdadeiro sistema distribuído onde todo mundo é proprietário de suas próprias cópia mestre. Por conta de conflitos de licença, BitKeeper foi posteriormente abandonado para dar lugar ao git (Apr, 2005). Outros sistemas seguindo o mesmo modelo estão disponíveis: Mercurial (Abr, 2005), Bazaar (Mar, 2005), darcs (Nov, 2004), Monotone (Abr, 2003).

Por quê?

Ou uma pergunta mais precisa: Por que SCVs de Destaque (e notavelmente Subversion) não estão satisfazendo?
Diversos quesitos são atribuídos ao Subversion:

• Maior razão é que fazer um branching fácil, mas fazer um merging é algo doloroso (e um não funciona sem o outro). E parece que qualquer projeto conseqüente que você vai trabalhar, será necessário fazer uma ginástica com separações, dev, branchs de teste. Subversion não tem um Histórico de consciência sobre a capacidade de um merge, forçando os seus usuários a rastrear manualmente exatamente quais as revisões que tem sido feito o merge entre os branches, tornando esta operação suscetível a erros.
• Sem chances de propagar as mudanças para outro usuário (sem a submissão para o Servidor Central).
• Subversion falha ao fundir as alterações quando os arquivos ou diretórios são renomeados.
• A convenção trunk/tag/branches pode ser considerado um engano.
• Commits offline não são possíveis.
• Arquivos.svn poluem os diretórios locais.
• svn:external pode ser perigoso de se lidar.
• Desempenho

Os modernos SCVD resolveram estes problemas com sua própria implementação e pelo fato de que eles eram distribuídos. Mas como veremos na conclusão, Subversion ainda não desistiu.

Como?

Descentralização

Sistemas Distribuídos de Controle de Versão utilizam como solução a tecnologia P2P (peer-to-peer). Clientes podem se comunicar uns com os outros e manter seus próprios branches locais sem ter que passar por um Servidor Central/Repositório. Desta maneira a sincronização acontece entre os peers que decidem quais as mudanças que devem ser submetidas.

Isto resulta em algumas diferenças de peso e vantagens sobre um sistema centralizado:

• Não é canônica, uma cópia de referência do código base existe por padrão; somente cópias funcionais.
• Disconnected operations: Operações comuns como commits, visualização de histórico, diff, e reversão de mudanças são rápidas, porque não há necessidade de se comunicar com um servidor central. Mesmo que um servidor central pudesse existir (para estabilidade, referência ou backup de versão), se a Distribuição é muito utilizada ela não deveria ser consultada como em um schema CVCS.
• Cada cópia funcional é efetivamente um backup remoto do código base e histórico de alteração, fornecendo uma segurança natural contra a perda de dados.
• Branches experimentais – criar e destruir branches são operações simples e rápidas.
• Fácil colaboração entre os pares.

Para um introdução nas práticas de colaboração de SCVD, você deve ter dado uma olhada na Intro to Distributed Version Control (Illustrated) ou possivelmente Collaboration workflows.

Você deve estar ciente que existem algumas desvantagens ao optar por um SCVD, notavelmente em termos de complexidade; Esta visão descentralizada é muito diferente do mundo Centralizado e pode levar algum tempo para ser utilizado pelos desenvolvedores. Rastreamento por mudança ao invés de rastreamento de arquivo pode ser confuso mesmo se com muita força tornar possível teoricamente rastrear mudança de método por arquivo.

Quem?

A batalha já começou! Alguns dos Bons e dos Maus.

O bom e o mau essencialmente de uma compilação alterada(porque alguns antigos argumentos não são mais verdadeiros) de blogs e de minha experiência pessoal.
 Você deve ter notado que a lista de funcionalidades é muito pequena (ex: git possui mais de 150 comandos), e alguns itens podem ser mais críticos do que outros.

	git	Mercurial	Bzr
Projeto
Mantenedor	Junio C Hamano	Matt Mackall	Canonical Ltd. - Became GNU project
Modelo de Concorrência	Merge	Merge	Merge
Licença	GPL	GPL	GPL
Plataformas suportadas	POSIX, Windows, Mac OS X	Unix-like, Windows, Mac OS X	Unix-like, Windows, Mac OS X
Custo	Grátis	Grátis	Grátis
Maturidade
Versão	> 1.0 (1.5.5)	> 1.0 (1.0)	> 1.0 (1.3.1)
Início do Projeto	Abr, 2005	Abr, 2005	Mar, 2005
Implementação
SLOC (Sem fonte do Teste)
Contagem SLOC	130550	38172	79864
Suítes de Teste	~20% dos fontes dedicados para Testes	~25% dos fontes dedicados para Testes	~50% dos fontes dedicados para Testes
Modelo do Histórico	Snapshot	Changeset	Snapshot
Repo. Crescimento	O(patch)	O(patch)	O(patch)
Protocolos de Rede	HTTP, FTP, pacotes de email, customizado, ssh, rsync	HTTP, ssh, email	HTTP, SFTP, FTP, ssh, customizado, pacotes de email
Funcionalidades Básicas
Commits Atômicos
Renomear Arquivo	implícito
Renomear arquivo merge
Links simbólicos
Ganchos para Pré/pos-evento
Revisões assinadas			Parcial / Verificação Manual
Rastreamento de Merge
Conversões de fim de linha			Planejado (1.6)
Tags
Suporte Internacional		Planejado
Checkout parcial	Ao invés disto utilize os sub-módulos	Planejado	Planejado
Arquitetura / Modelo
Arquivo	Diretório .git único alto-nível	Diretório .hg único alto-nível	Diretório .bzr único alto-nível
Modelo		Modelo de ramos simples (um clone é um ramo)	Modelo de ramos simples (um clone é um ramo)
Especificidades do Repositório			Repositórios compartilhados para revisões compartilhadas entre os ramos. Supõe-se ser um Modelo de Armazenamento Melhor
Diretórios versionados
Submódulos	Suporte a submódulos via git-submodule	Suporte a Submódulo via Extensão Forest (como utilizado pelo OpenJDK)	Alternativa com Ferramentas de Terceiros ConfigManager
Commit por arquivo	Vai contra a arquitetura	Vai contra a arquitetura	Vai contra a arquitetura
Rebase / Queue	rebase	Mercurial Queues	Rebase plugin, Loom plugin (comp. with Quilt)
Acesso Web
	Nota: Repositório também pode ser compartilhado como somente–leitura via arquivos estáticos sobre HTTP.	Nota: Repositório também pode ser compartilhado como somente–leitura via arquivos estáticos sobre HTTP.	Não tão bom quanto os outros 2. Smart Server Rápido agora disponível.
	gitweb, wit, cgit	hgweb (rep simples), hgwebdir (rep multíplo)	webserve, trac, Loggerhead
Integração
Habilidade de Integração	git é mais aberto a scritps do que integração através de API (mesmo que existam algumas apis frontend como Ruby/Git)		API Rica
Migração	Boa. git-svn é também muito poderosa e fácil de incluir como um gateway bi-directional entre o Subversion e o Git, permitindo você utilizar Git sobre um repositório Subversion existente.	Boa. hgsvn não é arrojada quanto git-svn.	Boa cobertura, mas é lenta.
Integração com Rastreamento de Ocorrência	Plugin para Backend de Sistemas de Rastreamento disponível. Opção alternativa ao Bugzilla. Sem plugin para o JIRA.	Plugin para Backend de Sistemas de Rastreamento disponível. Opção alternativa ao Bugzilla. Sem plugin para o JIRA.	Plugin para Backend de Sistemas de Rastreamento disponível. Opção alternativa ao Bugzilla. Sem plugin para o JIRA.
Plugins IDE	Versões des. existentes: Idea, Eclipse, NetBeans	Versões des. existentes: Idea, Eclipse, NetBeans	Versões des. existentes: Idea, Eclipse. Falta: NetBeans
Plugins	Emacs / Vim / ...	Emacs / Vim / ...	Emacs / Vim / ...
Desempenho
	git historicamente tem sempre sido mais rápido que seus competidores		bzr historicamente tem sido o mais devagar dos 3.
Funcionalidades Avançadas
	Com mais de 150 binários é difícil não encontrar o comando matador que você sempre sonhou (mesmo se isto aumente a complexidade)
Complexidade
			Bzr tem a pretensão de esconder a complexidade mantendo uma Interface com o Usuário limpa enquanto se adapta a diferentes collaboration workflows e sua evolução no time.
Revisão Nomeada	Revisões no git são SHA-1 tornando-o menos amigável ao fazer uma diff entre duas revisões. Esta escolha foi feita para garantir a segurança e a integridade dos dados e também evitar colisão quando fundir com outros pares.	Nomeação simples	Revisão simples por nomeação de id r1, r2, etc...
Comandos	Familiar, com algumas coisas especifícas como o comando rename que difere de outros SCM (não pode ser alterado por conta de compatibilidade inversa). git é o SCM mais avançado em termos de comando mas se você adicionar todos os comandos possíveis e suas opções, você irá acabar com um grande número de possibilidades que é difícil de se dominiar. O fato que uma ferramenta como Easy Git exista, significa que Git pode ser considerada muito complexa.	Familiar (não muito longe do subversion)	Familiar
UserBase
	Grande base de usuários / Projetos numerosos (e grandes) rodando git e interesse em feedback do usuário	Grande base de usuários / Projetos numerosos (e grandes) rodando hg.	É o menor Market Share: Tirando os projetos Canônicos (Ubuntu, Launchpad), nenhum grande player esta utilizando ainda. Bazaar é ainda menos conhecido.
	Linux kernel, Cairo, Wine, X.Org, Rails, Rubinius, Compiz Fusion	Xine, OpenJDK, OpenSolaris, NetBeans, (Parte de) Mozilla	(Parte de) Ubuntu, Launchpad
Documentação	Boa documentação. Páginas centrais muito boas (com uma série de exemplos)	Boa documentação.	Boa documentação.
Plataformas
	Suporte fraco a Windows.	Multi Plataforma	Multi Plataforma
Pontos Positivos em Funcionalidades Adicionais
	git é aberto a scripting ao invés de plugabilidade o que tem seus pontos bons (facilidade de entrada através de script, de toda a maneira, todos os testes são feitos em script em lote). Bem ajustável para uma administração avançada: área de staging, objetos de oscilação, cabeçalhos detachados, plumbing vs porcelain, logs de referência. Branches locais são possíveis.	Renomeação Robusta..	Renomeação Robusta.. Suporte a checkouts lightweight (sem histórico). Bound branches. Branches locais também são possíveis. Patch Queue Manager (gerencia diversos branches, executando merges para desenvolvedores)
Alguns comandos / extensões muito legais	git-stash (ao ser interropido para um acerto de bug rápido em outro projeto), git-cherry-pick (para selecionar apenas commits únicos, ao invés de branches completos), git-rebase (para encaminhar a porta de seus commits locais. Mudanças em conjunto parecido com Mercurial Queues). git add -i (equivalente ao Mercurial RecordExtension). É difícil não encontrar o comando que você sempre sonhou.	RecordExtension (permite você escolher quais as partes das mudança em um diretório de trabalho que você gostaria de salvar). Hg Shelve Extension (o mesmo que o git-stash: para iterativamente selecionar as mudanças que serão set aside).	Shelf plugin (mesmo que o git-stash: quando interropido para um acerto de bug rápido em outro projeto, último release em Jan. 2007). bzr-dbus (para propagar ganchos e revisões).
Pontos Negativos em Funcionalidades Adicionais
	Renomear não tratado tão bom quanto bzr (Test Case). Configuração de HTTP estático somente leitura é um pouco obtuso (--bare e update-server-info). Tratamento de arquivos Unicode (UTF-16 encoded). Modelo de Armazenagem. Git armazena cada objeto novo criado como um arquivo separado que pode ser empacotado em um único arquivo delta comprimido entre cada um. Força fazer uma administração e fazer um empacotamento em um período regular. Mistura de C, Perl e script bash, o que torna muito menos óbvio para se comunicar com outros sistema durante a manutenção no mesmo conjunto de funcionalidades.	Renomear não tratado tão bom quanto bzr. [RESOLVIDO] Ramos locais não são possíveis, clone é utilizado como alternativa. Para evitar perca de espaço, Hg utiliza hardlinks, o que torna um problema durante um pull (e também sobre o Windows). Extensão Forest (submódulos) não nativo e não muito bem documentado.
Gui
Windows		TortoiseHg	Complicado. TortoiseBzr (não atualiza ou lança um projeto desde de Agosto de 2007, mas o projeto continua ativo). WildcatBZR.
Linux	gitk, git-gui, tig, ...	TortoiseHg, Hgtk, hgct	bzr-gtk, ...
Instalação
	Você vai precisar ter instalado o cygwin ou uma instalação alternativa do git como Git no MSys
Disponibilidade de Hospedagem Livre
	GitHub, gitorious	FreeHg	Launchpad

Existem algumas questões que ficaram em aberto, como o fato que os diretórios bzr são branches, e não conteiners branch como no git.
Também pelo fato de que o Mercurial está utilizando ferramentas externas para fazer as fusões é algo criticado pela Bzr. Isto não é mais verdade com o lançamento do Mercurial v1.0.
Você vai encontrar outras comparações negativas produzidas pela equipe Bazaar: Bazaar vs Git, Bazaar vs Mercurial e a associada resposta da Mercurial.

 

 

Algumas Estatísticas de uma Pesquisa feita pela Git em 2007

Você deve ter notado que na pesquisa, não tem a opção de escolher Ruby como uma linguagem proficiente. Deve ser interessante incluir Ruby na pesquisa de 2008.

É também engraçado ver que cerca de 1/3 das pessoas utilizam um SCV Distribuído (aqui como git) em colaboração com ... 0 ou 1 pessoa!

Guis

gitk no Linux	TortoiseHg no Windows	OliveGtk no Linux

As interfaces gráficas são muito semelhantes com preferência para a efetividade do gitk. TortoiseHg (com checagem de pasta ativado) foi realmente muito devagar com um repositório grande como o Mozilla.

Um olhada rápida e não-exaustiva em desempenho

Condições do teste

git continua liderando a batalha de desempenho, mas a Hg e a Bzr tem feito grandes mudanças no último ano.

Você deve ter notado que o Mercurial dobra o número de arquivos no seu repositório (o histórico é mantido por arquivo em .hg/store/data). O que não parece ser uma escolha para sistemas Windows rodando em NTFS.
É também interessante ver que o git toma uma grande vantagem do sistema na execução de comandos. Enquanto que a Hg e a Bzr não gastam uma grande parte do tempo em sistema, Git pode tomar cerca de 10-40% do tempo da cpu em chamadas ao sistema, o que levanta a questão de que como será o desempenho em sistemas Windows onde os desenvolvedores-git não possuem acesso em todas as opções de desempenho do sistema que eles possuem no Linux.
Single Merges e Merge Queues deveriam ser testados, esta é a parte chata dos testes comparativos.

Deveriam ser executados benchmarks no Windows como:

1. Mesmo se o seu servidor esta rodando em *nix, muitos desenvolvedores ainda possuem em seus trabalhos o ambiente Windows e o SCVD transferiu mais processamento para a máquina do desenvolvedor
2. Desempenho deve ser totalmente diferente em máquinas Windows.

Quando?

Estórias de quem tem experiência.

Eu tive a chance de estar com Kelly O'Hair da Sun na escolha do Hg para o OpenJDK.

Sebastien Auvray: Eu li as razões da migração do TeamWare para o Mercurial mas ainda ficou algumas questões em aberto. Vocês simplesmente seguem a escolha do OpenSolaris?

Kelly O'Hair: TDe certo modo sim, mas a escolha do OpenSolaris também trouxe para a Sun uma ampla cobertura para qualquer Software da Sun que os times tenham que converter. A análise do OpenSolaris foi muito completa e eles possuem os exatos requisitos que nós temos. Nós temos que converter para o OpenJDK, porque o TeamWare era inaceitável para um projeto de código aberto, e a resposta do Mercurial era muito óbvia para nós.

Ou você deu uma acalmada no torneio e tentou outros SCVD novamente (git, ...)?

Nós não fizemos uma reinvestigação detalhada, o que me pareceu ser uma falta de tempo. A única escolha possível na minha visão era o git, e uma vez que o git não estava dando prioridade para o Windows, que nós precisávamos. Novamente, a escolha foi óbvia.

Os relatórios do OpenSolaris surgiram em Abril de 2006, que são 2 anos atrás.

Entendi. Algumas coisas podem ter mudado, git melhorou, mas a bola estava rolando, e o Mercurial estava melhorando também.

Também você encontrou algum problema especifico na migração?

Permissões em arquivo e ownership podem ser um problema em compartilhar um repositório via sistema de arquivos NFS ou UFS, então nós finalmente configuramos um servidor para tratar os repositórios compartilhados, na melhor maneira. Que poderia ser fácil de fazer.
O outro problema é que utilizar ganchos para fazer um rollback ou um filtro impulsiona a criação de uma janela onde alguém poderia acidentalmente forçar as mudanças que serão retornadas, então você tem que utilizar um par de repositórios, um para inclusão e outro para retorno, com sincronização automática após os ganchos rodarem para efetuar a sincronia dos mesmos.
Utilizar forests também trás outro problema porqeu um forest push é somente um conjunto de pushes individuais, e se um push falha, tecnicamente você poderia efetuar o rollback de todos os outros pushes. Ninguém está fazendo isto, e somente pegando as suas chances. Se os repositórios no forest são razoavelmente independentes, este não é um problema real.

E no uso do dia-a-dia?

Isto nós iremos ver. Mudanças como esta é fácil para alguns, e difícil para outros. Depois de um tempo, Eu acho que a maioria das pessoas vão se adaptar e aprender a amar a ferramenta.
O conceito de "working set files" (precisando fazer um 'hg update') e tendo que fazer um merge nas mudanças que parecem não fazer merge com nada é confuso para algumas pessoas. Também, a idéia de que elas estão efetivando um conjunto de mudanças e não arquivos é algo que as pessoas acham um problema, "Porque eu não posso simplesmente puxar este arquivo?".

O que é melhor que o TeamWare?

Muito, mas muito mais rápido do que o TeamWare. Nossas equipes na China e na Rússia estão pesquisando por empacotamento completo porque elas não precisam manter espelhos de áreas de integração. Refreshes (pulls) são muito rápido sobre conexões limitadas.
O estado do repositório no Mercurial é bem-definida, diferente do TeamWare que permitia workspaces parciais, TeamWare era somente um saco frouxo de arquivos gerenciados manualmente (arquivos SCCS).
O conceito de conjunto de mudanças estava faltando no TeamWare, assim como o conceito do conhecido estado simples de todo o repositório (um id simples para um conjunto de mudanças).

Existe algo que você está sentindo falta no TeamWare?

Pessoas estão sentindo falta das notificações de email e o histórico de transações de volta de um arquivo/retirada de arquivo, e o conjunto de mudanças fornece muita informação deste tipo.
O que pode estar faltando é algum tipo de histórico de transação no repositório, mas novamente, os arquivos de email dos eventos do Mercurial poderiam fornecer isto.

A Hg esta se tornando a escolha de SCV da Sun inclusive para projetos internos? Ou a Sun está usando isto somente para projetos públicos que precisam ser abertos?

Tanto os projetos internos quanto externos estão sendo convertidos, aonde isto faz sentido.
Eu tenho visto um grande aumento no interesse de projetos internos que estão migrando para esta nova ferramenta.

Eu também estive com Pierre d'Herbemont da VLC para saber a sua opinião sobre o git.

Sebastien Auvray: Primeiramente, qual foi o sistema de controle de versão você estava utilizando antes de utilizar Git?

Pierre d'Herbemont: SVN e um espelho git-svn.

Quando você fez a migração?

Nós abrimos um espelho git da árvore do svn, para facilitar os projetos do Google Summer of Code no VLC. E lá estávamos nós. Então migramos totalmente para o git nos dias 1 e 2 de Março de 2008.

Porque você escolheu Git ao invés de outros competidores?

• Sobre o SVN: Git é rápido. Branch é barato. Atomic Commits. Rebasing no topo de uma outra árvore.
• Sobre outros sistemas distribuídos: Base de usuário comprovada (Linux Kernel). Eu tenho tido sucesso ao utilizá-lo enquanto trabalho no Wine. Git é sexy. E alguns desenvolvedores de base têm experiência com Git, onde ninguém possui com Mercurial e similares. Nada técnico lá.

Você encontrou qualquer problema especifico durante a migração? E no uso diário?

Nós encontramos alguns problemas com o Trac e o buildbot. O suporte deles para o Git é muito fraco, especialmente nas suas versões anteriores. Nós tivemos que fazer checkout do último trunk do Builbot. No caso do Trac nós estamos usando um plugin muito fraco para o Git. O Plugin para Git do Trac precisa do Trac 0.11. Mas o Trac 0.11 ainda não está estável e tem alguns problemas conhecidos de vazamento de memória que nos impede de mudar. Então basicamente nós estamos esperando que eles consertem isto...
Leve algum tempo para alguns committers se acostumarem com o Git. Mas após dois dias, tudo parece estar bem. E alguns iniciantes do Git começam realmente a gostar dele.

Então o quê ?

Escolher entre um SCV Distribuído e um SCV Centralizado está longe de ser fácil. SCVD irá mudar definitivamente a maneira como você trabalha e colabora. Subversion, um dos líderes em SCV Central, ainda não se alistou na batalha de funcionalidades e desempenho, e a versão 1.5 deveria vir com um forte compromisso. Ela pode contar com sua base de usuários existente e a simplicidade a seu favor (a um custo de alguma dor). Em um caso bem especifico como projetos que lidam com arquivos binários opacos, Subversion pode ser melhor que um SCVD, porque o uso do espaço no lado do cliente é constante. Também se você utilizar checkout parcial constantemente, o svn irá ter um desempenho melhor (mas quando utilizado massivamente ele apresenta problemas na configuração de seus módulos).

Uma vez feita a escolha de uma solução Central ou Distribuída, ainda assim será difícil comparar os competidores em suas áreas como implementações/comandos e no final o desempenho pode ser bem diferente. E não existe um benchmark real para as operações comuns.
Esta é uma batalha difícil, Bazaar perdeu muitos usuários novos e influentes (Mozilla, Solaris, OpenJDK) por conta de seu baixo desempenho inicial. Também deve ser dito que o website do Bazaar é muito orientado pelo Marketing: publicando diferenças não tão verdadeiras com seus concorrentes, ou publicando comparações benchmark com seus concorrentes somente sobre a eficiência de Espaço enquanto que não tem um benchmark de comparação de tempo de comandos básicos: diff, add, ...
Eu sinto que mesmo com os 3 projetos que iniciaram quase que ao mesmo tempo, bzr já passou por muitos problemas relacionados a desempenho e design no início tornando-o um pouco menos maduro que seus concorrentes atualmente.
Ainda um fenômeno inédito, como se algumas escolhas baseadas em linguagens utilizadas pela comunidade têm surgido: Desenvolvimentos relacionados ao Java / Sun parece tender mais para Mercurial enquanto que projetos relacionados a C / Linux / Ruby / Rails são atraídos mais pelo git.

Espero que este artigo tenha esclarecido o assunto e suas experiências e feedbacks são sempre bem vindos!

Créditos:
Pessoas que gentilmente aceitaram a minha entrevista: Kelly O'Hair, Pierre d'Herbemont.
Ian Clatworthy pela sua ajuda e sua reação em nossa conversão sobre o Repositório Hg Mozilla para o Bzr.
#git, #mercurial, #bzr em Freenode IRC, #mozilla em Mozilla IRC.
Foto de Atletismo por Antonio Juez

Citações aleatórias:
Linus Torvald: "Subversion foi o projeto mais pontual já iniciado". "Se você gosta de utilizar CVS, você deveria estar em um tipo de instituição mental ou algum outro lugar".
Mark Shuttleworth (Ubuntu / Canonical Ltd.):  "Merging é a chave da colaboração para o desenvolvedor de software."
Ian Clatworthy (Canonical / Bazaar): "Entre 2011-2012, Eu prevejo esta tecnologia sendo largamente adotada e muitas equipes vão pensar como foi que eles conseguiram um gerenciamento sem isto."
Assaf Arkin em Git forking for fun and profit originally: "Apache construiu uma grande infraestrutura ao redor do SVN, muitas lágrimas e suor rolaram para fazer isto acontecer, e no inicio eu senti como se nós estivéssemos evitando tudo aquilo. Mas conforme eu pensava a respeito disto, mais eu percebia que Git é mais social que o SVN, e é exatamente isto o que é a Apache."

[Artigo alterado em 12052008 de acordo com os comentários aqui e de Ian Clatworthy e reedit]:

• Os plugins Bzr e a Gui do Windows adicionados: rebase, ..., Wildcat BZR, ...
• Hg Shelve adicionado.
• SLOC para o Hg alterado (Doc HTML utilizado para ser contado, Eu mantenho a contribuição que é responsável pela presença do Lisp e Tcl/Tk).
• • O tamanho do Repositório para a alteração do git após efetuar comandos de repacotamento apropriado (git repack -a -f -d --window=100 --depth=100 até o tamanho se tornar constante) (Agradecimento a dhamma vicaya pelo comentário).

Desculpas:
darcs, Monotone não foi levado em consideração nesta comparação, já estava difícil consolidar toda esta informação e efetuar testes nestes 3 SCVD. Estranhamente, mesmo assim eles são o mais antigo SCVD em cena, o foco é mais nos SCVD que eu revisei aqui (o que não ajuda mudar o foco eu admito, mas os usuários/desenvolvedores darcs, Monotone são bem vindos para publicar comentários e propaganda aqui!).

Referências
A exaustiva página na Wikipedia sobre Git.
Página na Wikipedia sobre Controle de Revisão Distribuido.
Página na Wikipedia de comparação de Software de Controle de Revisão.

Controle de Versão Distribuído – Porque e Como por Ian Clatworthy, Canonical (Bazaar).
Introdução a Controle de Versão Distribuido (Ilustrado) por Kalid Azad.
Sistemas de Controle de Versão Distríbuido por Dave Dribin (que finalmente escolheu Mercurial).
Porque Controle de Versão Distribuído por Wincent Colaiuta.
Gerenciamento de Código Fonte para OpenSolaris. Histórico do Projeto SCM OpenSolaris (2005).
Questões sobre OpenJDK Mercurial por Kelly O'Hair, Sun.
Porque eu escolhi git por Aristotle Pagaltzis.
SCM Distribuído por Gnome crew.
Requisitos SCM FreeBSD.
Requisitos Open Office.
Requisitos SCV Mozilla.
Utilize Mercurial seu git! por Ian Dees.
Qual o SCVD pegou você (talvez) por Bill de hÓra.
As Diferenças Entre Mercurial e Git.
E todas as URLs referenciadas neste artigo.

Cheat Sheets:
Git Cheat Sheet
Mercurial Cheat Sheet
Bazaar Quick Start Card

Condições do Benchmark.
Cada comando foi executado 8 vezes (e o melhor e pior tempo foram descartados). Eles foram feitos localmente através do filesystem (outros protocolos de testes deveriam ser feitos mesmo se SCVD não são conectados a um servidor central, comunicações de rede quando mal implementadas podem ocasionar baixo desempenho do usuário).

Versões utilizadas foram:

• Mercurial 1.0 lançado em 2008-03-24 (com Issue 1050 patch para opção inotify Edgy)
• Git 1.5.5 lançado em 2008-04-08
• Bazaar 1.3.1 lançado em 2008-04-10

Repositório consiste em um snapshot de 12456 changesets (de um total de 20080303, 70853 revisões do Repositório hg), ~30000 arquivos do Repositório Mozilla (originalmente formatado hg e traduzido para um repositório git, agradecimento para hg-fast-export.sh para o git e hg-fast-export.sh acoplado com o plugin fast-import para bazaar).
Formatos de arquivo padrão foram utilizados e o tamanho do repositório git continuou o mesmo executando git-gc (o que pode ser considerado normal para um repositório migrado recentemente). Um arquivo foi modificado (dom/src/base/nsDOMClassInfo.cpp) exatamente como um teste de benchmark feito pela Jst 1 ano e meio atrás..

Sobre o Author

Sébastien Auvray é um designer de software sênior e entusiasta de tecnologia. Após ser forçado a utilizar CVS, svn agora ele tem que sofrer com o uso diário de Perforce no trabalho. Sébastien é também um dos editores Ruby da InfoQ.