devlog

• No dia 2 de dezembro foi lançada a nova versão do Mercurial, a 1.1. Entre as novidades, compatibilidade com Python 2.6, maior conformidade com o padrão WSGI e o suporte a rebase através de uma extensão. Mais informações nas Notas de Lançamento.
• A ferramenta de buscas de código do google, o codesearch, ganhou suporte a repositórios no git e no mercurial no último dia 09. Agora é possível procurar lá coisas como do Mozilla, JDK e NetBeans, que são três softwares cujo repositório de código é gerenciado pelo mercurial. Mais no Blog do Google Code.
• O tópico do fórum do ohloh pedindo suporte ao mercurial é sempre movimentado. Nessa semana, começou um movimento espontâneo dos usuários, dizendo que fariam doações para que o mercurial fosse logo suportado pelo ohloh. Para a alegria dos usuários, Robin Luckey (um dos desenvolvedores do ohloh) apareceu na thread dizendo que nas próximas semanas ele vai trabalhar no código do ohloh para que o suporte a novos sistemas de controle de versão sejam adicionados de forma mais transparente.

Boas notícias para quem usa o mercurial para gerenciar seus códigos fonte!

Link: https://www.drproject.org/

Apesar da recente popularização de sistemas de controles de versão distribuídos como o git ou o mercurial, o svn ainda é a ferramenta mais popular para controle de versões. E junto com ele, quase sempre está o trac, que adiciona ao repositório um wiki, tickets e outras ferramentas para gerenciar o desenvolvimento.

Porém, a maior questão dos usuários com o trac é ter de subir uma instalação do trac para cada repositório. Não é uma tarefa muito difícil, mas convenhamos, podia ser mais fácil.

Pensando nisso, a Universidade de Toronto fez um fork do trac, adicionando a capacidade de múltiplos projetos. Entre as facilidades oferecidas, podemos citar, por exemplo, que criar um projeto no DrProject já cria o respectivo repositório.

Comparação

O DrProject era originalmente um fork do portal open source leve chamado Trac. Essa é a comparação dos dois hoje:

Segundo Jeff Balogh, o trunk dele é estável, com o desenvolvimento feito nos branches.

O projeto foi originalmente desenvolvido para uso no ensino. Numa troca de e-mail rápida com os desenvolvedores, perguntei no que isso se fazia presente no projeto. David Wolever me disse que o sistema de permissões é um reflexo disso, já que num projeto open source o acesso ao código não precisa ser restrito. Greg Wilson me falou a respeito das listas de e-mail integradas, e das operações em lote, como criar vários projetos com nomes sequenciais - que são úteis dentro de um ambiente de ensino.

A instalação do projeto foi parecida com a do trac, com a exceção que o DrProject espera que os repositórios estejam dentro dele, já que ele os administra. Numa tentativa de atualização, o meu banco de dados (sqlite) teve algum problema, mas logo depois o problema desapareceu. Sinais de que o projeto ainda tem muito o que andar, mas é uma boa pedida pra adicionar na lista de coisas a testar.

Creio que a primeira vez que li algo sobre controle de versão distribuído foi no blog do Thiago Arrais . Até falei sobre isso um tempo atrás .

Eu comecei a utilizar o mercurial. Daí, até descobrir o assembla, foi um pulo. Pensei em fazer um tutorial sobre o mercurial, mas sempre esbarrei na preguiça.

Então, veio a comunidade rails, com seu discurso de três letras: git, git, git! O Fábio Akita publicou um micro tutorial de git, e eu resolvi segui-lo, traduzindo os comandos para o mercurial.

Pra começar a história: nem todas as opções que o git suporta são suportadas pelo mercurial. Algumas são tratáveis pelo uso de extensões, outras estão planejadas para serem adicionadas no futuro.

Para começar, após instalar o mercurial, vamos fazer uma configuração básica e habilitar os plugins necessários. O arquivo é o .hgrc, no $HOME do usuário.

e o artigo .hgignore, que configura quais são os padrões de arquivos a serem ignorados.

Isso feito, vamos partir para a nossa exploração. Acompanhem junto com o artigo original do Akita. Nem tudo se traduz numa equivalência 100%, e tenho algumas considerações a fazer no final:

digo@ubuntu:~/devel/microformats_tests$ hg update -C default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

digo@ubuntu:~/devel/microformats_tests$ hg merge meufix
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

digo@ubuntu:~/devel/microformats_tests$ hg update -C working
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

# a rakefile for working with these microformats test files. Maintained by ryan king <ryan@theryanking.com>.
# tutorial mercurial

digo@ubuntu:~/devel/microformats_tests$ hg merge working
abort: outstanding uncommitted changes

digo@ubuntu:~/devel/microformats_tests$ hg merge -f working
3 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Ao criar um controlador em uma pasta que estava num repositório svn, ele já adicionou o controller ao repositório