Archive for the 'controle de versão' Category

Por um controle de versão menos insano

Recentemente encontrei um texto do Jeff Atwood sobre a instalação do Subversion. Ele tem alguns argumentos bastante interessantes sobre controle de versão (sempre use controle de versão, faça modificações pequenas e blá, blá, blá…) que me parecem em geral bastante acertados, mas uma coisa me chamou a atenção: por que um programador (que pelo menos parece) tão bem informado quanto ele ainda escolhe um sistema de controle de versão tão completamente insano quando já existem tantas alternativas mais naturais para qualquer ser humano?

A maioria dos sistemas da velha guarda incrementa algum tipo de contador para identificar cada versão do objeto controlado: o Subversion, por exemplo, gera números de revisão quando há modificações em alguma parte da árvore de diretórios e o CVS associa um identificador seqüencial a cada um dos arquivos controlados. O maior problema do versionamento seqüencial é que simplesmente não controla o que queremos que controle. Saber quantas vezes um item qualquer foi modificado é útil, mas não tão útil quanto saber quais foram as modificações e, ainda melhor, quais as dependências entre elas. Sim, é bastante interessante saber qual o estado final de um trecho de código após um certo número de transformações, mas me interessa muito mais saber o que cada uma dessas modificações faz e tratar as modificações como objeto de trabalho, não os resultados delas.

Mais do que quantas modificações aconteceram desde algum ponto qualquer do tempo, eu preciso saber se a segunda modificação pode ser aplicada sem a primeira, se a terceira é uma inversão da primeira ou se a quinta desfaz algumas coisas que a quarta fez. As respostas para todas estas perguntas são necessárias para a operação mais fundamental do controle de versão: o merge.

Quando o Subversion surgiu, lá pelos idos de 2004, um de seus maiores argumentos era o branch barato. Este com certeza é um bom recurso para se ter, afinal de contas derivações precisam ser criadas o tempo todo. Mas o que queremos mesmo é que o merge seja fácil. O branch é só o começo da história. O merge é o ponto alto do processo, é quando as contribuições dos vários envolvidos são combinadas e passam a (pelo menos tentar) funcionar em conjunto. Há uma palestra em que Linus Torvalds resume isto muito bem em algumas poucas palavras: “branches são completamente inúteis, a não ser que você faça o merge”. Só que o versionamento seqüencial pára no branch e o merge precisa ser feito de forma manual porque o sistema não enxerga as dependências entre as alterações, só sabe qual delas aconteceu antes ou depois. Você pode conseguir ajuda para comparar duas versões do mesmo conteúdo, mas é você quem tem que saber quais devem ser as duas versões para este merge em particular que você quer fazer. A coisa fica ainda mais complicada quando você precisa importar modificações de outro branch periodicamente. Quando, por exemplo, seu projeto tem um branch estável em que só se faz conserto de bugs e outro — ou outros — em que são desenvolvidos novos recursos e que precisa receber as mesmas modificações que o estável para se manter livre de bugs. As pessoas acabam desenvolvendo algumas soluções arcanas para controlar manualmente quais alterações já foram aplicadas a quais linhas de desenvolvimento, coisa que o sistema de controle de versão podia (e deveria) fazer sem precisar de babá.

Os identificadores seqüenciais precisam ser atribuídos por algum tipo de servidor central. Não podem ser determinados por máquinas diferentes para evitar conflitos de nomes e acabam sendo completamente artificiais porque refletem simplesmente a ordem em que o servidor recebeu as alterações. Para a maioria das alterações, a ordem de aplicação pouco importa. E quando ela importa, os sistemas com versionamento seqüencial não costumam ajudar.

A alternativa ao controle seqüencial é o controle de patches (termo que admito estar inventando agora, então não deve ser muito preciso e provavelmente você vai encontrar isto com outro nome por aí). Um sistema de controle de patches associa um identificador a uma modificação, não ao resultado dela como os de controle seqüencial. Uma versão qualquer é simplesmente um acumulado de modificações que, quando combinadas, determinam um resultado final.

Sistemas seqüenciais são necessariamente centralizados. Não há como decidir qual o número para a próxima versão se não houver uma autoridade central para controlar a numeração. Porém, o inverso não é verdadeiro. Isto é, sistemas baseados em controle de patches não precisam ser distribuídos. A maioria dos que encontramos realmente é, mas não precisavam ser. A questão é que eles podem ser muito bem usados como sistemas centralizados, mas já tem tudo que precisam para serem distribuídos e independentes de um servidor central. Então porque se limitar? Além de poderem fazer tudo que os centralizados conseguem, os sistemas distribuídos ainda costumam ser muito mais fáceis de instalar. Se o Atwood tivesse escolhido um deles, não precisaria nem escrever um tutorial de instalação para si próprio. Era só escolher inicializar um diretório qualquer como repositório e começar a versionar o que quisesse. Sem serviços. Sem nomes de usuário. Sem senhas. Sem dores de cabeça com o firewall.

Minha impressão é que o funcionamento dos sistemas distribuídos de hoje é muito mais parecido com o modo como naturalmente pensamos do que o dos centralizados. Quando quisesse combinar duas linhas de trabalho distintas eu deveria apenas dizer a meu sistema que quero combinar as modificações que eu tenho com as que meu colega tem e ele deveria ser capaz de fazer isso sozinho (assumindo que não haja conflitos complicados). Eu não deveria precisar criar marcadores artificiais e manter manualmente um histórico de quais alterações dele eu já tenho. Por que algumas vezes ainda insistimos em usar sistemas centralizados? Há alguma vantagem oculta neles ou o quê?

Anúncios

Sobre grandes alterações pequenas

Qual é a granularidade das modificações que você envia ao seu sistema de controle de versão? Você se limita a modificações pequenas (que mudam o nome de uma varíavel ou outra, por exemplo) ou gosta das mas volumosas (como as que mudam o nome de uma rotina, introduzem um parâmetro novo e ainda corrigem um defeito em um pedaço do código que a chamava)?

Não é uma pergunta retórica. Pode responder. O espaço para comentários ali embaixo serve exatamente para isso.

Quando envio patches para algum projeto, tento torná-los tão pequenos e localizados quanto possível. Eu sei que não é uma experiência muito agradável revisar modificações monstruosas que afetam toda a base de código e tento poupar disso os mantenedores dos projetos para os quais colaboro. Eles são programadores, mas também são gente.

Não é tão raro que uma parte das modificações em um patch sejam aceitas e outras não. Caso o patch enviado seja muito extenso, o mantenedor vai ter um bocado de trabalho para separar as partes boas das ruins. Se ele tiver muitas outras preocupações no dia (o que não é nada incomum), pode ser que ele simplesmente recuse todo o patch, apesar de haver mudanças úteis, só para poupar o trabalho de filtragem. Para quem está contribuindo, certamente é melhor que as modificações sejam aceitas e um conjunto de patches pequenos torna as chances disso acontecer muito maiores do que um único patch grande. Nem todo patch que enviamos é aceito e precisamos conviver com isso. Modificações pequenas e localizadas ajudam muito quando algumas delas precisa ser rejeitadas.

Patches pequenos costumam ser mais ortogonais e fazem muito sentido no contexto colaborativo de um projeto de código aberto, principalmente com sistemas de controle de versão distribuídos. Mas ainda existem sistemas centralizados e — pior — cuja única solução para edição concorrente é usar travas para tentar tornar o desenvolvimento serializado e impedir toda e qualquer tentativa de paralelismo. Como se este cenário não fosse suficientemente ruim, alguns sistemas não suportam commits com múltiplas modificações e obrigam todo mundo a registrar alterações arquivo por arquivo, mesmo que toquem em muitos pontos. Para terminar imagine que a única forma de interação da equipe com a ferramenta de controle de versão seja um cliente gráfico com interface do século passado e dificilmente automatizável.

É serio mesmo, essas coisas ainda existem.

E tem gente que precisa usá-las.

Quando o mundo conspira contra você com tanta intensidade, fica mais difícil resistir à tentação de fazer uma modificação monstruosa com um comentário altamente descritivo como “Modificações do código”. Porém, mesmo quando estou em algum ambiente parecido com este, ainda tento fazer modificações pequenas. Não faço alterações tão pequenas como quando estou usando Darcs e vez ou outra combino duas ou três modificações em uma, mas sempre evito registrar uma alteração que resolva mais de um defeito ou melhoria.

Parece haver um certo conflito entre commits localizados e implementação de recursos. A renomeação de uma rotina, por exemplo, pode ser um dos passos que leva à inclusão de uma nova funcionalidade, mas com certeza não vai resolver a bronca sozinha. As funcionalidades precisam de modificações maiores, mas modificações menores são mais fáceis de entender, revisar e reverter. Será que este conflito real ou apenas um produto da nossa imaginação?

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.