Controle de versão distribuído se distribui

Talvez eu simplesmente tenha pegado o trem tarde demais e estou vendo como novidade o que os veteranos veriam como normalidade, mas tem algo que venho observando há algum tempo. Não vou chamar de tendência para não arriscar queimar a língua no futuro, mas é no mínimo curioso.

Você tem notado como os sistemas de controle de versão distribuídos estão mais comuns?

Há um ano e meio nós no projeto EclipseFP estamos usando um sistema distribuído chamado Darcs. Ele vem se tornando um tipo de padrão de fato na comunidade Haskell porque é escrito em Haskell. Apesar do nosso projeto (ainda) não ser totalmente escrito em Haskell, em geral é uma boa idéia para um ambiente de desenvolvimento se distanciar o mínimo possível da sua comunidade. A escolha então foi óbvia.

Isto não prova muita coisa. Estou falando do meu próprio projeto, afinal de contas. Mas tem mais. A menos que você estivesse em algum tipo de caverna em um planeta distante da Terra durante os últimos dois anos, você já ouviu falar no Ubuntu. Eles também usam um sistema de controle de versão distribuído, o Bazaar-NG (também conhecido por bzr). Outro projeto do qual você talvez já tenha ouvido falar que usa controle de versão distribuído é o Linux. Eles usam o git, que foi originalmente escrito por Linus Torvalds para ser usado no desenvolvimento do seu kernel. Há até um espelho Darcs do repositório deles. Como se não bastasse há ainda os boatos sobre a versão 2.0 do Subversion (conhecido também pela alcunha svn) ser distribuída.

Mas o que me chamou a atenção foi um pequeno detalhe da decisão da Sun de abrir o código de Java semana passada. Passaria totalmente desapercebido se não fosse minha interminável lista de feeds e seu inesgotável estoque de artigos interessantes. Acontece que eles também vão passar a usar mais um sistema de controle de versão distribuído. O nome dele é Mercurial. hg para os íntimos.

A pergunta de um milhão de dólares (ou de um milhão de olhos, como vou tentar mostrar) é: por que eles estão fazendo isso?

Com controle de versão distribuído, cada cópia de trabalho é um repositório completo. Ou seja, cada desenvolvedor ou curioso que queira acompanhar o projeto tem o histórico de modificações ao código-fonte armazenado localmente. Há dez anos não era todo mundo que tinha 40GB de memória de armazenamento disponível e fazia sentido recorrer a um servidor central para armazenar o histórico de um projeto. Hoje as pessoas podem se dar ao luxo de armazenar o histórico do Linux (hoje com mais de 300MB) sem problemas.

Tecnicamente não é necessário haver algo como um repositório central quando se usa controle de versão distribuído. Não há uma hierarquia de repositórios, cada um é independente dos demais. Se eu e você estamos trabalhando em um mesmo projeto, podemos fazer modificações separadamente o tanto quanto quisermos e ambos terão o mesmo poder sobre seu repositório local. Ambos poderão gravar alterações, desfazê-las e consultar o histórico do projeto como quiserem sem precisar saber o que acontece com o repositório do outro. Se quisermos, podemos mesclar os dois repositórios para sincronizá-los e isso faz muito sentido se estivermos realmente trabalhando no mesmo projeto. Como esta operação costuma ser freqüente, as pessoas em geral elegem um dos repositórios como central. Elas passam a enviar suas alterações para lá quando estão prontas para publicação e consultá-lo quando precisam atualizar suas cópias locais. Mas só porque escolheram fazê-lo. Não há nenhuma limitação do sistema que as obrigue a fazer isso.

Isto facilita muito a vida tanto de quem quer contribuir com patches como de quem precisa gerenciá-los. Se você fez uma modificação no código de algum projeto, tudo que você precisa é fazer um mini-fork fazendo uma cópia local do repositório e gravar sua alteração. Mais tarde, quando o corpo de código principal for modificado, o sistema vai se encarregar de juntar tudo sozinho. Com controle centralizado você precisa convencer os mantenedores que o seu patch é importante para que eles o integrem ao código principal ou se contentar em refazer as modificações a cada revisão. Claro que você vai gravar seus patches localmente para facilitar, mas as coisas podem ficar bem cabeludas se você tiver muitas alterações.

Ter um repositório completo local significa também que você pode gravar modificações intermediárias. Todo mundo faz besteira de vez em quando e é bom poder saber que há algo mais que a função de desfazer do editor para te proteger. Quando podem as pessoas tendem a fazer modificações menores e detalhar melhor seus comentários. Ao mesmo tempo que o colaborador externo tem mais controle sobre suas alterações, o mantenedor ganha um histórico de versões mais limpo, livre de revisões gigantescas.

Toda a razão para disponibilizar seu código-fonte livremente é poder contar com a força de uma comunidade. Quanto mais gente vir o código, melhor ele vai poder ficar. Patches são um dos maiores desejos de qualquer mantenedor de um pedaço de código e controle de versão distribuído facilita a vida deles e de quem quer contribuir. Quando se quer atrair contribuições, diminuir as barreiras para quem quiser contribuir não faz mal a ninguém e é justamente isso que a Sun está tentando fazer agora com o OpenJDK.

5 Responses to “Controle de versão distribuído se distribui”


  1. 1 Rodrigo Araujo 24/nov/2006 às 20\0843

    Fala Arrais, fiquei curioso para saber porque você mudou de casa. :)

    Muito interessante este post, trabalho diretamente com SCM e ainda não tinha despertado para essa “onda” de controle de versão descentralizado. É uma ideia bem interessante, porém é preciso um time muito bem treinado para que se possa extrair todo o potencial dessa distribuição! O que ainda vejo muito acontecer por ai é o uso de controle de versão “serializado”, onde cada desenvolvedor só pode editar um arquivo se outro não estiver fazendo no mesmo tempo :)

    Outro uso muito interessante para esses sistemas distribuídos é para equipes separadas geograficamente. Atualmente a solução líder de mercado de repositórios remotos é o ClearCase Multisite da IBM/Rational, mas é uma ferramenta com carga administrativa pesadissima e cheia de problemas ainda. Isso sem nem falar dos custos do licença!

    Parabéns pelos artigos sempre interessantes.

    Abraços,
    Rodrigo

  2. 2 thiagoarrais 25/nov/2006 às 11\1152

    Interessante é que pesquisando mais sobre o assunto Sun/Java/DRCS (que quer dizer Distributed Revision Control System), descobri que eles usavam um sistema distribuído. Era um sistema desenvolvido e comercializado pela Sun chamado TeamWare já com alguns anos de existência. É uma evidência de que sistemas distribuídos podem funcionar também para um modelo menos aberto.

    Mas é claro que a adoção deste modelo ainda vai esbarrar nos controles de versão serializados da vida. E o pior é que isto não é tão raro quanto deveria ser. Sem falar em quem não usa controle de versão nenhum

  3. 3 Fred Maranhão 29/ago/2007 às 12\1225

    O problema do controle de versão serializado é o medo do novo. Mas não o medo da nova tecnologia, e sim o medo das novas idéias, das novas formas de trabalhar, de uma nova forma de encarar um problema.

    Pela minha experiência com profissionais competentes que tem medo de controle de versão concorrente (e não serializado), o problema se passa pela falta de treinamento.


  1. 1 Walter Cruz - devlog Trackback em 22/ago/2007 às 01\0138
  2. 2 Sobre grandes alterações pequenas « Mergulhando no Caos Trackback em 29/ago/2007 às 13\0117
Comments are currently closed.




%d blogueiros gostam disto: