prefix = o />
Mais controle no desenvolvimento em equipe
O CVS – Concurrent Versions System – não é escrito em Java, mesmo assim ocupa posição de destaque em nossa comunidade. Um software de controle de versões é um componente obrigatório para qualquer projeto de desenvolvimento sério. Quem nunca utilizou o CVS, ou um software similar, não sabe o que está perdendo.
IDEs livres, como o Eclipse e o NetBeans – além de várias ferramentas proprietárias, como o JBuilder e o IDEA – fornecem integração nativa com o CVS. Grandes projetos livres, tais como o próprio Eclipse, JBoss, Tomcat, Apache Httpd, Gnome e MySQL, são baseados na infra-estrutura fornecida pelo CVS, da mesma forma que as maiores incubadoras de software livre: SourceForge, Tigris e Savannah.
A finalidade de um sistema de controle de versões é gerenciar o repositório de código de um projeto de software, fornecendo controle, por exemplo, sobre qual desenvolvedor está trabalhando em que módulo, qual o histórico de mudanças para cada módulo, e possibilitando a integração automatizada das modificações realizadas por diferentes desenvolvedores sobre o mesmo módulo.
Em suma, sistemas de controle de versões eliminam o velho problema de um programador sobrescrever o mesmo arquivo-fonte que havia sido editado por outro, levando à perda das modificações realizadas pelo segundo. Esses sistemas também permitem aos programadores maior liberdade de experimentar novos algoritmos e novas arquiteturas, testar estratégias radicais para a solução de um problema, ou incluir novas funcionalidades – pois caso a linha de trabalho escolhida se mostre um “beco sem saída”, basta pedir ao sistema para que retorne o projeto a uma situação anterior, estável.
O CVS, como indicado, não é o único software nesta área. Entre os projetos livres, temos, por exemplo, o Subversion; entre os proprietários existem o ClearCase da IBM/Rational, PVCS da Merant, Visual SourceSafe da Microsoft e StarTeam da Borland.
A maioria das ferramentas de desenvolvimento Java posicionadas como “enterprise” inclui um sistema de controle de versões embutido, ou possui recursos para integração com sistemas de terceiros. Mas, da mesma forma que vem acontecendo em outras áreas, o software livre tem se mostrado de tanta qualidade, que vem levando empresas tradicionais a descontinuarem seus produtos concorrentes.
Certamente, o leitor gostará de saber que o CVS, embora não escrito em Java, é multiplataforma. Há servidores para todos os sistemas Unix do mercado (Linux, AIX, Solaris etc.) e para Windows, e há clientes para praticamente todas as plataformas conhecidas (além de alguns 100% Java).
Controle de versões para a internet
O CVS segue alguns princípios bastante diferentes de outros softwares similares. Por exemplo, ele não requer que sejam estabelecidas travas (locks) sobre os módulos sendo modificados. Vários desenvolvedores podem trabalhar simultaneamente no mesmo módulo – o CVS cuida de integrar as modificações ou de indicar onde as modificações entram em conflito.
Dessa forma, é viabilizado o estilo de desenvolvimento altamente descentralizado utilizado por grandes projetos de software livre ou em grandes sistemas corporativos, onde desenvolvedores podem estar em diferentes continentes. O histórico mantido pelo CVS garante que seja possível revisar (e reverter, se for o caso) qualquer mudança. Pode-se, ainda, restringir, a grupos específicos, os direitos de registrar mudanças em certos módulos. Portanto, o CVS mantém o controle gerencial sobre um projeto de software.
Por outro lado, caso houvesse necessidade de comunicação constante entre os membros da equipe para obter acesso a travas, seria inviável a participação de desenvolvedores independentes, cada um no seu próprio ritmo.
É possível também ter desenvolvedores que trabalham desconectados do CVS. Eles modificam uma “fotografia” (snapshot) do repositório para depois gerar um patch contendo as modificações realizadas. Este é enviado para um desenvolvedor com acesso ao CVS, que faz uma avaliação e decide incorporar ou não as modificações. É assim, por exemplo, que projetos de software livre aceitam colaboradores ocasionais.
O “Concurrent” no nome CVS vem da possibilidade de se criar linhas de desenvolvimento paralelas ou branches. É uma necessidade muito comum em softwares criados para distribuição externa (em oposição aos desenvolvidos apenas para uso interno).
Por exemplo, quando a versão 1.0 de um sistema é entregue aos usuários, inicia-se, digamos, o desenvolvimento da versão 2.0. Mas a versão entregue não é abandonada: é necessário fornecer atualizações para correção de bugs e ajustes diversos. Isso deve ser feito sem que haja interferência com o desenvolvimento dos novos recursos da versão 2.0, e sem que seu código – potencialmente instável – seja misturado ao da versão em produção. Assim, as versões 1.0 e 2.0 seriam branches separados no CVS, partindo de uma base de código comum.
Posteriormente, é possível fazer o merge de dois branches, o que no exemplo aconteceria quando a versão 2.0 estivesse a ponto de entrar em beta-testes: afinal é desejável incorporar à nova versão quaisquer correções de bugs ou melhorias desenvolvidas na versão 1.0 (que provavelmente seria, a essa altura, 1.1 ou 1.2).
Antes de passarmos para a instalação e uso do CVS, precisamos conhecer alguns conceitos fundamentais – veja o quadro "Conceitos do CVS".
Ciclo de vida de um projeto no CVS
Um projeto nasce para o CVS no momento em que uma versão inicial (normalmente contendo apenas esqueletos da estrutura de pacotes e das principais classes e interfaces) é importada (import) para o repositório. Não existe uma operação para criar um projeto ou módulo “do zero” no CVS – ele sempre deve ser importado.
Cada desenvolvedor cria a sua cópia de trabalho ao fazer um checkout. O resultado é uma cópia de todos os arquivos sob o módulo selecionado, que pode incluir, ou não, seus submódulos (subdiretórios).