Versionamento, parte 2

Como prometido, segue a parte dois do post sobre versionamento.

Sistemas de versionamento

Eu disse que haviam várias ferramentas disponíveis, e por causa disso, não me estenderei demais nessa parte, mas citarei as principais com as quais eu já tive alguma experiência.

As ferramentas distinguem-se entre dois grandes grupos. As ferramentas de versionamento centralizadas e aquelas distribuídas. No final, todas acabam possuindo um servidor central para disponibilizar os arquivos do projeto, mas existe uma diferença sutil na utilização desse servidor.

Nas ferramentas centralizadas, o servidor é o mais importante. Todas as modificações são feitas com relação a ele. Sem acesso ao servidor, simplesmente não há como trabalhar, a não ser realizando modificações locais e depois enviando tudo de uma vez para o servidor quando esse estiver disponível.

Nas ferramentas distribuídas, o foco está nos programadores. O servidor é apenas um ponto de junção para todos os membros do projeto, mas o projeto pode continuar a evoluir em ele. Os programadores podem realizar commits locais caso o servidor não esteja disponível e depois enviar todos os commits de uma vez. A diferença aqui é que, enquanto no caso anterior todas as modificações formaram um único commit, e nesse caso cada modificação gerou o seu próprio commit com seu próprio comentário, tornando muito mais fácil rastrear as modificações e realizar um futuro merge do projeto.

Só para esclarecer, as boas práticas de versionamento determinam que um commit é uma unidade lógica de trabalho. Ele pode representar uma correção de um erro, uma funcionalidade nova ou uma melhoria. Ele também não está restrito a um único arquivo.

Um merge é a incorporação de commits no projeto principal. Quanto mais fragmentado e melhor separado os commits, mas fácil será juntá-los ao projeto principal.

Centralizadas: CVS e SVN

O modelo de versionamento centralizado foi o primeiro que surgiu, junto com as primeiras ferramentas. Desse grupo, vale a pena destacar o CVS e o SVN.

CVS ou Concurrent Version System (Sistema de Versões Concorrentes) foi um dos primeiros a surgir, já não é o melhor que existe, mas ainda está em funcionamento em muitos lugares, talvez pela simplicidade, talvez por ter chegado primeiro e muitos estarem acostumados com ele, além de existir extensões e plugins para inúmeras ferramentas de desenvolvimento, que incorporam o CVS dentro da ferramenta.

O sucessor do CVS é o SVN ou Subversion. Ele trabalha no mesmo princípio do CVS mas traz muitas melhorias. Atualmente é um dos principais sistemas de versionamento que exite e inclusive possui diversos sites fornecendo hospedagem gratuitas para projetos usando o SVN, como o google. A maioria dos sites que fornecem hospedagem gratuita fazem isso apenas para projetos de software livres mas há alguns que permitem desenvolvimento privado, como o Project Locker.

Distribuídas: Mercurial, git, etc

Dentre os modelos distribuídos, posso citar o Mercurial, GIT ou Bazaar como os principais. No caso do GIT, além do Project Locker, existem serviços como o Git Hub e o Gitorious que também permitem o cadastro de projetos que sejam livres.

Recentemente tenho trabalhado com o Mercurial e tenho tido boas experiências. Uso o serviço Bitbucket que permite projetos tanto livres como privados. Em sua última atualziação, o Bitbucket também passou a oferecer hospedagem para progetos em GIT.

Além do suporte de versionamento esses sites costumam também disponibilizar uma wiki e uma página especial para reportar bugs para o seu projeto.

Algumas dicas

Você não precisa usar as ferramentas de versionamento no terminal (apesar de que, com a prática, vai parecer mais simples). No caso do SVN no windows você pode usar o TortoiseSVN, que cria no menu do windows explorer um menu para realizar as tarefas de versionamento.

No caso do Mercurial existe o TortoiseHg, tanto para Windows, Linux ou Mac, que também é uma ferramenta visual. Se você está usando alguma IDE, é bem possível que existam plugins para ela que facilitem o uso de versionamento.

Para o GIT, no windows, existe a possibilidade de usar o TortoiseGit.

É possível versionar qualquer tipo de arquivo. Imagens, binários, documentos além dos arquivos de código fonte. O problema é que a ferramenta só consegue calcular as alterações entre duas versões em arquivos de texto puros, como os códigos fontes. Ao versionar um arquivo que não é um texto puro, a ferramenta verá que a data de modificação do arquivo é maior que a data da ultima versão, então ele substitui a versão anterior pela mais nova. Na prática, ele está só criando novas cópias, o que não é um uso muito inteligente de espaço no servidor, mas quebra um bom galho.

Conclusões

Versionar é mais importante do que parece. Infelizmente, só sentimos falta dele quando surgem os problemas. Através do versionamento fica mais fácil controlar as mudanças, distribuir patches e trabalhar de forma colaborativa. A prática do versionamento já está bem madura no mundo e é possível encontrar diversas ferramentas e tecnologias para atender as mais diversas necessidades.

Mesmo sem o uso de alguma ferramenta própria, também é recomendável adotar o uso de versões no nome dos arquivos, principalmente se eles podem mudar e você vai distribuí-los. Por exemplo, você tem o trabalho_de_historia.odt no seu computador e vai enviá-lo para o seu grupo para esse avaliar o resultado. Haverão sugestões você mudará algumas coisas, alguém mudará algumas coisas e, no final, você precisa mandar o trabalho pra professora e você tem três arquivos trabalho_de_historia.odt espalhados no seu computador, um na pasta downloads, um na documents e um na sua pasta de trabalhos. Qual é o mais recente para você entregar a professora?

A dica é use um nome como trabalho_de_historia_v1.odt no seu documento e incremente esse valor sempre que o arquivo for alterado, dessa forma, pelo nome do arquivo, você sempre saberá qual é o mais recente.

Att,