Comparação entre Subversion, Mercurial e Git
Suponha que uma empresa tenha decidido migrar seus projetos comerciais do Subversion para uma ferramenta de controle de versão distribuído (DVCS). Os candidatos possíveis são o Mercurial e o Git. O próximo passo é fazer uma análise comparativa para decidir qual o mais adequado.
A definição dos critérios de comparação depende muito do perfil do projeto. Projetos comerciais têm necessidades diferentes dos projetos open source. A hospedagem externa (Github , Bitbucket, Google Code etc.), por exemplo, não será um fator decisivo na escolha se o repositório oficial do projeto for mantido internamente na empresa.
Para determinar quais os critérios mais relevantes, é preciso primeiro definir o perfil do projeto. O perfil de um projeto comercial típico que usa Subversion pode ser descrito como:
- Possui, no máximo, algumas dezenas de desenvolvedores, todos com acesso ao repositório pela rede local.
- As equipes são formadas, em sua maioria, por desenvolvedores juniores com pouca ou nenhuma capacitação em Subversion e pouco conhecimento de inglês.
- Os desenvolvedores juniores trabalham apenas no trunk usando apenas operações básicas como add, commit e update.
- Os projetos evitam usar ramos para não ter de fazer mesclagem. Casos de mesclagem são executados por coordenadores/líderes de projeto, que são nível pleno ou sênior.
- O ambiente de desenvolvimento é Windows.
De acordo com esse perfil, serão apresentados uma série de artigos comparando o Subversion (servindo de referência), Mercurial e o Git de acordo com os seguintes critérios:
- Desempenho. É desejável que a ferramenta tenha o melhor desempenho possível. Contudo, só será um fator decisivo se houver uma diferença muito grande entre as ferramentas.
- Funcionalidades. Ter muitas funcionalidades é interessante. Mas também só será decisivo se houver muita diferença entre os candidatos.
- Complexidade. Quanto mais complexa a ferramenta, mais difícil de aprender e usar. Influencia a produtividade e também aumenta a chance de haver erros de operação durante atividades cotidianas de controle de versão.
- Ramificação e Mesclagem. A mesclagem deve ser uma operação elementar se possível. A ramificação deve atender a todos os tipos de ramos possíveis e desejáveis.
- Similaridade com o Subversion. Quanto mais próximo do Subversion for o fluxo de trabalho, comandos e modelo mental, menor será o esforço de transição para a nova ferramenta.
- Funcionamento no Windows. É importante que a ferramenta funcione bem no ambiente de desenvolvimento. De preferência, com interfaces gráficas e plugins para as IDEs usadas.
Versões Usadas Nas Comparações
No momento em que este artigo foi escrito, as versões mais atuais das ferramentas analisadas eram:
Subverion 1.7.5
Mercurial 2.2.1
Git 1.7.10
No Ubuntu, as versões mais atuais podem ser obtidas através de ppas do Ubuntu, conforme os comandos abaixo:
- $ sudo add-apt-repository ppa:dominik-stadler/subversion-1.7
- $ sudo add-apt-repository ppa:mercurial-ppa/releases
- $ sudo add-apt-repository ppa:git-core/ppa
- $ sudo apt-get update $ sudo apt-get install subversion mercurial git
O Mercurial não vem com os comandos fetch e rebase habilitados por padrão. Como eles serão usados em algumas comparações, é necessário ajustar a configuração conforme o comando abaixo:
$ sudo echo '
fetch =
rebase = ' >> /etc/mercurial/hgrc.d/hgext.rc
Desempenho
A análise de desempenho entre o Subversion, Mercurial e o Git se baseia em um estudo de caso que simula operações cotidianas de controle de versão. O objetivo é definir se as variações nos tempos de execução são grandes o suficiente para ser usadas como critério de escolha.
As operações consideradas no estudo de caso são:
Desempenho
A análise de desempenho entre o Subversion, Mercurial e o Git se baseia em um estudo de caso que simula operações cotidianas de controle de versão. O objetivo é definir se as variações nos tempos de execução são grandes o suficiente para ser usadas como critério de escolha.
As operações consideradas no estudo de caso são:
- Criação/clonagem de um repositório.
- Adição de arquivos
- Consolidação
- Visualização do estado, histórico e das diferenças
- Mesclagem (Merge)
- Comunicação entre repositórios (pull, fetch e push)
O estudo de caso está automatizado por um script em bash. As operações manipulam apenas alguns arquivos por vez, pois é o que acontece nas consolidações comumente realizadas por desenvolvedores.
O acesso ao repositório do Subversion é apenas local. Um repositório remoto dificultaria a replicação da experiência e adicionaria fatores não controlados como velocidade da rede à medição. Caso haja algum repositório remoto disponível para testes, o script fornecido pode facilmente ser modificado para acessá-lo e as medições ser refeitas.
Mesmo o Subversion se saiu muito bem nos testes, com tempo melhores até mesmo que o Mercurial em algumas operações. Certamente os tempos de algumas operações seriam piores caso o repositório fosse remoto e houvesse requisições concorrentes de processamento. Ainda assim, provavelmente os tempos continuariam satisfatórios.
As operações do Mercurial tiveram um tempo de execução bastante uniforme. Parte desse resultado se deve ao fato de o Mercurial ser escrito em Python e, por isso, há um tempo adicional de carregamento inicial do interpretador a cada comando.
Conforme esperado, o Git é extremamente rápido. O Subversion e o Mercurial são mais lentos que o Git em décimos de segundo. Mas em termos absolutos e práticos, essa diferença é insignificante e não tem impacto na produtividade. Sendo assim, pode-se afirmar que todas as ferramentas são satisfatoriamente rápidas na execução das suas operações e, portanto, desempenho não é um critério decisivo para escolha de ferramenta.
Melhor: Empate Técnico
Funcionalidades
O objetivo deste critério é apenas analisar o número de funcionalidades existentes, sem entrar no mérito de cada uma ou se determinada funcionalidade é importante ou não para um certo modo de trabalho. Na análise da “Similaridade com o Subversion” é que esses aspectos serão melhor abordados.
O Subversion possui naturalmente menos funcionalidades que o Mercurial e o Git porque o controle de versão centralizado é um subconjunto do distribuído. Com exceção dotravamento de arquivos, que não condiz com o DVCS, as operações feitas pelo Subversion também podem ser feitas pelo Mercurial e pelo Git. Algumas operações não fariam sentido para o Subversion, como push e pull por exemplo. Mas outras talvez pudessem ser incorporadas, como o bisect.
Desde 2005, quando começaram suas atividades, o Mercurial e o Git vêm se influenciando continuamente, com um incorporando características do outro. O Mercurial, por exemplo, implementou o rebase e apontadores para revisões (bookmarks) que eram do Git. O Git, por sua vez, implementou os comandos daemon e bundle equivalentes aos comandos servee bundle do Mercurial. Atualmente, chegaram a tal ponto que ambos podem ser considerados equivalentes em termos de funcionalidades.
Por isso, número de funcionalidades também não é um critério decisivo de escolha de ferramenta.
Melhor: Mercurial e Git.
Conclusão
A escolha da ferramenta de DVCS precisa ser baseada em critérios relevantes ao perfil do projeto. Dentre o vários sugeridos, dois critérios já foram apresentados neste primeiro artigo: Desempenho e Funcionalidades. Mas, como mostraram as medições, houve empate tanto no desempenho do Subversion (com acesso a um repositório local), Mercurial e Git, quanto no número de funcionalidades do Mercurial e do Git.
