Não sei quantos de vocês, queridos leitores, tiveram que lidar com o CVS pra controlar o código-fonte de seus projetos. Eu tive, e não foi a melhor das experiências...
Vamos colocar os pingos nos is primeiro: o CVS é uma tecnologia de quase trinta anos já e que cumpriu muito bem sua finalidade, dado sua idade já avançada, mas não dá mais: toda vez que tentava renomear ou mover um arquivo por algum motivo, isso era um parto, pois pelo que pesquisei na ocasião, ou eu basicamente dava adeus ao histórico anterior do dito arquivo e o apagava para criar um novo com o nome ou no local onde desejasse ou tinha que achar um jeito de mexer no arquivo diretamente no repositório, o que era um bocado perigoso (trabalho com Java, em que mover um arquivo de um diretório -ou pacote- para outro não é algo tão incomum assim).
Passado isso, me deparei com o Subversion (SVN), com a mesma filosofia do CVS, mas muito mais modernoso (já podia mover meus arquivos, yay!), com uma interface amigável para Windows (TortoiseSVN) e basicamente falando com todo mundo. Realmente um salto enorme.
Mas tem uma coisa que sempre me incomodou no SVN: tá certo que tem aquele padrão de organização dos fontes do projeto em três pastas: .../trunk, .../tags e .../branches que nunca foi tratado de forma obrigatória e dara uma tremenda flexibilidade para a organização do repositório. Mas não estou focando da parte boa da flexibilidade, mas naquele tipo que faz com que o pessoal comece a criar repositórios como scripts Ant: do jeito que bem entender.
Mais ainda era melhor que o CVS.
Finalmente, depois de mais uma pequena batalha dentro das listas de discusssão de desenvolvimento do kernel Linux, o próprio Linus Torvalds meteu a mão na massa e criou o famoso GIT: um sistema de controle de versões distribuído com várias diferenças do CVS e SVN, sendo a principal exatamente o sufixo "distribuído": um sistema em que você tem uma cópia TOTAL do repositório e pode manipulá-lo como bem entender; tudo offline. Estava inaugurada a era dos sistemas de versões distribuídos (ou DVCSs, em inglês).
Nessa mesma época, outros sistemas similares pipocaram, sendo os principais o Mercurial (Hg) e o Bazaar (Bzr - cara, como esse povo de TI gosta de siglas!) que abrigam vários sistemas de respeito. O primeiro, por exemplo, é o sistema de controle de versão usado pelo Codeplex, da Microsoft, enquanto o segundo guarda o projeto do Ubuntu Linux e outros projetos Open Source, como o Gnome Do!
De posse de todo esse conhecimento, queria trazer isso pro meu mundinho de desenvolvedor e comecei a pesquisar os sistemas e topei com alguns inconvenientes: o primeiro e crucial foi a integração com sistemas Windows, que já usávamos como base para desenvolvimento. Nesse quesito o Git acabou caindo fora, pois uma adaptação seria um pouco mais complicada, o Bazaar ainda parecia meio instável na época e no final minha escolha recaiu sobre o Mercurial. O processo de migração foi meio espinhoso, admito, mas graças a um script em Python que pode ser encontrado no wiki do Hg, o processo correu sem tantos sobressaltos.
Finalmente, pra ser bem sincero, ainda não consegui converter tudo (em parte pela velha e boa resistência cultural), mas não me arrependo nem um pouco: consegui instalar tudo sem problemas e até consegui integrar o serviço ao IIS do servidor (pretendo postar sobre isso mais tarde) e, ao longo do uso diário, topei com uma "feature" muito eficaz para mim: além do "hash" de identificação de cada commit feito pelos desenvolvedores, que torna cada commit virtualmente único, o Hg também dá para cada commit um número seqüencial, como no SVN. Sendo assim, por exemplo, para manipular uma revisão do repositório basta referenciar o número 12 ao invés do hash 936d33245c5b.
Mais informações sobre DVCSs futuramente.
Nenhum comentário:
Postar um comentário