Perdõem a falta de objetividade no título, mas eu adorei esta decisão dos core developers da linguagem Python: entre os principais sistemas de controle de versão distribuídos, o Guido van Rossum optou pelo Mercurial, também conhecido como Hg, seu símbolo na tabela periódica.
No primeiro dia da conferência o Brett Cannon (perfil no Ohloh) fez uma palestra relâmpago explicando que os desenvolvedores do Python haviam decidido migrar do sistema de controle de versão atual, o Subversion, para um DVCS (sistema distribuído de controle de versões) e que ultimamente três sistemas tinham sido avaliados: Bazaar, Mercurial e Git.
Na mesma palestra-relâmpago, Brett disse que o Git havia sido descartado por ser o menos popular entre os principais desenvolvedores da linguagem Python e por não ser adequadamente suportado no Windows. Também pesou, mas não foi decisivo, o fato de que o Mercurial e o Bazaar são escritos em Python com partes em C, mas o Git é praticamente C puro com alguma coisa escrita em Perl. O vídeo da primeira sessão de palestras relâmpago, incluindo esta do Brett Cannon, já está no Blip.tv.
Chegando no Hg
Uma vez descartado o Git, foram apenas mais dois dias de suspense até que o Guido anunciou sua decisão favorável ao Hg, baseada principalmente nas preferências pessoais dos core developers que lhe enviaram e-mails ou twittaram sobre o tema. Segundo ele, o Git tem muitos fãs mas também um alto índice de rejeição, e o Hg tem ainda mais fãs que o Bazaar, com menos oposição. Então é isso, Mercurial na cabeça!
Gostei muito dessa escolha, porque passei bastante tempo tentando me acostumar com a idéia de usar um DVCS em vez do Subversion. Inicialmente brinquei com o Bazaar, mas só entendi realmente a idéia quando experimentei o Mercurial. Não sei se é a documentação dele que é melhor, ou seus comandos fazem mais sentido para mim, mas o fato é que com o manual do Mercurial a coisa toda finalmente fez sentido para mim.
Na verdade, eu vou mais longe, acho que aprender a usar o Mercurial é mais fácil que aprender a usar o Subversion, então se você ainda não usa um sistema de controle de versões, chegou a hora de começar!
Git e eu
Depois que eu já havia adotado o Mercurial eu resolvi aprender o Git porque estava na moda, e muita gente que eu respeito falava muito bem dele. Achei a documentação do Git horrenda, e suas mensagens de erro estão entre as piores que eu já vi. Ele foi desenvolvido pelo Linus e outros kernel hackers para uso próprio, e a documentação deixa claro que eles não se importam minimamente se meros mortais vão usar a ferramenta. Daí a comunidade Rails adotou o Git e com seu talento evangelista transformaram o Git em mais um ritual de sua religião.
Acontece que a maioria dos defensores do Git que eu conheço nunca experimentaram o Mercurial, e quase todas as vantagens do Git que eles apregoam por aí se aplicam perfeitamente ao Mercurial e até ao Bazaar.
Para mim as únicas vantagens objetivas do Git sobre o Mercurial são o desempenho e o Github.
A vantagem do desempenho é relativa, porque a gente não gerencia milhões de linhas de código como o Linus e os kernel hackers, então na prática isso significa que o Git faz em 0.01s algo que o Hg leva 0.1s para fazer.
Só que esta vantagem é anulada pelas armadilhas anti-usuário do Git. Cada vez que você perde 20 minutos tentando desfazer um erro lutando contra a interface hostil do Git, lá se vão 1200 segundos, ou seja, você acabou de perder a vantagem de desempenho equivalente a milhares de operações!
O Github é muito legal pelo seu componente social (virou uma espécie de Orkut de programadores), e continua sendo a melhor razão objetiva para usar o Git.
Agora com essa decisão da comunidade Python, o Bitbucket.org deve ficar mais popular, e funcionalmente ele é bem parecido com o Github.
Tentei muito gostar do Git, mas estou muito contente por poder deixá-lo de lado e voltar a me concentrar no Mercurial.
Na órbita de Mercurial
Vale notar que o Hg também foi adotado pelos core developers da linguagem Java e do projeto Mozilla (Firefox), então estamos na companhia de mega projetos (lista de usuários do Hg).
Com a adesão da comunidade Python ao Hg, vou migrar meus projetos relacionados a Python do Github para o Bitbucket.org. Nos vemos lá!
Subscribe to:
Post Comments (Atom)
7 comments:
Também optei pelo hg para meus projetos pessoais pela simplicidade e já tenho uma conta no bitbucket para, eu um breve futuro, disponibilzar alguma coisa.
Estou quase na mesma situação, estava olhando e estudando o git como se utilizar branchs tivesse uma curva de aprendizado elevada e achava que esse motivo usavamos subversion no trabalho, mas após ver a notícia do Python migrar para Mercurial resolvi dar uma olhada no projeto.
Com suporte Windows e melhor documentação, vou preferi-lo ao git.
PS: Depois da documentação do Django é difícil acostumar a docs e mensagens de erro ruins.
O que o git teria de vantagem é o rebase, mas penso que a última versão do mercurial já tem um rebase.
No geral eu achei a interface do mercurial mais simples. Cabe na minha cabeça.
Com o git, sempre tem algum canto escuro no quarto que a eu precisei de uma lanterna pra enxergar melhor...
Concordo. Estive dando uma olhada no git achei legal, mas é uma hype para pouca substancia. Ele e mercurial estão praticamente pau-a-pau em features.
O meu maior problema com Hg e Git é que as ferramentas gréficas ainda são muito alpha. Usei TortoiseHG, TortoiseGit, KGit, e alguns plugins do Eclipse mas tudo funciona mais ou menos ainda.
Eu também estou gostando mais do Mercurial. Eu acho ele menos verboso, só imprime o necessário na tela, entre outros detalhes bacanas que me agradam muito.
Além disso, acho ele menos confuso que o Bazaar e Git, vejo ele mais coeso, organizado e bem acabado. E tem o Bitbucket que é melhor que o Github e Google Code em minha opinião.
Você perecbe que ele é bom quando você perde um bom tempo tentando fazer algumas coisas em outros DVCS. Sempre que me deparo com um problema chato com o uso do controle de versão, no Mercurial resolvo rapidamente.
Parabéns pelo artigo, Luciano! Resumiu muito bem os prós e contras de cada um.
O que eu achei mais interessante foi a idéia para os iniciantes. Eu nunca tinha pensado em recomendar um DVCS para quem ainda nem sabe o que é VCS, mas recentemente tive que explicar o ciclo svn mkdir, svn checkout, copia tudo pra dentro do WC (explica a diferença entre Working Copy e Repositório), svn add, svn commit, depois esquece a pasta antiga e usa só a nova... Enfim, migramos para Mercurial. Não só por isso, claro! :)
O mercurial é muito interessante e bem vindo. Mas falar que ele é mais simples que o Subversion é um exagero.
Para trabalhar no esquema de projeto pessoal, ótimo. Ele é tão simples quanto o commit e o update do Subversion. Mas para um projeto com várias pessoas, quando começa a aparecer vários heads e merges já começa a ficar bem mais complicado.
E a operação de backout então? Quem realmente pode afirmar que é simples? Mais simples que um svn merge -c -NUM_REVISAO?
E pior, quando é pra desfazer um merge errado? Não é nem um pouco simples isso!
Quero reiterar mais uma vez que estou gostando muito do mercurial. Mas sejamos francos que um sistema de controle de versão distribuído só é simples que um centralizado em projetos de _EU_quipe.
Post a Comment