CVS X Subversion

Olá pessoal,

hoje gostaria de tratar sobre um assunto que, por mais que esteja bem conceituado e conhecido por todos, sempre gera uma certa polêmica ao se tomar uma decisão a respeito. Estou falando da definição de um sistema de controle de versões (Software Configuration Management - SCM) para controlar e gerenciar a evolução dos artefatos gerados por um projeto de software.

Embora existam dezenas de sistemas dessa linha, tratarei aqui apenas dos mais utilizados atualmente no mercado: o CVS e o Subversion (SVN) frutos de uma boa e produtiva discussão gerada na empresa onde trabalho. Fato que me motivou a escrever sobre este tema após coletar dados e pesquisas suficientes para argumentar a migração do nosso SCM atual, o CVS, para o Subversion. Para uma completude das argumentações, também era necessário se levantar uma forma de migrar todos os dados hisóricos do repositório do antigo para o novo sistema.

Para resumir a comparação entre as duas tecnologias, criei uma tabela que cruza características dos dois sistemas em uma perspectiva de administração da ferramenta, que é o que no fundo mais importa, já que as ferramentas utilizadas como clientes para acessa-las são muito parecidas e de fácil assimilação, o que não influenciaria em nada como vantagem ou desvantagem entre um e outro sistema de versionamento.

	CVS	Subversion
Armazenamento	É feito em arquivos RCS. Estes arquivos são criados em toda a árvore de diretórios do projeto para versionar arquivo por arquivo. Possibilita maior poder para recuperar possíveis falhas apenas editando esses arquivos.	É feito em banco de dados Berkley DB. Existem aplicativos para a recuperação de falhas.
Concorrência	Existem problemas de acesso concorrente por se tratarem de arquivos em disco.	Acesso concorrente transacionado pelo banco de dados.
Velocidade	Mais lento pelo fato de usar file system.	Mais rápido. O único problema de velocidade está no momento de se conectar ao repositório e fazer o primeiro checkout, já que ele traz uma cópia local de todos os arquivos.
Versionamento	Gerencia versões diferentes para cada arquivo do projeto. Permite a criação de branchs e tags por arquivo. Não permite restaurar a versão do projeto à partir de uma tag específica.	Para cada branch ou tag, cria-se uma cópia no repositório e todos os arquivos do projeto ganham um número identificador de 4 dígitos. Ao se configurar um branch, o SVN cria uma tag correspondente no início, mas depois que se dá o primeiro commit, ele se transforma no branch e o novo versionamento se inicia imediatamente. Permite restaurar a versão do projeto à partir de uma tag específica.
Metadados	Não armazena metadados, somente arquivos.	Permite que se vincule e versione também atributos relacionados aos arquivos, esses atributos são configurados na forma de par “chave=valor”.
Tipo de arquivos comportados	Bom para armazenamento de arquivos texto. Problema em armazenar binários. Também não é possível se fazer diff de binários.	Todos os tipos de arquivo.
Rollback	Permite, no entanto tem que se faze de arquivo por arquivo.	Não permite, tem que ser fazer cópias de versões em bom estado.
Transações – Integridade	Não possui a teoria do “ou tudo, ou nada” pois, quando há conflitos, os arquivos afetados deixam de serem “commitados”, sendo que os estão íntegros(sem conflito) vão para o repositório mesmo assim.	Possui o conceito do “ou tudo, ou nada”. Assim, os números das revisões são marcados apenas quando todos os conflitos foram resolvidos e finalmente se dá o commit. Permite também configurar grupos para commit.
Lock de arquivos	Não possui.	Possui. Se um usuário bloqueia o arquivo, ele fica como “somente leitura” para os outros.
Interoperabilidade	Não possui.	Pode se comunicar via Http e ssh.
Integração com o RedMine	Possui.	Possui.
Integração com o Hudson	Possui.	Possui.

Reparem que ao final da tabela de avaliação eu cito duas integrações com outros sistemas: RedMine e Hudson. O RedMine é um sistema de gerência de projetos que utilizamos na empresa. Já o Hudson é o sistema de integração contínua open-source mais utilizado do mercado. Estas duas ferramentas se tornam muito valiosas para se fechar o círculo formado pelos componentes necessários a uma Gestão de Configuração eficaz. Pretendo abordar algo sobre elas e sobre a teoria em torno da Gerência de Configuração e Mudança em breve!

Ok, podemos concluir pela tabela que, o SVN possui uma série de características mais arrojadas que o CVS, mas ainda fica uma pergunta no ar: se a necessidade era também a de migrar os dados, como faríamos isto sem que perdêssemos todos os dados históricos das tags e branchs criados?

Para a árdua tarefa de migração também já existe uma ferramenta muito difundida: o CV2SVN... Ufa! 

Esta ferramenta basicamente percorre toda a estrutura de diretórios do projeto afim de mapear e migrar todos os dados históricos de branchs e tags criadas para o novo repositório. Ela permite também que se configure os dois SCM's para sincronizar as alterações de arquivos de um para o outro.

Os nossos próximos passos são instalar então o SVN e CVS2SVN e colocar a migração em prática. Prometo relatar os resultados e todo o caminho das pedras nos próximos posts!

Seguem algumas referências importantes sobre o assunto:

Sites para documentação:

• CVS:  http://www.nongnu.org/cvs/#documentation
• Subersion: http://subversion.apache.org/docs/

Estratégia de migração:

• Aplicativo CVS2SVN : http://cvs2svn.tigris.org

Outras referências:

• http://sam.zoy.org/writings/programming/svn2cvs.html
• http://onlamp.com/pub/a/onlamp/2005/10/03/cvs-to-subversion-with-cvs2svn.html
• http://sial.org/howto/subversion/cvs-migrate/

Fiquem à vontade para deixar os seus comentários!

Um abraço a todos e até o próximo post! ;)

.