Feeds:
Posts
Comentários

Posts Tagged ‘Linux’

Este é um pequeno guia para iniciantes, que já tenham alguma noção do que é um controle de versão, caso você ainda não saiba veja adefinição da Wikipédia sobre Sistema de Controle de versão e também a definição de Sistema de Controle de Versão Distribuído (Em Inglês) que é o caso do Bazaar.

Quando precisamos de um controle de versão?

Sempre que queremos manter o histórico de alterações de arquivos, sejam eles código fonte de programas ou até mesmo documentos (aquelas várias versões do seu trabalho de conclusão de curso) entre outros arquivos, também é possível manter versões de arquivos binários, como fotos programas executáveis entre outros, porém para estes últimos alguns recursos não são possíveis, tais como ver as diferenças entre o arquivo na revisão 5 e 6.

Mas qual ferramenta usar?

Bem, existem várias e depende do molde que você quer trabalhar, mas eu posso recomendar hoje 3 ferramentas, e vou listar em ordem da mais fácil para a mais difícil de usar (na minha opinião), são elas: Bazaar, Git e Mercurial.
Presando pela facilidade de instalação e uso mas com todos os recursos dos demais e até mais algumas opções, minha opção foi o Bazaar.

Vou partir do princípio que você sabe instalar um software em seu sistema operacional, bem como utilizar um shell (“Promt de comando” para usuários windows). Todos os meus exemplos são feitos no Linux utilizando o gnome-terminal, sendo que para Windows alguns comandos do sistema operacional podem ser diferentes, mas os comandos do Bazaar são iguais.

Instalação

O Bazaar está disponível oficialmente para uma série de sistemas operacionais e também em forma de código fonte que “teoricamente” pode ser compilado em qualquer plataforma que rode Python.

  • Linux: Se já não estiver instalado você pode facilmente encontrar em seu gerenciador de pacotes, geralmente o nome do pacote é “bzr” e não bazaar:
  • Windows Siga as instruções de instalação (Em inglês) aqui ou clique aqui para baixar o diretamente o instalador da versão 1.9.
  • Mac OS X: Siga as instruções aqui (Em inglês).
  • Para outras plataformas e instalação via código fonte, veja mais informações aqui e aqui (Em inglês).

Se apresentando para o Bazaar

Antes de começar a controlar versão de coisas é interessante colocar sua identificação no Bazaar, para que ele possa “assinar” suas alterações nos arquivos, normalmente é utilizado o nome e email como identificação, portanto em um promt utilizando seus próprios dados digite:

  $ bzr whoami "Alexandre da Silva <simpsomboy@gmail.com>"

o Bazaar vai criar um arquivo de configuração (ou atualizar se ele já existir) incluindo sua identificação. para verificar qual a identificação você está utilizando atualmente ignore o segundo parâmetro e ele exibirá as configurações atuais:

  $ bzr whoami
  Alexandre da Silva <simpsomboy@gmail.com>

Controlando a versão de arquivos

Agora vem a parte interessante, vamos controlar a versão de alguns arquivos, para isso vamos criar uma pasta/diretório onde ficarão estes arquivos:

  $ mkdir arquivos
  $ cd arquivos
  $ mkdir adicionais
  $ touch teste1.txt teste2.txt teste3.txt adicionais/teste4.txt teste5.txt

(Usuários do windows não possuem o comando touch, e devem usar o Windows Explorer ou outra ferramenta para criar alguns arquivos texto vazios)

Até agora temos apenas uma pasta e um punhado de arquivos, vamos colocá-los agora no controle de versão:

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

Aparentemente nada foi feito, porém o Bazaar inicializou o diretório atual como um “branch” que nada mais é do que um local onde ficarão registradas todas as alterações realizadas nos arquivo pertencentes a ele. No Bazaar um branch é um diretório.

o próximo passo é adicionar os arquivos ao branch:

  $ bzr add
  added adicionais
  added teste1.txt
  added teste2.txt
  added teste3.txt
  added teste5.txt
  added adicionais/teste4.txt

Agora o Bazaar conhece os arquivos que ele deve manter o histórico, então vamos criar nossa primeira “revisão” dos arquivos existentes. Pense em uma revisão como uma foto do estado atual dos arquivos.

  $ bzr commit -m "Primeira versão"
  Committing to: arquivos/
  added adicionais
  added teste1.txt
  added teste2.txt
  added teste3.txt
  added teste5.txt
  added adicionais/teste4.txt
  Committed revision 1.

Como o Bazaar é um controle de versão distribuído não é necessário conectar a um servidor para enviar as alterações, todo o histórico de todos os arquivos ficam guardados dentro de apenas um sub-diretório especial chamado “.bzr” que fica no diretório raíz do branch.

Alterando seus arquivos

Vamos fazer algumas alterações e armazenar (commit) o que foi feito para o nosso branch.
Edite o arquivo teste1.txt em seu editor favorito, depois verifique o que foi feito:

  $ bzr diff
  === modified file 'teste1.txt'
  --- teste1.txt    2008-11-28 22:39:16 +0000
  +++ teste1.txt    2008-11-28 22:43:09 +0000
  @@ -0,0 +1,1 @@
  +teste teste teste

Armazene seu trabalho no branch:

  $ bzr commit -m "Adicionada primeira linha no arquivo teste1.txt"
  Committing to: arquivos/
  modified teste1.txt
  Committed revision 2.

Verificando o Log de alterações

Você pode ver todo o histórico do que foi modificado e quem modificou observando o log de alterações:

  $ bzr log
  ------------------------------------------------------------
  revno: 2
  committer: Alexandre da Silva <alexandre@exatisistemas.com.br>
  branch nick: arquivos
  timestamp: Fri 2008-11-28 20:44:12 -0200
  message:
    Adicionada primeira linha no arquivo teste1.txt
  ------------------------------------------------------------
  revno: 1
  committer: Alexandre da Silva <alexandre@exatisistemas.com.br>
  branch nick: arquivos
  timestamp: Fri 2008-11-28 20:39:16 -0200
  message:
    Primeira versão

Publicando seu trabalho em um servidor sftp

Existem várias maneiras de publicar um branch do Bazaar, mas uma das mais fáceis é utilizar um servidor sftp, se você tiver acesso a um você pode publicar seu branch da seguinte forma:

  $ bzr push sftp://seu.usuario@seu.servidor/~/arquivos
  Created new branch.

Criando sua própria cópia de um branch existente

Para trabalhar com os arquivos de outra pessoa você deve obter sua própria cópia (branch) para que possa trabalhar com os arquivos localmente em seu computador:

  $ bzr branch sftp://seu.usuario@seu.servidor/~/arquivos arquivos-copia1
  Branched 2 revision(s).

O Bazaar vai fazer o download de todas as revisões dos arquivos contidos no branch, além de uma cópia de trabalho contendo o estado atual dos arquivos.

Atualizando seu branch a partir de um branch remoto já modificado

Enquanto você modifica seus arquivos, os outros usuários também podem modificar os arquivos deles, podendo ser inclusive os mesmos arquivos, e neste último caso se for alterada a mesma parte do arquivo, há grande chace de você ter que resolver alguns conflitos, mas o processo é bem simples, mas em grande parte dos casos o Bazaar faz todo o trabalho para nós. Para atualizar nosso branch (cópia de trabalho) que já foi alterada, com um branch remoto que também já pode ter sido alterado, utilizamos o comando merge:

  $ bzr merge
  Merging from remembered parent location sftp://seu.usuario@seu.servidor/~/arquivos/
   M  teste2.txt
  All changes applied successfully.

Agora verificamos o que foi alterado:

  $ bzr diff
  === modified file 'teste2.txt'
  --- teste2.txt    2008-11-28 22:39:16 +0000
  +++ teste2.txt    2008-11-28 22:59:10 +0000
  @@ -0,0 +1,1 @@
  +editado editado editado

Estamos contentes com as alterações, vamos dar o nosso commit (armazenar nossas alterações) e em seguida publicar devolta para o branch remoto

  $ bzr commit -m "Merge a partir do branch principal"
  Committing to: arquivos-copia1/
  modified teste2.txt
  Committed revision 4.

  $ bzr push sftp://seu.usuario@seu.servidor/~/arquivos
  Pushed up to revision 4.

Como aprender mais

  1. Eventualmente estarei postando mais informações relacionadas aqui no blog.
  2. O Site oficial oferece uma ótima documentação, porém encontra-se em sua maioria em Inglês. http://doc.bazaar-vcs.org/latest/en/user-guide/index.html
  3. O próprio Bazaar pode lhe dizer o que fazer em alguns casos, para tanto consulte a ajuda de linha de comando:

Informações sobre a linha de comando do Bazaar

  $ bzr help

Informações sobre vários comandos do Bazaar

  $ bzr help commands

Informações detalhadas sobre um comando específico

  $ bzr help [comando]

Este artigo foi fortemente inspirado e pode ser considerado uma tradução parcial de: http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html

Anúncios

Read Full Post »

Olá, hoje vou demonstrar como criar um servidor de controle de versão distribuído Bazaar. Para tanto temos basicamente 2 alternativas:

  1. Não fazer nenhuma configuração de Bazaar no servidor, apenas utilizar a estrutura existente.
  2. Instalar o Bazaar no servidor para prover o recurso do “Fast Server” que dá uma melhora na performance, ( em alguns testes que eu fiz baixar uma arvore de codigo direto do meu servidor para minha maquina tive um ganho de aproximadamente 20% )

Alguns protocolos de comunicação são suportados pelo Bazaar, são eles:

file:// => Este é o padrão, o protocolo utilizado quando você trabalha com branches no mesmo computador ou em um compartilhamento da rede no computador local, ou seja, se você fizer o seguinte:

$ bzr init meubranch
$ cd meu branch
hack
hack
hack
$ bzr commit -m "tudo pronto!"
$ cd ..
$ bzr checkout meubranch meubranch1

o último comando irá utilizar o protocolo file://

sftp:// => Este é o protocolo para usar em uma conexão segura ssh+ftp com o servidor, claro que se também é possível trabalhar localmente com este protocolo, mas é totalmente desnecessário. Este protocolo é o mais comum para servidores sem setup de Bazaar, pois fornece um bom nível se segurança. É necessário informar o usuário e senha do usuário do servidor para fazer operações com sftp, por exemplo:

bzr branch sftp://usuario@meuservidor/~/branch
usuario@meuservidor's password:_

Então você deve informar a senha do usuário para continuar a operação.
se não quiser entrar com a senha para cada operação é possível guardar as configurações de usuário e senha em um arquivo de autenticação, você pode ver mais osbre este procedimento aqui: http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#authentication-settings

ftp:// => Este protocolo utiliza ftp, pode ser necessário informar um usuário e senha assim como no sftp a maior diferença é que os dados irão trafegar sem criptografia, o restante vale o mesmo do sftp.

http:// ou https:// => O Bazaar pode acessar qualquer branch que esteja visível via http ou https (com criptografia ssl), porém estes branches são apenas para leitura, é possível configurar o Apache por exemplo para permitir gravação em repositórios Bazaar sobre http, mas não é seguro e nem muito simples, então descarte a não ser que seja a última alternativa. Entretanto é um ótimo protocolo para repositórios publicados como somente leitura.

bzr:// => Este é o protocolo interno do Bazaar para utilizar em modo FastServer. Note que este protocolo sozinho não oferece segurança.

bzr+ssh:// => Este é o mesmo protocolo acima porém, utilizando um túnel ssh para trafegar os dados. É necessário possuir um servidor ssh instalado no servidor.

Servidor Sem Configuração.

Bem você vai precisar de um servidor linux instalado, de preferência o Ubuntu Server Edition 8.04 ou 8.10. As instruções de como instalar um servidor estão fora do escopo deste guia, mas, vá até o Google e digite “instalando ubuntu server”. Também é possível utilizar um servidor Windows mas eu particularmente não recomendo.

Considerando que o servidor já esteja funcionando, ele deve ter um servidor ssh com sftp rodando, e você ter acesso a ele é claro.
Pronto! Seu servidor Bazaar já está pronto para uso!:). Mas como isso? Não é preciso fazer configurações adicionais? De fato não, como o Bazaar é um controle de versão distribuído (4a Geração) que não precisa de nenhum setup no servidor.

Servidor com configuração.

Vou assumir que seu servidor usa Ubuntu ou Debian, ou alguma distribuição baseada em um dos dois. Você vai precisar de acesso root (sudo) no servidor e uma conexão com a Internet é claro :).
Para instalar o Bazaar no servidor execute:

sudo apt-get install bzr

depois deste comando o Bazaar já deve estar funcionando, para verificar digite:

$ bzr
Bazaar -- a free distributed version-control tool
http://bazaar-vcs.org/

Basic commands:
  bzr init           makes this directory a versioned branch
  bzr branch         make a copy of another branch

  bzr add            make files or directories versioned
  bzr ignore         ignore a file or pattern
  bzr mv             move or rename a versioned file

  bzr status         summarize changes in working copy
  bzr diff           show detailed diffs

  bzr merge          pull in changes from another branch
  bzr commit         save some or all changes

  bzr log            show history of changes
  bzr check          validate storage

  bzr help init      more help on e.g. init command
  bzr help commands  list all commands
  bzr help topics    list all help topics

Se o comando retornar algo similar ao texto acima, o Bazaar deve ter sido instalado corretamente.
Neste momento a parte de Bazaar já está pronta! Nossa mas só isso? Sim só isso :). Mas vamos colocar algo mais palpável para uso em produção.
Primeiro para não precisar encher o servidor de usuários, vamos criar um usuário que terá direitos de acesso aos branches, você pode usar o nome que você quiser para o usuário, em nosso exemplo vamos utilizar bzr.
digite o seguinte no servidor:

$ sudo adduser \
    --system \
    --shell /bin/sh \
    --gecos 'Bazaar version control' \
    --group \
    --disabled-password \
    --home /home/bzr \
    bzr

isso vai retornar algo como:

Adding system user `bzr' (UID 110) ...
Adding new group `bzr' (GID 118) ...
Adding new user `bzr' (UID 110) with group `bzr' ...
Creating home directory `/home/bzr' ...

o que estamos fazendo é criando um usuário e dando a ele um shell válido, para que o ssh funcione porém ele não poderá se logar no servidor usando qualquer senha. Ai você me pergunta, mas se não tem senha, como vamos fazer para autenticar no servidor? a resposta é, usando autenticação por ssh. Vou explicar aqui como fazer isso usando linux, para usar windows é possível fazer algo similar usando o PuTTY, mas o uso do PuTTY também está for do nosso escopo.
O primeiro passo é gerar uma chave pública e privada ssh, para fazer isso digite em um promt no seu computador cliente:

$ ssh-keygen

O comando vai pedir o local onde salvar a chave publica e privada, deixe o padrão, também vai pedir uma senha, que é opcional, se você não digitar nada ele não vai pedir nenhuma senha para efetuar a autenticação, entretanto eu recomendo que cada usuário coloque uma senha em suas chaves.
Bem, foi criada uma chave publica em ~/.ssh/id_rsa.pub e precisamos enviar esta chave para o servidor e colocar ela em um lugar que o usuário bzr conheça para que ele possa comparar a chave publica com a chave privada de cada usuário e efetuar a autenticação. Coloque o arquivo no servidor, vou exemplificar usando sftp:

$ scp ~/.ssh/id_rsa.pub usuario@servidor:id_rsa.pub

Agora acesse o servidor (via ssh ou outro) e lá iremos adicionar a chave publica que acabamos de criar para o cliente, na lista de chaves conhecidas do usuário bzr. já no servidor é preciso tornar-se o usuário bzr utilizando sudo e em seguida jogar o conteúdo da chave para a lista de chaves conhecidas do usuário bzr:

$ sudo su bzr
$ mkdir ~/.ssh (necessário apenas se o diretório ainda não existir)
$ cat id_rsa.pub >> ~/.ssh/authorized_keys

A sequência de comandos acima assume que você está no diretório home do usuário ao qual foi enviado o arquivo id_rsa.pub. Pronto!, a partir deste momento você já pode  utilizar o servidor e criar seus branches Bazaar nele, tanto usando sftp, quanto bzr+ssh (que é o mais recomendado).
Agora volte para sua máquina e vamos criar o nosso primeiro branch usando sftp (este não necessitaria ter o Bazaar instalado no servidor):

$ mkdir meubranch
$ cd meubranch
$ bzr init
$ touch arquivo1.txt
$ bzr add
$ bzr commit -m "branch teste"
$ bzr push sftp://bzr@servidor/~/meubranch

Isto vai publicar (push) as alterações de seu branch local para o servidor remoto via sftp.
para usar via bzr+ssh e ter um ganho de performance em algumas operações troque o ultimo comando por:

$ bzr push bzr+ssh://bzr@servidor/home/bzr/meubranch

Note que neste caso utilizamos o caminho completo para o branch no servidor, pois até o presente momento o ~ (til) que representa a pasta home do usuário ainda não é suportada pelo Bazaar, mas será em breve. Lembre que informar o camhinho do branch é necessário apenas no primeiro chechout/pull/push depois o caminho fica gravado. Mas se você resolver colocar os repositórios em alguma parte do servidor que seja muito difícil de digitar, como por exemplo “/var/projetos/vcs/bzr/branch” então você pode criar um link simbólico para a pasta raís, dentro do /.

sudo ln -s /home/bzr /bzr

isto vai criar um link com o nome bzr no sistema de arquivos raíz, então a o comando com a url vai ficar assim:

$ bzr push bzr+ssh://bzr@servidor/bzr/meubranch

Se não quiser publicar diretamente a pasta do usuário como /bzr, você pode (e deve) criar um subdiretório para os projetos dentro de “/home/bzr/projetos” e apontar o link simbólico para lá. (não esqueça de tornar-se(sudo su bzr) o usuário bzr antes de criar o diretório).

Toda a parte de configuração do servidor termina aqui. Claro que você pode criar seu servidor de outros modos, como por exemplo criando um usuário para cada desenvolvedor, etc, e aplicar suas próprias regras de segurança, mas isso é uma questão estrutural de cada projeto e/ou empresa.

foi comentado do protocolo bzr:// sem o ssh, para levantar um servidor desta natureza utilize o seguinte comando dentro de um branch:

bzr serve

Ele vai levantar um servidor somente leitura que ficará ouvindo maquina local (se você tiver o Ipv6 ativado, este comando vai dar um erro, então utilize bzr serve –port=127.0.0.1:4155 ) que é bastante útil quando queremos publicar um branch temporariamente com outro membro da equipe para que ele faça um merge por exemplo. se quiser que seja publicado para leitura e escrita utilize o parametro –allow-writes.

bzr serve --port=127.0.0.1:4155 --allow-writes

Para saber mais sobre o Bazaar acesse a seguinte página: http://doc.bazaar-vcs.org/latest/
Lá você vai encontrar a documentação completa de cada comando entre outras informações úteis.

Read Full Post »

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.

Read Full Post »

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

Read Full Post »

Many thanks to Firmansyah Adiputra Now we get gedit TODO List working properly with Firefox 3 and Ubuntu 8.04

Download the 0.1.4b version from sourceforge install and enjoy.

Read Full Post »

Após um longo tempo tentando fazer funcionar as notificações dos testes com o Rails no meu recém instalado Ubuntu 8.04 (hardy) sem muito sucesso, finalmente cheguei a uma resposta.

a Combinação foi a seguinte:

1. ZenTest (ZenTest 3.9.2), o Framework de testes propriamente dito.

$sudo gem install ZenTest

2. RedGreen (redgreen 1.2.2), para colorizar o resultado dos testes, fica mais atrativo e fácil de verificar os resultados

$sudo gem install redgreen

3. libnotify-bin, pacote presente nos repositórios do ubuntu para enviar mensagens de notificação ao desktop

$sudo apt-get install libnotify-bin

4. Arquivo de configuração do autotest colocado no meu diretório home ~/.autotest
neste caso:

$gedit ~/.autotest

e coloque o código a seguir:

# ~/.autotest
module Autotest::GnomeNotify
  EXPIRATION_IN_SECONDS = 8
  FAIL_IMAGE    = "gtk-dialog-error"
  PENDING_IMAGE = "gtk-dialog-warning"
  SUCCESS_IMAGE = "gtk-dialog-info"
#  FAIL_IMAGE    = "~/Imagens/rails_fail.png"
#  PENDING_IMAGE = "~/Imagens/rails_pending.png"
#  SUCCESS_IMAGE = "~/Imagens/rails_success.png"

  def self.notify title, message, stock_icon
    options = "-t #{EXPIRATION_IN_SECONDS * 1000} -i #{stock_icon}"
    system "notify-send #{options} '#{title}' '#{message}'"
  end

  Autotest.add_hook :ran_command do |at|
    result = at.results.last
    if result
      examples = result =~ /(\d+) examples/ ? $1.to_i : 0
      failures = result =~ /(\d+) failure/ ? $1.to_i : 0
      pendings = result =~ /(\d+) pending/ ? $1.to_i : 0

      if failures > 0
        notify "Tests Failed", "#{failures} test#{ 's' if failures > 1 } failed", FAIL_IMAGE
      elsif pendings > 0
        notify "Tests Pending", "#{pendings} test#{ pendings == 1 ? ' is pending' : 's are pending'}", PENDING_IMAGE
      else
        notify "Tests Passed", "All tests passed", SUCCESS_IMAGE
      end
    end
  end
end

copie e cole o código ou faça o download aqui de um arquivo no formato do openoffice (o wordpress nao permite fazer o upload de qualquer tipo de arquivo) com o conteúdo descrito acima. Copie o conteúdo e cole em seu ~/.autotest.

Dica: Você pode personalizar as imagens, colocando o caminho de uma imagem da sua preferência, assim como eu faço na parte do código do .autotest que está comantada:

#  FAIL_IMAGE    = "~/Imagens/rails_fail.png"
#  PENDING_IMAGE = "~/Imagens/rails_pending.png"
#  SUCCESS_IMAGE = "~/Imagens/rails_success.png"

Feito isto, tive minhas notificações de teste funcionando perfeitamente como podem visualizar neste screenshot:

para fazer os testes, escreva-os, vá até o diretório do seu projeto e

$autotest

isto supondo que você já tenha o ruby e o rails previamente instalado e funcionando perfeitamente

obs o código original foi retirado daqui

Read Full Post »

Ubuntu Announce the new release stage of popular Ubuntu Linux
for now we can download a beta version for test purposes.

you can obtain more information here : Ubuntu Beta Release

Read Full Post »

Older Posts »