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:
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! 😉
.
