Feeds:
Posts
Comentários

Micro Tutorial de Bazaar

Conforme Prometido, vou reproduzir um tutorial idêntico ou pelo menos similar ao tutorial do Akita, só que utilizando o Bazaar ao invés do Git.

Recomendo altamente que leia o Artigo Original antes de prosseguir com a leitura, pois vou referenciar ele com bastante freqüência.

Pra deixar o ciclo completo eu vou baixar um projeto a partir do Launchpad que seria o “Equivalente” digamos assim do Github. o Akita utilizou com  exemplo o Código do Merb Core, eu vou utilizar um branch do próprio Rails, que está disponível no Launchpad, não sei porquê alguém resolveu manter um branch bazaar dele lá no launchpad, mas, o branch existe e vou usá-lo como exemplo.

Para poder realizar operações de escrita em um projeto do lanuchpad obviamente você deve se cadastrar lá, e vai ter um ambiente bem similar ao do Github, com chaves publicas etc etc.

Para clarear uma das maiores diferenças entre o Bazaar e o Git é que, no Bazaar cada diretório é um branch, ou seja, se eu clonar o branch do rails por exemplo eu terei um diretório rails que é o meu branch, já o Git, o diretório é uma espécie de placeholder(Projeto) e você pode ter quantos branches quiser dentro do mesmo diretório.

Também não vou mostrar como instala o Bazaar, visto que há diferenças em cada sistema operacional, e nada que uns 5 minutos de Google não devam resolver, só para constar estou usando a versão 1.9 liberada em 07/11/2008.

O projeto rails no Launchpad fica na seguinte url:

https://launchpad.net/rails

Para obter o código fonte de um projeto no launchpad o Bazzar possui um recurso que já vem instalado por padrão (como um plugin), logo para baixar o projeto rails via Bazaar faça:

bzr clone lp:rails
You have not informed bzr of your launchpad login. If you are attempting a
write operation and it fails, run "bzr launchpad-login YOUR_ID" and try again.
Branched 6711 revision(s).

ele reclamou ali que eu ainda não configurei minha identificação no launchpad,e eu não configurei mesmo ;).
ps: o processo acima vai demorar um pouco, assim como você fazer um clone do edge_rails do github também vai demorar, visto que ele baixa cerca de 41 megabytes.

Pronto, ao final do download você terá um branch contendo todo o histórico de revisões, assim como no git. no Bazaar o comando clone é um alias para o comando branch que tem por finalidade criar um novo branch a partir de outro, portanto clone, branch ou get fazem o mesmo efeito. Agora entre no diretório rails e digite:

bzr info
Standalone tree (format: pack-0.92)
Location:
  branch root: .

Related branches:
  parent branch: http://bazaar.launchpad.net/%7Evcs-imports/rails/trunk/

Aqui são exibidas a formato atual do sistema de armazenamento, indica que estamos em uma arvore standalone, que estamos trabalhando no branch “root .” e mostra a referência do branch master que é de onde nós pegamos a nossa cópia, e para onde podemos depois enviar nossas alterações.

Bem, aqui temos um conceito diferente que, no Bazaar você pode criar repositórios compartilhados e não compartilhados. Nos compartilhados você inicializa um repositório, e cria um branch dentro dele, a partir dai você pode criar tantos branches quanto forem necessários dentro do repositório e todos os recursos serão compartilhados, ou seja vai ficar similar ao Git, já nos repositórios não compartilhados cada branch mantém todo o seu próprio histórico independente. Note que é possível converter de um para outro.

Manipulando branches locais.

Bom agora eu tenho uma cópia(branch) do branch remoto em meu computador, eu poderia sair alterando os arquivos direto dentro deste branch e no final mandar as alterações de volta, não há nada de errado com este modelo, mas seguindo o modelo do artigo do Akita, vamos criar um branch para de trabalho e vamos chamar de working, mas primeiro para ficar o mais similar possível vamos renomear o nosso branch que no momento se chama rails para master, assim os comandos vão ficar mais parecidos e em seguida criaremos o nosso novo branch.

mv rails master
bzr branch master working
Branched 6711 revision(s).

E primeiro comando é do Sistema Operacional estou movendo o diretório rails para o diretório master (renomeando)
Em seguida crio um novo branch a partir do meu master, note que como ele irá copiar TODAS as revisões para o novo branch vai demorar um pouquinho mais do que no git que é instantânea a criação de um branch, para que tenha um comportamento similar teríamos que usar um repositório compartilhado ao invés de standalone, mas acho que isso é uma preferência pessoal.

Eu poderia agora entrar no novo branch working e fazer minhas alterações lá, mas para ficar mais similar ao Git vou criar primeiro uma cópia de trabalho:

bzr checkout working copia
cd copia
bzr info
Checkout (format: pack-0.92)
Location:
checkout root: .
checkout of branch: /home/alexandre/tmp/bazaar/working

podemos perceber que agora estamos dentro de um checkout do branch working. Agora vamos fazer algumas alterações, aqui você pode fazer o que quiser que não vai estragar nada nem no repositório “principal” e nem no seu branch master, em seguida vamos ver o que foi alterado.

bzr status
modified:
Rakefile
unknown:
alexandre.txt

Bem os arquivos que já estavam no repositório aparecem na sessão modified ou removed, os arquivos que o ainda não estão lá, aparecem na sessão unknown (desconhecidos).

Para adicionar o arquivo novo que acabamos de criar, vamos usar o comando add assim como no svn ou git

bzr add alexandre.txt
added alexandre.txt

caso varios arquivos tenham sido adicionados e você quer adicionar todos ao mesmo tempo (que seria o equivalente do git: git add . ) basta digitar:

bzr add

Aqui podemos notar outra diferença bastante grande entre o Bazaar e o Git, no Bazaar diretórios também são “versionados”, como se fossem arquivos regulares, então se criarmos um diretório vazio ele também será adicionado na árvore de versão, o que em muitos casos é util, para não termos que criar um arquivo .bzrignore dentro de uma pasta apenas para que a pasta seja “versionada”. Outra diferença é que o Bazaar ainda não possui uma opção interativa para o add (pelo menos eu desconheço), entretanto eu particularmente nunca senti a necessidade, pois mesmo utilizando o Git eu acabo dando normalmente um add . e um commit -a.

Agora com os novos arquivos adicionados podemos dar um commit, bem padrão igual ao svn e bastante similar ao git:

bzr commit -m "meu primeiro commit"
Committing to: /home/alexandre/tmp/bazaar/working/
modified Rakefile
added alexandre.txt
Committed revision 6712.

No Bazaar não é necessário a opção -a para “adicionar” as alterações.
Observando visualmente:

Screenshot 1

Bom no nosso caso como estamos em no branch working e ele poderia continuar sozinho parece apenas uma alteracao linear.
outra coisa que podemos perceber aqui, é que o Bazaar possui uns nomes de revisão legíveis, o que facilita em alguns procedimentos, internamente o Bazaar controla por um sha1 único para cada revisão tal como no Git ou Mercurial.

Bom seguindo o artigo original agora acabamos de descobrir um bug no branch master, então teremos que mudar (switch) para o branch master, então fazemos:

bzr switch master
Updated to revision 6711.
Switched to branch: /home/alexandre/tmp/bazaar/master/
ls alexandre.txt
ls: impossível acessar alexandre.txt: Arquivo ou diretório inexistente

bem, primeiro mudamos (switch) para o branch master, ou seja agora estamos em uma cópia de trabalho do branch master. agora vamos criar um branch chamado meufix para fazer nossas alterações.

bzr branch . ../meufix
Branched 6711 revision(s).

Bem, o que fizemos?
estávamos em uma copia de trabalho do branch master (igual) entao vamos criar um branch novo “../meufix” baseado no branch (copia de trabalho) atual “.”, note que apenas o comando switch pode ser usado para trocar de branches sem precisar referenciar o diretório, mas agora estamos criando o branch “meufix” no diretório anterior ao atual da copia de trabalho.

agora ainda estamos no branch master, vamos mudar para o branch meu fix

bzr switch meufix
Tree is up to date at revision 6711.
Switched to branch: /home/alexandre/tmp/bazaar/meufix/

Não é possível criar um branch e trocar para ele em um comando só, a não ser que usássemos trapassa do Sistema Operacional, que seria mais ou menos assim.

bzr branch . ../meufix && bzr switch meufix

Bem, fizemos a nossa correção de bug e vamos dar o commit nas alterações:

bzr commit -m "minha correcao"
Committing to: /home/alexandre/tmp/bazaar/meufix/
modified Rakefile
Committed revision 6712.

Pronto, correçao feita em cima do branch master.

Merges

Bom, agora temos o branch master que não chegamos a tocar, temos o branch working onde estávamos trabalhando e fizemos um bugfix em um branch a partir do master. Que zona! mas agora temos que juntar tudo isso. Basicamente os branches working e meufix tem o mesmo ancestral, o master.
bem, vamos primeiro pegar o que foi feito no branch meufix e dar um merge.

bzr switch master
Updated to revision 6711.
Switched to branch: /home/alexandre/tmp/bazaar/master/
bzr merge ../meufix
M  Rakefile
All changes applied successfully.

basicamente voltamos para o branch master e demos um merge nele com as informações do branch meufix, agora está tudo junto, podemos dar o commit para aplicar as alterações:

bzr commit -m "merge do meufix"
Committing to: /home/alexandre/tmp/bazaar/master/
modified Rakefile
Committed revision 6712.

vamos ver vizualmente o que aconteceu:

Screenshot 2

O master estava na revisão 6711, quando eu fiz o branch ele também estava nesta revisao entao fiz as alterações lá o branch meufix, e quando dei o merge novamente o número de versão ficou desta forma: [revisao pai][numero do branch][numero do commit], ou seja 6711.1.1. O numero do branch é gerado incrementalmente a medida que você executa o merge e deve ser lido da seguinte forma, Revisão 6711 branch 1 commit 1.

bom agora fizemos tudo que tinhamos que fazer e podemos apagar o branch meufix e voltar a trabalhar na nossa copia de trabalho do branch working.

bzr switch working
Updated to revision 6712.
Switched to branch: /home/alexandre/tmp/bazaar/working/
rm -rf ../meufix

Agora vamos trabalhar, mas, espere, fizemos uma correção no master e precisamos incorporar agora no nosso trabalho, mas, eu já estava no meio de uma alteração que ainda não está acabada, o que fazer?, a resposta é, guarda na prateleira e pega depois :).

bzr shelve
--- alexandre.txt    2008-11-14 16:57:16 +0000
+++ alexandre.txt    2008-11-14 19:18:20 +0000
@@ -0,0 +1 @@
+# Alexandre da Silva
Shelve this change? (1 of 1) [yndisq?] (y): y
Status:
alexandre.txt    2008-11-14 16:57:16 +0000
1 hunks to be shelved
0 hunks to be kept
Shelve these changes? [yrsiq?] (y): y
Shelving to default/00: "Changes shelved on 2008-11-14 17:18:29"

shelf em Inglês significa prateleira, ou pilha, então empilhamos as nossas alterações em um lugar temporário para usar depois, agora vamos pegar o que estava no master e incorporar aqui.

bzr merge ../master
M  Rakefile
All changes applied successfully.

pegas as alterações do master podemos agora pegar o que estávamos fazendo da prateleira e continuar nosso trabalho

bzr unshelve
--- alexandre.txt    2008-11-14 16:57:16 +0000
+++ alexandre.txt    2008-11-14 19:18:20 +0000
@@ -0,0 +1 @@
+# Alexandre da Silva
Unshelve this change? (1 of 1) [yndisq?] (y): y
Status:
alexandre.txt    2008-11-14 16:57:16 +0000
1 hunks to be unshelved
0 hunks left on shelf
Unshelve these changes? [yrsiq?] (y): y
Unshelving from default/00: "Changes shelved on 2008-11-14 17:18:29"

pronto, agora podemos continuar nosso trabalho e por fim dar um commit para aplicar as alterações.

commit -m "trabalho completo"
Committing to: /home/alexandre/tmp/bazaar/working/
modified Rakefile
modified alexandre.txt
Committed revision 6713.

e Vizualmente o que aconteceu:

Screenshot 3

agora temos a revisao 6711.2.1 que é do nosso segundo branch a dar merge logo apos o merge do primeiro branch.

Bem, no artigo do Akita ele usiliza o comando rebase, que é basicamente similar ao merge só que as alterações são desfeitas e refeitas uma a uma, e o merge aplica as alterações sobre a copia de trabalho atual, o Bazaar possui o comando rebase também, que pode ser adicionado via plugin, mas como eu nunca utilizei, não sei se ele é estável ou mesmo se vai funcionar com minha versão do Bazaar que acabou de sair do forno, além do mais na prática o resultado final é o mesmo então aqui ele se torna desnecessário.

Para finalizar vamos agora dar o merge no nosso branch master que é de onde veio o código original, e por fim poderíamos enviar todas as alterações devolta para o projeto original.

bzr switch master
Updated to revision 6712.
Switched to branch: /home/alexandre/tmp/bazaar/master/
bzr merge ../working
+N  alexandre.txt
M  Rakefile
All changes applied successfully.
bzr commit -m "merge com working"
Committing to: /home/alexandre/tmp/bazaar/master/
modified Rakefile
added alexandre.txt
Committed revision 6713.

e visualmente temos o resultado de todo o nosso trabalho:

Screenshot 4

pode parecer estranho que a versão 6711.2.1 veio depois da 6712, porém ele está mostrando a ordem temporal dos acontecimentos, além do mais fica fácil na visualização saber de onde cada revisão partiu. lembre-se que internamente as revisões são controladas igual ao git com hashes sha1.

Levando em consideração que cada um dos branches que eu criei funciona sozinho, eu posso manter cada um deles e criar outros a partir deles sem nenhuma restrição, inclusive se eu fizer um branch da minha cópia de trabalho, ele fará um branch do branch a que ela se refere no momento atual.

Para excluir um branch é só excluir o diretório que ele se encontra.

o Bazaar traz algumas funcionalidades interessantes que no Git é feito de forma diferente, vejamos:

Rename

bzr rename alexandre.txt alexandre2.txt
alexandre.txt => alexandre2.txt

Sim, no Bazaar eu posso renomear um arquivo explicitamente e ele mantém a referência disso. no Git seria mais ou menos como criar um arquivo novo com o mesmo conteúdo e excluir o anterior, ou realizar aquele processo mágico de comparação de conteúdo que o Akita mostra no artigo dele.

Uncommit

bzr commit -m "renomeado"
Committing to: /home/alexandre/tmp/bazaar/master/
renamed alexandre.txt => alexandre2.txt
Committed revision 6714.
bzr uncommit
6714 Alexandre da Silva    2008-11-14
renomeado
The above revision(s) will be removed.
Are you sure [y/N]? y
You can restore the old tip by running:
bzr pull . -r revid:lexrupy@gmail.com-20081114194441-ei3fa5npeo7puc8q
bzr status
renamed:
alexandre.txt => alexandre2.txt

Yes!, fiz uma coisa que não devia e dei um commit…. posso dar um uncommit e tudo volta como estava antes do commit. no Git você pode dar um hard reset no HEAD^1, mas o resultado não é exatamente o mesmo.

Conclusão

  1. Tudo foi feito offline com exceção do primeiro clone.
  2. Assim como no git eu tenho apenas 1 pasta .bzr no diretório principal do branch que controla tudo.
  3. Assim como no git podemos criar quantos branches quisermos para fazer nosso trabalho.
  4. Assim como no git o tamanho do diretório onde ficam guardados os arquivos com todas as revisões é praticamente do mesmo tamanho da própria cópia de trabalho.
  5. Assim como no git podemos trabalhar com um repositório svn remoto usando o bzr-svn e localmente usar todos os recursos do bazaar.
  6. E, por fim assim como no git eu escrevi este artigo enquanto digitava os comandos e dava uma olhada no blog do Akita para seguir mais ou menos o mesmo fluxo :).

E a conclusão final é, seja qual for a ferramenta que você goste mais, Git, Bazaar ou Mercurial, use-a e aprenda a usar bem, pois elas podem economizar um monte de trabalho extra. Este artigo não tem o propósito de dizer que o Bazaar é melhor que o Git ou que o Mercurial, Apenas mostra que oferece os mesmos recursos. para aprender mais sobre o Bazaar visite o site, é a documentação da última versão em desenvolvimento, para outras versões olhe em um diretório acima e escolha a versão que você está usando.

Anúncios

Git Bazaar ou Mercurial?

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 CodevilleDarcsMonotoneMercurialGit 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:

  1. Ser multiplataforma, afinal ainda tenho ainda hoje código fonte para manter em Delphi :(.
  2. Possuir um modo de converter meus repositórios Subversion.
  3. Ter uma curva de aprendizado pequena em relação ao SVN.
  4. 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 MingWMSyS 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 bugzillaTracRedmine 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 MingWMSyS 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.

Bem, fazem apenas algumas horas que o novo Ubuntu 8.10 foi anunciado e já temos uma atualização de Kernel, isso nao faz nada menos que provar que o software livre dá uma resposta rápida à qualquer tipo de falha, problema ou erro que possa vir a ocorrer. Vale lembrar que embora o anúncio tenha saído hoje próximo ao meio dia, as imagens iso dos cds de instalação já estavam prontas pelo menos desde ontem para que todos os mirrors pudessem ser atualizados em tempo.

Com esta versão do Ubuntu temos o melhor linux de todos os tempos com várias melhorias visuais e não visuais, com uma base forte e estável (Debian), trazendo o que há de mais novo e moderno do software para as nosssas casas. Foi só uma pena que o OpenOffice 3 não tenha sido lançado antes do Freeze do 8.10 para que desse tempo de ser incluso.

Ubuntu 8.10 Intrepid Ibex

Quase todos os mirrors “espelhos” etão prontos para o lançamento, mas você já pode ir baixando antes mesmo do anúncio oficial.

Confira as novidades desta nova versão:

GNOME 2.24

Ambiente desktop GNOME 2.24, com várias correções de bugs e novas funcionalidades incluindo:

  • Nautilus Gerenciador de arquivos ganhou suporte a abas, e novos icones de eject para dispositivos removíveis na barra lateral.
  • File Roller Gerenciador de arquivos compactados agora suporta os tipos de arquivo ALZ, RZIP, CAB, TAR.7Z.

X.Org 7.4

X.Org 7.4, A última versão estável do X.Org, está disponível no Intrepid. Esta versão traz suporte melhorado para dispositivos hot-plug, como tablets, teclados e outros. Ao mesmo tempo permite que a maioria dos usuários possa utilizar o sistema sem um arquivo /etc/X11/xorg.conf. Traz também gerênciamento de falhas e ferramentas recuperar de falhas de inicialização.

Linux kernel 2.6.27

Inclui por padrão o kernel 2.6.27 que possui melhor suporte a hardware e uma série de correções de bugs.

Diretório privado criptografado

Traz também suporte a um mecanismo chamado secret encrypted folder que pode ser utilizado para criptografar seus arquivos pessoais, ele não vem habilitado por padrão pois a maioria dos usuários não necessita deste recurso, mas quem quiser, abra um terminal (Aplicações →  Acessórios → Terminal) e digite:

  • sudo aptitude install ecryptfs-utils
  • ecryptfs-setup-private

Sessão anônima

Foi criado um novo applet para o painel do gnome que permite a troca rápida entre usuários, que dá suporta também a um recurso chamado de sessão anônima, este recurso é muito útil quando você precisa deixar alguém utilizar seu computador temporariamente para uma simples checagem de email. O sistema cria uma sessão temporária, sem necessidade de senha, onde o usuário tem acesso apenas aos recursos do sistema como browser etc, porém sem nenhum acesso aos sistemas de arquivos, diretórios home por exemplo.

Network Manager 0.7

O Intrepid traz também o Network Manager 0.7 que vem com algumas funcionalidades adicionais incluindo:

  • Configurações a nivel de sistema (ex: não é necessário logar para ter acesso a uma conexão)
  • Gerenciamento de conexões 3G (GSM/CDMA)
  • Gerenciamento de dispositívos múltiplos ao mesmo tempo
  • Gerenciamento de conexões PPP(Internet Discada) e PPPOE (ADSL)
  • Gerenciamento de dispositivos com IP fixo
  • Gerenciamento de Rotas dos dispositivos

Mais informações podem ser obtidas no wiki do Network Manager. (Inglês)

DKMS

DKMS (Dell) também está incluso no 8.10, este é um recurso interessante que permite que drivers sejam recompilados (rebuild) automaticamente quando novos kernels sao instalados no sistema. Isto permite que atualizaçẽos de kernel estejam disponíveis imediatamente, sem ter que esperar a recompilação dos pacotes de drivers, agilizando o processo.

Samba 3.2

Novos recursos também incluídos na comunicação com o protocolo smb:

  • suporte a servidores de arquivos em cluster
  • transmissão de pacotes de rede criptografados
  • suporte a ipv6
  • melhor integração com as versões mais recentes do Microsoft Windows™, tanto clientes (desktop) e servidores.

framework de autenticação PAM

8.10 permite gerenciamento simples de autenticação PAM para servidores e desktop. Pacotes que provém recursos do PAM serão automaticamente configuradas, e os usuários poderão fazer suas configurações pessoais executando sudo pam-auth-update.

Mais informações no  wiki do Ubuntu.

plugin BBC para Totem

Um novo plugin que permite obter conteúdo direto da BBC.

Virtualização de servidores

python-vm-builder

O ubuntu-vm-builder foi completamente reescrito, provendo agora melhor sistema de templates, sistema de plugins permitindo suporte para outras distribuições, front-ends e outras funcionalidades adicionais

O Python-vm-builder permite a criação de novas máquinas virtuais em poucos minutos sem entrar em um processo interativo de instalação, ele pode ser múito útil para desenvolvedores, administradores de sistema e vendedores de software. Um tutorial está disponível em https://help.ubuntu.com/community/JeOSVMBuilder (Inglês)

Ubuntu como um “Xen guest”

Usar o Ubuntu deste modo agora é incluida por padrão no kernel, é mais uma opção ao criar máquinas virtuais usando o python-vm-builder.

JeOS é agora uma opção no instalador do server

Para simplificar o processo e reduzir confusão na hora de instalar o JeOS em hardware real, o JeOS não é mais uma ISO de instalação separadade. Ao invés disso é  uma opção ativada no processo de instalação da versão server, pressionando F4 na primeira tela e selcionando a opção “Install a minimal virtual machine” (Instalar máquina virtual mínima).

Inclusões no repositório principal (main)

Alguns pagotes bastante utilizados foram inclídos no repositório principal, para facilitar a instalação, estes pacotes são de interesse particular para administradores de servidores:

  • Sun Java OpenJDK 1.6 – Uma implementação open source do Kit de desenvolvimento java
  • Apache Tomcat 6 – Um container servlet para Java
  • ClamAV – um sistema de detecção de vírus que pode ser associado a uma série de servidores de email
  • SpamAssassign – Um sistema de detecção de spam que pode ser associado a vários servidores de email

Inicialização de raid com problemas

Quando um disco de um array RAID apresenta problemas normalmente o boot do Ubuntu era levado a um promt reduzido (busybox) no initramfs. Esta é a opção mais secura e previne possíveis perdas de dados e permitindo que o administrador tome alguma decisão, mas estava causando problemas com servidores remotos. O administrador do sistema pode configurar “estaticamente” suas máquinas para continuar inicializando mesmo que um disco do array esteja ruim com o seguinte comando:

  • echo "BOOT_DEGRADED=true" | sudo tee -a /etc/initramfs-tools/conf.d/mdadm

Adicionalmente esta configuração pode ser especificada na linha de boot do kernel com o parâmetro bootdegraded=[true|false].

Agora o Ubuntu também suporta o comando service

Administradores de Fedora ou Red-Hat agora vao se sentir mais confortáveis usando o Ubuntu pois o comando service que usavam antes está disponível para gerenciar os daemons. Agora por padrão, além do método tradicional sudo /etc/init.d/<service> [start|stop|restart] de gerenciamento de processos, é possível usar sudo service <service> [start|stop|restart].

Uma série de serviços padrão agora suportam a opção status, então por exemplo, sudo service postfix status vai retornar se o serviço está ou não rodando.

OpenLDAP usando ”cn=config”

A instalação padrão do servidor OpenLDAP agora usa a extenção cn=config, que permite sincronização automática entre alterações de configuração em replicas LDAP.

Firewall descomplicado (ufw)

Serviços comuns agora informam ufw sobre portas que são recomendadas para serem habilitados corretamente, então o administrador pode abrir com um simples comando ufw allow <service>.

Novas formas de instalação

Esta nova versão vem também com suporte a novas opções de instalação como o MID USB, que serve para equipamentos “Low-Power Intel Architecture”, incluindo processadores A1xx e Atom. e também uma nova  opção chamada “Mobile USB” que pode ser colocada em um pendrive para instalação ou uso (como o livecd), esta versão é otimizada para computadores pequenos com telas reduzidas (PCs Ultra-Móveis), por exemplo 10 polegadas, mas é necessário lembrar que para rodar esta versão seu equipamente precisa ter pelo menos 256 MB de memória RAM.

Mais informação

Você pode encontrar mais informação sobre o ubuntu no website e no wiki.

Para efetuar o download da ISO, clique em um dos links a seguir, note que os arquivos já estávam disponíveis em alguns servidores antes mesmo do anúncio oficial, isto se dá porque a Canonical aguarda que todos os seus espelhos estejam atualizados antes de lançar o anúncio.

Link 1 (Este link já estava disponível antes mesmo do anúncio oficial)

Link 2

Link 3 (Também disponível do anúncio oficial)
Link 4 (Também disponível antes do anuncio oficial)
 
O Link Oficial para download no site do Ubuntu é este aqui

O usuários do Mac e do Textmate contam com alguns benefícios quando se desenvolve em Rails, visto que boa parte dos desenvolvedores do Rails, inclusive do core-team utilizam esta plataforma e editor de texto. em busca de melhorar a experiência dos usuários linux fui verificar a possibilidade de portar mais um plugin bastante interessante, o rails-footnotes.
Este plugin oferece algumas funcionalidades bem interessantes, e uma das funcionalidades que eu acho mais útil é que ele transforma o backtrace de um erro exibido do browser em links, onde você pode clicar, e o editor de texto abrirá o arquivo listado no trace posicionando o cursor na linha indicada, facilitando e muito na hora de seguir o rastro de um bug.
No momento a única funcionalidade que eu portei, foi o backtrace, quem sabe no futuro eu verifique a possibilidade de portar mais funcionalidades
Assim que sobrar um tempinho vou solicitar ao drnic para dar um merge das alterações que eu realizei no plugin para que todos possam ter acesso, por enquanto você pode instalar o plugin através do meu fork no github

Para instalar o plugin em sua aplicação rails faça o seguinte:

script/plugin install http://github.com/lexrupy/rails-footnotes.git vendor/plugins/footnotes

para que o plugin funcione no Gedit é necessário instalar o url-handler para que o navegador saiba que um link apontando paratxmt://open?file=…. tenha que abrir o arquivo na linha x. para isso faça o seguinte logo após a instalação normal do plugin:

cd vendor/plugins/footnotes
sh linux_install.sh

Este processo de instalação precisa ser realizado apenas uma vez, então depois que você instalar o plugin no seu linux na primeira vez, poderá apenas executar a primeira etapa para quaisquer outra aplicação que desejar.

Note que para instalar você precisa ter em mãos sua senha do sudo.

Para quem não conheçe a suite de plugins para melhorar a usabilidade do gedit com aplicações Rails clique aqui

Veja um pequeno vídeo do plugin em funcionamento:

Ao contrário do que alguns estão falando por ai, o BrOffice (Versao Brasileira do OpenOffice) foi lançado juntamente com o OpenOffice, para quem nao está conseguindo acessar a página, pode utilizar os links a seguir:

DEB/GNU/LINUX: Download

EXE/MSWINDOWS: Download

Gedit Modelines

Tabulações, Espaços, Nível de tabulação, etc, todas estas configurações no gedit são manuais, você precisa ir no menu Editar, Preferências e encontralas para modificar o comportamento certo?

Errado

Existe um plugin chamado “modelines” que tenho certeza que muita gente já viu lá na lista de plugins mas não sabe para que serve. bem vamos a uma breve explicação:

Alguns editores de texto, como o Vim, Emacs e até mesmo o Kate, suportam um recurso com este nome, que nada mais é que incluir uma linha no arquivo em edição para definir o modo de operação sobre este arquivo mode-line.

antes a definição mínima:

“ShiftWidth é a quantidade de espaços que são inseridos para cada TAB”

“TabStop é a quantidade de espaços que um TAB vai ocupar na visualização”

vejamos um exemple de modeline do vim:

# vim:set ts=4 sw=4 noexpandtab:

que significa:

defina o tabstop para 4 e o shiftwidth para 4 e não expanda os tabs para espaços.

podemos utilizar esta mesma linha no gedit com o plugin modeline ativado.

um exemplo para arquivos ruby seria:

# vim:set ts=2 sw=2 expandtab nowrap textwidth=80

ou seja, estamos definindo para trocar tabs por espaços utilizando um tabstop/shiftwidth de 2 caracteres, não queremos que ele quebre as linhas e queremos a régua de texto na posição 80 caracteres.

um exemplo para python seria algo como:

# vim:set ts=4 sw=4 expandtab nowrap textwidth=80

basicamente a mesma coisa só que com um tabstop/shiftwidth de 4 caracteres.

experimente colocando esta linha no início do seu arquivo e ir modificando ela e vendo os resultados automaticamente.

esta linha funciona no gedit para qualquer linguagem, basta estar presente no arquivo nas primeiras 3 linhas em um comentário. o aconselhável é você utilizar o plugin de snippets(trechos) para criar um header para cada tipo de arquivo que você utiliza, onde você pode além desta informação colocar a licença de uso etc etc… a criatividade é sua.

Não deixe de conferir meu set de plugins para tornar o gedit uma “Rails IDE”