Controle de Versão Mercurial
História
O Mercurial teve início
quando Larry MacVoy, optou por tornar o BitKeeper pago. Com isso, o criador do
Kernel do Linux, Linus Torvalds, anunciou que estava à procura de uma ferramenta
para substituir o BitKeeper.
Paralelamente, Linus
Torvalds começou a desenvolver um novo Sistema de Controle de Versões, o GIT e Matt
Mackall, também começou a desenvolver o Mercurial a o intuído de substituir o BitKeeper.
No dia 19 de Abril de
2005, o release 0.1 do Mercurial foi
anunciado por Matt Mackall, porém, apesar de possuir uma boa interface
funcional e um armazenamento eficiente, a ferramenta escolhida para controlar o
código do Kernel do Linux foi o GIT.
Mesmo não sendo a
escolhida, o Mercurial passou a ser adotado em muitos projetos importantes, e
assim como o GIT, passou a ser um dos SCV´s descentralizados mais populares.
Ciclo básico de trabalho
Faz parte do ciclo básico
de trabalho as seguintes operações, que são realizadas por um desenvolver em
seu dia a dia: Atualizar repositório e cópia de trabalho; fazer alterações; verificar
alterações; verificar alterações; possivelmente desfazer algumas
alterações; resolver conflitos; submeter alterações e possivelmente
propagar suas
alterações para outro repositório.
Figura 01 – Fluxo de trabalho do Mercurial
Status técnico
Apesar de ter sido inicialmente
desenvolvido para substituir o BitKeeper, no papel do SCV do Kernel do Linux, o
desenvolvimento do Mercurial não foi tão focado no Linux. Foi desenvolvido na
linguagem Python e funciona em qualquer Sistema Operacional que seja compatível
com essa linguagem.
Possui a interoperabilidade como
ponto forte, assim como no Subversion e no GIT, com plug-ins para várias IDEs e
uma boa documentação disponível em seu site oficial https://www.mercurial-scm.org/wiki/Tutorial, como o manual chamado Mercurial:
The Definitive Guide. Esse manual foi escrito por Bryan O'Sullivan, um dos
principais colaboradores no desenvolvimento do Mercurial.
Operações de Repositório
No Mercurial a operação commit é atômica, ou seja, se a operação
for interrompida, ela é desconsiderada e o repositório não fica em um estado inconsistente,
assim como no Subversion e no GIT.
No Mercurial também possuem os
comandos para propagar alterações entre repositórios, como por exemplo o hg push e o hg
pull. O comando hg push envoa as alterações do repositório local para
um repositório remoto, como no GIT, porém o hg
pull é diferente do coemando git
pull, pois o mesmo realiza download de alterações de outro repositório e um
merge coma cópia de trabalho,
enquanto o comando hg pull, apenas
realiza a etapa de download das alterações.
Para definir permissões tanto
para o repositório como um doto, quanto arquivos, pode ser feito através dos
protocolos ssh e http.
No Mercurial, assim como no
Subversion e no GIT, também registra as revisões, como quem realizou as
alterações e quando foram feitas, e através do comando hg annotate é possível analisar as alterações realizadas linha por
linha.
Diferentemente do Subversion e do
GIT, o Mercurial trabalha com merge inteligente
após operações de rename em um arquivo.
Uma vantagem do Mercurial é o
fato dele ser compatível tanto com o Subversion quanto no GIT.
Referências
Comentários
Postar um comentário