Este artigo já estava na minha todo-list já faz algum tempo, visto que os projetos em que trabalho já estão utilizando controle de versão descentralizado desde o início de 2008, mas agora depois de reler o artigo do Akita resolvi tirar esta pendência do meu to-do.
Por quê mudar para um controle descentralizado?
Bom já faz algum tempo que o controle de versão descentralizado está em alta em detrimento às opções que acredito serem mais utilizadas ainda hoje que são o SVN e o CVS. Quero dizer que o SVN e outras ferramentas centralizadas que utilizamos solucionaram o problema para nossa equipe durante muito tempo, No início quando programava em Delphi era utilizado um controle de de versão integrado a IDE chamado FreeVCS, que depois se tornou o JediVCS, resolvia o problema e o workflow utilizado era o de dar o CheckOut do arquivo a trabalhar (isso travava o arquivo no servidor e ninguém poderia alterá-lo) fazia-se as alterações necessárias em em seguida executava o CheckIn aplicando as alterações no repositório principal e liberando o arquivo para outros desenvolvedores, Um bom começo.
Um dia precisamos tratar branches e coisas do gênero, e surpresa o nosso amigo Jedi não suportava (acho que ainda não suporta), então a solução foi migrar. O escolhido para a migração foi o SVN, provavelmente os descentralizados já existiam, mas os na época qualquer pesquisa no Google sobre controle de versão devolvia toneladas de links para SVN. Tudo bem até ai, e como nenhum usuário de Windows gosta de usar o promt de comando acabei desenvolvendo um plugin para o Delphi que se comportava mais ou menos como o JediVCS mas com o SVN, daí em diante muitos projetos no SVN, em seguida migração de plataforma (Hoje utilizamos Linux embora os servidores já fossem Linux desde a migração para SVN). Mas às vezes era necessário levar parte da equipe para outro local (longe dos servidores internos), geralmente no cliente, onde eram feitas alterações no sistema. A solução não era muito prática, fazer o setup de um servidor SVN temporário para o desenvolvimento no local, depois pegar as revisões gerar um diff gigante das alterações e aplicar no repositório na empresa e resolver os conflitos com o que os desenvolvedores internos fizeram neste meio tempo. Quando um dia decidi que precisávamos de um controle de versão onde pudéssemos realizar algum trabalho desconectados do servidor interno e depois fosse menos trabalhoso juntar tudo novamente, além de, manter o histórico de cada um dos commits realizados.
Foi então que comecei a minha jornada em busca de um controle de versão distribuído* é claro que fosse OpenSource, a lista é grande, onde podemos citar alguns como Codeville, Darcs, Monotone, Mercurial, Git e Bazaar além de mais alguns que não cheguei nem a pesquisar. Desta lista poucos minutos de pesquisa me levaram a considerar apenas o Bazaar o Git e o Mercurial, e fazendo alguns testes percebi que todos poderiam satisfazer minhas necessidades usando Linux. Então vamos às necessidades:
- Ser multiplataforma, afinal ainda tenho ainda hoje código fonte para manter em Delphi :(.
- Possuir um modo de converter meus repositórios Subversion.
- Ter uma curva de aprendizado pequena em relação ao SVN.
- Tivesse como integrar com alguma ferramenta estilo Trac ou Redmine.
Primeira Tentativa: Mercurial
No primeiro quesito, à primeira vista ele se encaixa pois grande parte do seu código é escrito em Python, tem um instalador para Windows (que não me parece ser oficial). Mas esperem, eu sou fissurado por usar a Ultima versão da ferramenta que o Desenvolvedor disse que está estável, logo, não me interessa muito usar o instalador da versão Windows, que na época dos meus testes instalava algo em torno de 0.9 e a versão oficial já era a 1.0 (Março de 2008). Bom escrito em Python pensei eu, vamos ao easy_install……
c:\easy_install mercurial...... bam!
Erro, claro, não havia um compilador C. vamos lá instalei toda a MingW, MSyS etc, easy_install denovo, compilou, instalou beleza!.Não, o comando hg não funciona, bom vamos la, eu crio um hg.bat que chama o script do mercurial, jogo na pasta Scripts e tudo certo…. Também não, mais algumas tentativas depois consegui rodar o hg e ter um resultado. Bom, pra mim morreu aqui, não quero uma coisa que cada vez que tenho que instalar tenha que… Instalar um compilador C que os meus desenvolvedores Windows nao vão ter na máquina e fazer mais um monte de gambiarras pra ter versão “featured” do sistema. Enfim o Mercurial possui uma ferramenta de conversão de repositórios SVN e outros e tem integração com algumas ferramentas, inclusive o Netbeans, que por sinal, Surpresa!, também não funciona no Windows mesmo tenho o Mercurial funcionando no promt instalado via easy_install, acho que só funciona se for via installer mesmo. A curva de aprendizado dele é bem grande se formos levar em conta que sempre temos usuáriosbitolados, ei, eu disse bitolados?, eu quis dizer “acostumados” com o SVN e seu set de comandos, mal e porcamente.
Já é um caos fazer as pessoas entenderem o conceito de controle distribuído.
Segunda Tentativa: Bazaar
Bom eu já estava desanimado mas tinha que continuar, Uma olhada no site, cheio de tutoriais e extensiva documentação, Boa! documentação parece pelo menos ser bem melhor que a do Mercurial, embora eu tenha encontrado muitos posts em blogs dizendo o contrário, então só posso supor que, se a documentação do Mercurial é boa, ela está bem escondida em algum lugar do Wiki deles, bom blames à parte, Já vi um instalador para Windows e… hum, vamos tentar do velho e bom modo…
c:\easy_install bazaar ...
E instalou sem nenhum erro… bom eu já tinha um compilador C instalado, seria por causa disso? Vamos desinstalar tudo e ver o que acontece. Após remover todas as parafernalhas do MingW e Cia Ltda e remover o egg** do Bazaar e tentar novamente… vamos lá…
c:\easy_install bazaar
E funcionou novamente!, bom o Bazar é completamente escrito em Python, o que explica a tamanha portabilidade. o comando bzr já saiu funcionando, e, por curiosidade vou até a pasta Scripts, e… lá está um arquivo bzr.bat mais ou menos como o meu workarround, porém, out-of-the-box. Tudo funcionando agora vamos ver uma ferramenta de conversão, na época utilizei o svn2bzr, que funcionou perfeitamente, mas não importou as tags e relações dos branches, mas a história Linear do Subversion veio funcionando 100%. Hoje tem o bzr-svn que é um plugin para trabalhar diretamente com repositórios svn utilizando o bzr, e esta sim importa as tags referências de branches, merges etc. Ok curva de Aprendizado… uma estudada na documentação e, show de bola, não só tem praticamente todos os comanos similares aos do SVN, como também permite trabalhar com vários Workflows, inclusive o modelo Centralizado igual ao SVN. Então uma pequena busca por integração com os issue trackers, e, existiam plugins para bugzilla, Trac, Redmine e outros. eu na época estava utilizando o Trac e estava pensando em migrar para o Redmine, boa oportunidade para dar uma testada nele… Instalei testei e funcionou 100%, inclusive com aqueles comandos de commit, do tipo: bzr commit -m “This commit fixes #772” para fechar o ticket numero 772. Perfeito.
Terceira Tentativa: Git
Já mais contente mas minha jornada ainda não estava finalizada, uma pequena pesquisada e achei um instalador do Git para windows, que não era exatamente a última versão, mas vamos dar um desconto, o Git é escrito em uma carrada de linguagens, uma parte em C outra em Perl outra em Shell Script e por ai vai, fazer isso integrar, e pior, Funcionar no Windows não deve ser das mais fáceis tarefas. Bem, feita a instalação, ele instalou um shell bem similar ao do Cygwin que praticamente dá a leve sençassão de estar em um terminal Linux, e mais algumas ferramentas, ele utiliza o MingW, MSyS e outras bibliotecas para fazer a mágica de funcionar no Windows, Instalado fazer alguns testes, e gostei, segundo o próprio instalador e documentação afirma, alguns comandos não estão disponíveis pois falta ambiente***, mas para o uso diário geral show de bola. A curva de aprendizado….. hummm um pouco pior que a do Mercurial, porque por exemplo o comando checkout parece não ter nada haver com o que o SVN faz, embora para mim faça sentido, em fim, quando eu falei que era possível trocar de branch dentro da mesma cópia de trabalho com apenas um comando, ninguém entendeu nada, afinal totalmente fora deste planeta SVN. Continuando a conversão dos repositórios SVN também funcionou lindamente (bastante similar ao que hoje é o bzr-svn do Bazaar), e Integrou bonitinho com o Redmine, com uns pequenos probleminhas que não me recordo, mas, bastante usável.
Bom vejamos minha tabela de pontuação:
+----------+----------+-----------+----------+------------+ | |Multiplat |SVN/Import | CurvaApr | Integracao | +----------+----------+-----------+----------+------------+ |Mercurial | 5 | ?? | 7 | ?? | +----------+----------+-----------+----------+------------+ |Bazaar | 10 | 9 | 10 | 10 | +----------+----------+-----------+----------+------------+ |Git | 9 | 10 | 5 | 9 | +----------+----------+-----------+----------+------------+
Bom tinhamos um vencedor, agora vamos fazer algumas pesquisas e comparativos para ver o que o Povo acha… e, Blames**** está cheio!
bom na opinião geral e também por mim constatada, o Git é o Mais Rápido para a Maioria das operações, Seguido do Mercurial e por Último o Bazaar, mas a maioria desses artigos falam em 100000 arquivos de 10000 linhas cada um, e fazem um monte de testes com 10000 revisões etc… claro algo escrito basicamente em C seria obviamente mais rápido que algo escrito parcialmente em C e Python do que algo Totalmente em Python, mas nos meus testes de uso geral, a diferença de performance é praticamente irrisória, mesmo trabalhando com árvores grandes.
Agora vamos ver quem utiliza cada uma destas ferramentas. Bem o Git foi contruído pelo Linus para manter o Kernel do Linux, e fora o Kernel temos outros projetos grandes utilizando. Já o Mercurial tem o pessoal da OpenJDK do Netbeans entre outros projetos Java***** . O Bazaar quem principalmente usa é a Canonical para manter grande parte do Ubuntu, li em algum lugar (quando eu lembrar posto no final do artigo) que vai utilizar só o Bazaar para manter o Ubuntu, afinal de contas a Canonical é a mantenedora do próprio Bazaar, além dela alguns outros projetos grandes como o MySQL também utilizam.
Outras ferramentas que podem ser citada são os hostings Free que cada uma das ferramentas possui.
O Mercurial tem o FreeHg, que não cheguei a testar mas parece-me que é totalmente gratuíto e deve ser destinado a projetos OpenSource.
O Git tem o Gitorious e o mais recente Github, este último bastante utilizado por toda a comunidade Ruby On Rails, desde que o Próprio Rails foi hospedado lá, além de o próprio Github ser desenvolvido em Rails. é uma Pena que o Github não tenha um gerenciamento de bugs (Bug Tracker) integrado a ele, e a opção que foi adotada inclusive pelo Rails o Lighthouse, eu particularmente não me agradei, sinceramente eu preferia o Trac ou o Próprio Redmine que também é Feito em Rails.
o Bazaar tem o Launchpad, que é totalmente gratuíto, destinado a projetos Opensource, possui um ótimo Issue Tracker integrado e mais um monte de coisas legais como os Blueprints e sistema para auxílio a internacionalização, é uma Excelente ferramenta, que na minha opinião melhor de todas aqui citadas, porém eu mesmo acho ele um pouco lento às vezes se comparado com o Github. Mas se formos levar em conta que o Github tem (no momento da escrita deste artigo) um limite de 100Mb por conta de usuário para projetos Pessoais/Públicos (Provavelmente isso deve poder ser negociado com o Pessoal do Github) Launchpad continua melhor, pois não possui limite, entretanto eu realmente gostaria que o pessoal da Canonical criasse a possibilidade de ter Contas Premium para projetos privados no Launchpad (que eu nunca vi mas pode até ser que exista, pois o launchpad em si não é OpenSource, embora partes dele sejam).
Final da história
Meu escolhido foi o Bazaar. Se eu já utilizasse apenas Linux e não tivesse mais desenvolvedores para ter que botar na cabeça todos os comandos, talvez eu tivesse optado pelo Git, embora hoje em dia depois de utilizar os dois no dia a dia acho o Bazaar realmente melhor que o Git, além do mais o Bazaar vem evoluindo rapidamente inclusive no quesito da performance que seria o seu ponto mais fraco. Em todo caso se as coisas um dia ficarem realmente lentas eu sempre terei a opção de migrar para o Git.
Hoje em dia eu particularmente utilizo o Git com bastante frequência assim como o Carlos, e assim provavelmente vamos continuar fazendo, quando se tratar de algo relacionado ao Ruby On Rails, em contrapartida nossos projetos da Empresa e pessoais, além de outros tipos de controle de versão de documentos e arquivos binários eu vou continuar utilizando o Bazaar.
Em breve estarei postando um how to, bastante sem criatividade pois pretendo refazer o artigo do Akita utilizando o Bazaar para exemplificar o uso, semelhanças e diferenças, além de mostrar que é possível trabalhar com o Bazaar em um modelo bastante aproximado, senão idêntico ao Git.
Todos os testes foram realizados em aproximadamente umas 3 semanas, não foram apenas testes de 5 minutos em cada opção de ferramenta.
Tudo que eu escrevi aqui está diretamente relacionado ao meu cenário de trabalho e experiências, provavelmente para outros cenários e pontos de vista uma das outras ferramentas citadas ou mesmo não citadas se encaixam melhor.
* Veja mais sobre controle de versão distribuído neste link (Em Inglês) e não deixe de assistir o vídeo.
** Os pacotes em Python são chamados de Eggs, seriam equivalentes aos Gems do Ruby ou mesmo aos pacotes Deb ou RPM do linux.
*** O Ambiente Windows não é preparado para desenvolvedores
**** Conversa sem sentido onde dois ou mais grupos que não tem o que fazer, discutem incansávelmente para provar que sua ferramenta é melhor que a do outro
***** Grande Ironia, Um dos maiores causadores de Blames que eu já vi foram comparativos entre Java e Python, e os Javeiros Inteligentes passam a usar uma ferramenta em Python… já os outros…. devem estar chorando.
Agile on Rails 