3.2.7 Mercurial

 

Projeto Mercurial iniciou em abril de 2005, originalmente para Linux sendo posteriormente portado para Mac OS X e Windows, tem código escrito em Python, a exceção do recurso Diff que foi escrito em C, foi criado para ter  alta performance, ser escalável, descentralizado, trabalhar de forma distribuída e de forma colaborativa, suportar tanto arquivos de texto e binários, boa capacidade de branching e merging e simples de usar.

 

O Mercurial funciona tanto via linha de comando como através de clientes gráficos como o TortoiseHg que se integra ao Windows Explorer nas plataformas windows e ao nautilus nas plataformas Linux

 

Os Comandos começam com “hg”, sendo claramente uma referência ao elemento químico Mercúrio.

 

Bryan O'Sullivan, comenta em seu manual como o Mercurial gerência as mudanças que ocorrem nos arquivos. Quando ele percebe a ocorrência de uma mudança em um arquivo, ele guarda o histórico do arquivo em um objeto de metadados chamado filelog, estas entradas no file log contém informações suficientes para reconstruir uma revisão do arquivo. A filelog contém dois tipos de informações: revisão de dados e um índice para ajudar o Mercurial a encontrar uma revisão eficiente, caso o arquivos seja muito grande as informação são divididas em dois arquivos separados uma de dados e outro de índice.

Mercurial utiliza uma estrutura chamada de manifesto para reunir informações sobre os arquivos que estão sendo controlados. Cada entrada no manifesto contém informações sobre os arquivos presentes em um único conjunto de alterações. Um registro de entrada dos arquivos que estão presentes no conjunto de alterações, a revisão de cada arquivo, e algumas outras peças de metadados do arquivo.

 

Já os logs de mudanças (changelogs) contém informações sobre cada alteração (changeset). cada revisão do changelog possui quem fez o commit, o comentário do changeset, outras informações relacionadas ao changeset e a revisão do manifesto em uso.

 

Os relacionamentos entre as revisões são guardadas dentro de um changelog, um manifesto, ou umafilelog, cada revisão armazena um ponteiro para seu pai imediato (ou para os seus dois pais, se é uma junção de revisão) . Existe também as relações entre as revisões por essas estruturas, e eles são de natureza hierárquica.

 

Para cada conjunto de alterações em um repositório, há exatamente uma revisão armazenados nochangelog. Cada revisão do changelog contém um ponteiro para uma única revisão do manifesto. Uma revisão do manifesto armazena um ponteiro para uma revisão única de cada filelog rastreado quando o changeset foi criado. Se um arquivo controlado pelo Mercurial não mudou entre duas changesets, a entrada para esse arquivo nas duas revisões do manifesto irá apontar para a mesma revisão do seu filelog,  estes metadados ficam sobre uma única estrutura chamada revlog.

 

revlog fornece um armazenamento eficiente de revisões usando um mecanismo delta. Em vez de armazenar uma cópia de um arquivo para cada revisão, ele armazena as mudanças necessárias para transformar uma revisão mais antiga para a nova revisão. Para muitos tipos de arquivo de dados, esses deltas são tipicamente uma fracção de um por cento do tamanho de uma cópia integral de um arquivo.

 

Identificação e forte integridade de revisões, junto com um Delta ou informações de um instantâneo (snapshot ou fotografia), uma entrada no revlog contém um hash de criptografia dos dados que ela representa. Isto torna difícil para forjar o conteúdo de uma revisão, e fácil de detectar danos acidentais.

 

hashes fornecem mais de uma verificação simples contra a corrupção, pois eles são utilizados como identificadores de revisões. Os hashes de identificação de alterações que você vê como um usuário final são de revisões do changelog. Embora filelogs e o manifesto também usam hashes, Mercurial só usa esses nos bastidores.

 

Mercurial verifica que os hashes estão corretos quando ele recupera as revisões de arquivos e quando ele puxa as mudanças a partir de outro repositório. Se ele encontrar um problema de integridade, ele irá parar a solicitação e tudo o que está fazendo.

 

Além do efeito que tem sobre a eficiência de recuperação, Mercurial uso instantâneos periódicos para tornar mais firme contra a corrupção de dados parciais. Se um revlog torna-se parcialmente danificado devido a um erro de hardware ou erros de sistema, muitas vezes é possível reconstituir alguns ou a maioria das revisões das seções não corrompida do revlog, tanto antes como após a seção danificada. Isto não seria possível com apenas um modelo delta de armazenamento.

 

Comments