Controlador de Versão

SubVersion – Uma Abordagem

Por um bom tempo eu fui meio reativo quanto a utilização do SubVersion como controlador de versão. Acredito que muita dessa reatividade tenha sido causada pela maçante utilização do Visual Source Safe (Microsoft) em diversos projetos, tanto Java como .Net.

De uns tempos para cá tenho lido bastante documento sobre o SubVersion e tenho mudado radicalmente minha visão sobre o produto, que além de ser muito bom, é Open Source.

A grande diferença entre ele (o SubVersion) e outros produtos como o Source Safe é que se você tem uma equipe de desenvolvimento de software e você precisa aumentar a produtividade das entregas, isso é bastante factível, tendo em vista que duas ou mais pessoas podem trabalhar no mesmo programa ao mesmo tempo. O que é uma grande diferença entre ele e outras ferramentas tipo Source Safe.

O Source Safe só permite que uma pessoa trabalhe em um determinado documento, enquanto ferramentas como o SubVersion permitem que diversas pessoas possam trabalhar ao mesmo tempo no mesmo documento e depois alguém se encarrega de fazer um “Merge” desses trabalhos executados em paralelo.

O Subversion é um sistema centralizado para compartilhar informações. Ele é em essência um repositório de dados que armazena informações de forma centralizada e que permite que várias pessoas possam então ler e escrever informações nesta base de dados.

Estou colocando abaixo uma imagem com o fluxo de trabalho que o SubVersion implementa na sua utilização. É tipicamente um modelo cliente/servidor, mas que contém mais funcionalidades e mais recursos para controle desse repositório.

A questão é que se temos um controlador de versão que bloqueia a edição de um determinado arquivo enquanto uma determinada pessoa está utilizando, podemos ter problemas com a produtividade da equipe, pois uma pessoa terá que esperar a outra terminar seu trabalho para começar a trabalhar.

Esse bloqueio criado por alguns controladores de versão, pode causar diversos problemas administrativos, pode causar problemas de serialização desnecessária, pois será necessário para cada alteração a criação de uma versão documento, e ainda pode causar uma falsa impressão de segurança.

O modelo implementado pelo SubVersion é chamado de Copy-Modify-Merge Solution, pois os membros da equipe baixam uma cópia do arquivo a ser atualizado para suas máquinas, modificam o arquivo e fazem merge do documento, ou seja, cada um atualiza sua parte dentro do documento através do SubVersion. Não há necessidade de esperar o colega terminar de trabalhar no documento para começar a utilizá-lo.

É importante comentar sobre a estrutura recomendada pelos criadores do SubVersion.

É recomendado que sempre que se crie um repositório do SubVersion, coloque na raiz do repositório a seguinte estrutura:

$ svn list file:///usr/local/svn/repos
/trunk
/branches
/tags

Trunk é o local onde estão armazenados os documentos que estão sendo editados, ou seja, onde estão sendo feitas as suas revisões. É o local principal para o desenvolvimento de um aplicativo, uma melhor definição seria o principal local de desenvolvimento, desde o início do projeto até o presente.

Branches é o local onde será armazenada uma cópia do código derivado de um determinado ponto do Trunk que será utilizado para aplicar grandes modificações no código, preservando a integridade do Trunk. Em outras palavras, é de onde poderá sair uma nova versão do seu produto. Se essas grandes modificações funcionarem de acordo com o plano, elas serão unidas ao Trunk para que o desenvolvimento possa se dar com essas modificações incorporadas.

Tags devem ser interpretadas como um momento no tempo no qual você deseja preservar tanto seu Trunk quanto seu Branch, normalmente imediatamente apos a disponibilização de uma determinada Release. As duas principais razões para gerar uma Tag são:

1 – Manter uma verão principal do software: ex. alpha, beta, RC or RTM.

2 –  Mante ponto mais estável do software antes de grandes revisões sobre o Trunk serem aplicadas.

Por hoje é só. Espero ter passado algum conhecimento sobre o assunto e poder contribuir de alguma forma para o entendimento do funcionamento do SubVersion.

Até a próxima.

Namaskar.