Artigos Java Controles de Versão para Projetos Java

Introdução

Todo o projeto de média ou alta complexidade necessita de um software para controle de versão. Até mesmo projetos pequenos sofrem com a falta desse tipo de aplicativo. Praticamente qualquer desenvolvedor já trabalhou com um sistema de controle de versão, é praticamente impossível fazer isso com trocas de arquivos por e-mail ou outras forma semelhantes.

Em ambientes de desenvolvimento de projetos de médio a grande porte é muito comum vários programadores manipulando ao mesmo tempo um determinado arquivo, às vezes o mesmo arquivo. É nesse momento que o controle de versão é útil para auxiliar nesse processo. Além de controlar as alterações o controle de versão também ajuda na mesclagem de códigos e na resolução de conflitos.

Alguns dos problemas encontrados em sistemas que não utilizam controle de versão são:

  • Sobrescrita de código de uma outra pessoa por acidente na qual acabou-se perdendo as alterações feitas.
  • Dificuldades em saber quais alterações foram feitas num determinado código.
  • Dificuldades em saber quando foram feitas as alterações.
  • Dificuldades em saber quem fez uma determinada alteração.
  • Dificuldades em recuperar o código de uma versão anterior.

Portanto, o controle de versão apoia o desenvolvimento através de Históricos nos quais registra-se toda a evolução do projeto, todas alterações sobre cada um dos arquivos do projeto permitindo saber o que, quando e onde foi feita uma determinada alteração. Além dos Históricos o controle de versão ainda auxilia a Colaboração onde possibilita-se o trabalho paralelo de vários desenvolvedores sobre um mesmo arquivo sem que tenha perigo de um sobrescrever as alterações do outro. Por fim, o controle de versão auxilia nas Variações que ocorrem num projeto na qual matem-se linhas diferentes de evolução do mesmo projeto, dividindo-o em diferentes versões de um mesmo projeto.

Os plugins existentes para Eclipse e Netbeans ajudam a trabalhar com os controles de versão, exibindo os históricos, alterações do código, criação de versões, etc.

O controle de versão é composto de duas partes: o repositório e a área de trabalho. O repositório armazena todo o histórico de evolução do projeto, onde registram-se todas as alterações feitas em cada item versionado. No entanto, os desenvolvedores não trabalham diretamente nos arquivos do repositório, mas sim através de uma "cópia de trabalho" que contém a cópia dos arquivos do repositório e que é monitorada para identificar as mudanças realizadas. Essa área é individual e isolada das demais cópias de trabalho.

Por fim, tem-se dois tipos de controles de versão, são eles:

Controle de Versão Centralizado: existe apenas um único repositório central mas várias cópias de trabalho, uma para cada desenvolvedor. A comunicação entre uma cópia de trabalho e outra passa obrigatoriamente pelo repositório central. Exemplo desse tipo de controle de versão é o SVN e o CVS.

Controle de Versão Distribuído: são vários repositórios autônomos e independentes, um para cada desenvolvedor. Cada repositório possui uma cópia de trabalho acoplada e as operações commit e update acontecem localmente entre os dois. Exemplos desse tipo de controle de versão são o GIT e o Mercurial.

Atualmente existem três principais controles de versão utilizados no mercado corporativo, são eles CVS, SVN e GIT.

Todos eles serão melhor avaliados abaixo.

Principais ferramentas de controle de versão

Figura 1: Principais ferramentas de controle de versão

CONCURRENT VERSIONING SYSTEM (CVS)

O CVS foi criado em 1986 e está instalado em diversas partes. Embora antigo, o CVS ainda é muito utilizado, possuindo como um dos seus grandes clientes para plataforma Windows o Tortoise CVS. O CVS também é utilizado em diversos IDEs como Eclipse e Netbeans.

O CVS armazena os arquivos em um repositório central acessível para todos os usuários que possuem permissão de acesso. Esse sistema de controle de versão possui alguns comandos importantes e muito utilizados. O comando "check out" armazena uma cópia do repositório para a área de trabalho do usuário, o comando "Commit" permite armazenar um arquivo modificado no repositório, o comando "Update" atualiza a cópia local do desenvolvedor com as modificações feitas por outros usuários no repositório. Outros comandos importantes do CVS são o “Branch” que permite a criação de diferentes versões do sistema e o "Merge" que é usado sempre que alguém altera o código. Ressalta-se que quando for feito o merge é necessário realizar um comando Update antes do Commit, de modo que seja feito o merge — ou a fusão — das mudanças. Um exemplo simples de um merge é quando dois usuários modificaram o mesmo arquivo e precisa-se unir as duas modificações de modo que o arquivo fique único, ou seja, que não se perca nenhuma das modificações realizadas.

O Branch é muito utilizado em sistemas grandes, pois, se alguma versão estiver com algum problema grave que esteja impedindo a operação normal do sistema em produção, pode-se facilmente voltar para a versão anterior até averiguar qual alteração provocou impacto.

SUBVERSION (SVN)

O Subversion, mais conhecido como SVN, é o sistema de controle de versão com maior número de aprovações entre os existentes. É muito utilizado em projetos de software corporativos e grandes projetos Opensource como SourceForge, Apache, Ruby e diversos outros. Para usuários de Windows o Tortoise SVN é uma excelente opção. O SVN também é amplamente utilizado nos IDEs como Eclipse e Netbeans. O SVN é considerado um substituto do CVS procurando eliminar algumas limitações dessa ferramenta.

No Subversion, os arquivos não têm versões independentes. Todos os arquivos são parte de uma mesma revisão, e a modificação de um único arquivo altera a revisão de todos. O Subversion utiliza o conceito de Branches, Tags e Trunk.

Trunk é uma pasta que contém os projetos que estão em desenvolvimento. Todas as atualizações efetuadas no dia-a-dia são armazenadas na pasta Trunk. É como se fosse o HEAD do CVS. Branches é uma pasta que contém as “linhas de desenvolvimento” de um projeto, onde entre cada uma dessas linhas de desenvolvimento existem diferenças, ou seja, para cada Branch tem-se diferentes versões de um projeto. Quando esta versão está pronta, migram-se a pasta Trunk para a pasta Branch e assim é dado um nome para esta versão. O Branch deve ser congelado e não sofrer mais alterações, apenas correções se for necessário. Isso é importante inclusive se quisermos voltar uma versão atrás no caso em que uma versão em desenvolvimento está enfrentando algum problema que levará um certo tempo para ser arrumado. Outro conceito é o de Tags que é considerada apenas uma variação de um Branch, e na prática é exatamente como um Branch, apenas uma cópia da ramificação atual da árvore. A Tag é como se fosse uma versão liberada para o cliente após um Branch estar completo. Essa é a pasta que deve ser empacotada e enviada para o cliente.

Outros comandos utilizados é o Update, Commit e Checkout assim como no CVS.

GIT

O GIT tem sido considerado o novo controle de versão da moda. Foi inicialmente desenvolvido pelo criador do Kernel do Linux Linus Tolvards. A grande diferença do GIT em relação ao SVN e o CVS é que este não se baseia em uma base centralizada de código. No GIT diferentes pontas detêm partes diferentes do código, enquanto que o SVN e o CVS utilizam um controle centralizado, ou seja, apenas uma cópia original do software é utilizada.

O GIT é rápido e eficiente utilizado pelo Kernel do Linux, Fedora e diversos outros.

Cada desenvolvedor que possui o GIT no seu ambiente de desenvolvimento possui um repositório com todos os históricos e habilidade total de controle das revisões, não dependente de acesso a uma rede ou a um servidor central.

O desenvolvimento do GIT começou em 3 de Abril de 2005. A primeira mescla de arquivos (Merge) de múltiplos “ramos” (Branches) foi realizada em 18 de Abril. Torvalds alcançou seus objetivos de performance em 29 de Abril, o recém-nascido Git se tornou referência ao registrar patches para o Linux com altas taxas em performance. No dia 16 de Junho, a entrega do kernel 2.6.12 foi gerenciada pelo GIT.

Mesmo que fortemente influenciado pelo antigo controle de versão BitKeeper, Torvalds deliberadamente tentou evitar abordagens tradicionais, levando a um design único. Tolvards considera o CVS um péssimo controle de versão e o SVN pior ainda, pois segundo ele o SVN veio para corrigir defeitos do CVS que por sua vez são incorrigíveis e somente uma outra abordagem criaria um verdadeiro sistema de controle de versão. Ele desenvolveu o sistema de controle de versão GIT até que fosse possível sua utilização por usuários técnicos, entregando então a manutenção do software para Junio Hamano, um dos principais colaboradores do projeto. Hamano foi responsável pela entrega da versão 1.0 em 21 de dezembro de 2005, e continua como responsável pela manutenção do GIT.

O projeto do GIT é fruto da experiência de Torvalds com a manutenção do desenvolvimento altamente distribuído do projeto do Linux aliado com todo o seu conhecimento de performance de sistemas de arquivos e a necessidade urgente de produzir um sistema funcional em um curto espaço de tempo. Todas essas influências levaram Tolvards a fazer diversas escolhas de implementação do GIT como Desenvolvimento Distribuído (cada desenvolvedor com a sua cópia local das mudanças e do histórico de desenvolvimento), Suporte consistente para desenvolvimentos não lineares (rápidas criações de Branches e Merges com ferramentas específicas para isso), eficiência em projetos grandes (a performance é uma ordem de magnitude maior que os outros controles de versionamento, permanecendo rápido até quando o histórico cresce), entre diversas outras escolhas que formaram o GIT.

Utilização nos Projetos

Ultimamente o GIT se tornou o sistema de controle de versão mais popular para os projetos da Fundação Eclipse. O número de projetos controlados por repositórios GIT ultrapassou o número de projetos que utilizam CVS e SVN. Essa transição dos projetos da Fundação Eclipse começou após o lançamento do Eclipse Indigo. Um dado importante é que hoje tem-se pouco menos de 40% dos projetos da Fundação Eclipse sendo controlados pelo CVS, que além disso foi marcado como obsoleto pela Fundação Eclipse. Assim, o CVS é utilizado apenas para controlar projetos mais antigos da Fundação Eclipse. Há uma séria expectativa que os projetos CVS sejam completamente desabilitados depois do lançamento do Eclipse Juno.

Outro dado interessante é que o SVN hoje representa cerca 20% dos projetos do Eclipse, porém sempre foi muito mais utilizado que o CVS. A mudança desse quadro se deve ao fato que a importação de projeto SVN para GIT é bastante simples, portanto a maioria dos projetos que eram controlados pelo SVN já foi migrada para o GIT. Vale ressaltar que a migração de um projeto CVS para outro repositório é algo bastante complicado devido a quantidade de arquivos de administração do repositório.

O anuncio recente do Google que vai suportar o GIT aumentou ainda mais o número de projetos controlados pelo GIT.

No mercado corporativo ainda tem-se visto um uso relativamente muito alto do SVN, muitos ainda consideram um controlador de versão bastante superior ao seu antecessor e aos demais. O CVS ainda possui alguns problemas não resolvidos principalmente na questão dos merges onde podem ocorrer sérios problemas. No entanto, aos poucos o GIT vem tomando conta, principalmente devido ao seu propósito de trabalhar bem com equipes distribuídas que é o que vem mais crescendo no mundo globalizado atual.

Conclusão

Neste artigo procurou-se descrever o que são os controles de versão e como eles podem ajudar em projetos de desenvolvimento. Além disso, descreveu-se cada um dos controles de versão mais utilizados atualmente, procurando posicionar o leitor no propósito de cada um deles e o que eles oferecem. Por fim, analisou-se como eles estão sendo utilizados por projetos importantes como os Open source e os projetos corporativos.

Bibliografia