Základní pojmy Mercurialu

Decentralizovaný model Mercurialu může být pro nového uživatele matoucí. Tato stránka se pokouší osvětlit některé z jeho základních pojmů. Postupný výklad viz Tutorial Mercurialu.

1. Repozitórium

Repozitórium je pracovní adresář Mercuriálu, který se od běžného pracovního adresáře liší tím, že jeho chování je ovlivňováno programem Mercurial:

1. Obsahuje složku .hg neboli repozitář a případně další provozní soubory (.hgrc, .hgignore, ...).

2. Obsahuje soubory a složky, které jsou součástí projektu. Přítomnost všech těchto položek v adresáři je Mercuriálem reflektovaná, složky jsou přitom pojímány jenom jako objekty na cestě k souborům.

   Soubory, které jsou uvedeny v souboru .hgignore, jsou Mercuriálem ignorovány. Soubory, jejichž název byl alespoň jednou akcí "commit" uložen do složky .hg/store/ repozitáře, jsou soubory sledované.

   Míra pozornosti, které je soubor v pracovním adresáři vystaven, se označuje jako statut souboru a má tyto kategorie:

   • ? - neznámý (nesledovaný) soubor, o němž Mercurial ví jen to, že existuje v repozitóriu

   • I - původně neznámý soubor, zařazený do seznamu ignorovaných souborů

   • A - původně neznámý soubor, zařazený jako kandidát pro komit

   • M - změněný sledovaný soubor, je kandidátem pro komit

   • ! - původně sledovaný soubor, ručně smazaný, přejmenovaný či přemístěný

   • R - soubor, odebraný ze sledování příkazem ´´hg remove´´

Komitované sledované soubory jsou v repozitóriu přítomny v závislosti na "příslušnosti" pracovní kopie.

Nesledované soubory (včetně ignorovaných) jsou v repozitóriu přítomny trvale - pokud nejsou smazány.

Repozitórium je tedy vnímavý kořenový adresář projektu, který obsahuje složku .hg, zvanou repozitář a další složky a soubory, které tvoří sledovaný (pracovní kopie) i nesledovaný obsah projektu.

2. Repozitář

Repozitář je technicky vzato složka .hg v repozitóriu.

Následující ilustrace se pokouší naznačit situaci, kdy rodičovskou revizí pracovní kopie (pracovního adresáře) je revize č. 2, uložená ve složce .hg/store.

Subsložka .hg/store obsahuje kompletní historii projektu.

3. Pracovní kopie

Pracovní kopie (working copy) je pomyslná složka v repozitóriu, která obsahuje soubory, jejichž složení a obsah odpovídá aktuálně připojenému changesetu. Implicitně je pracovní kopie napojena na changeset poslední. Aktualizaci pro jiný changeset zařídí příkaz hg update -r REV.

V programových odezvách Mercuriálu a v popiscích grafické aplikace TortoiseHg se pracovní kopie označuje jako pracovní adresář. Musíme to vzít na vědomí ale pro pochopení určitých souvislostí práce s Mercuriálem je vhodnější termín "pracovní kopie".

Pracovní kopie je "kopie" vybrané revize repozitáře, která umožňuje manipulaci s komitovanými soubory jako v normálním pracovním adresáři. Složení a obsah sledovaných souborů v pracovní kopii se mění v závislosti na nastavené aktuální revizi (viz hg update). Obsah pracovní kopie je prezentován v repozitóriu.

V instruktážních schematech se pracovní kopie (pracovní adresář) zobrazuje jako potenciální changeset, vycházející z aktuální rodičovské revize. Komitované změny pracovní kopie představují nový changeset. Nekomitovaným změnám pracovní kopie se říká lokální modifikace. Nemá-li pracovní kopie žádné lokální modifikace, říkáme, že je čistá.

Ideální skladba názvů popisovaných entit by tedy mohla být repozitórium - repozitář - pracovní kopie. Musíme se však smířit s tím, že v anglických textech a schematech se setkáme pouze s termíny repozitář - pracovní adresář nebo dokonce s jediným, vše zahrnujícím termínem repozitář.

Zcela běžně se pro jednu a tutéž komitovanou změnu používají slova revize, changeset a komit.

4. Registrace změn - komit

Provedením příkazu hg commit se stav pracovního adresáře zapíše jako nový changeset neboli revize do repozitáře.

*//*

5. Revize, changesety, čela a tip

Mercurial sdružuje změny ve více souborech do jednotlivých atomických (nedělitelných) changesetů. Každému changesetu je přiřazeno pořadové číslo revize. Protože Mercurial umožňuje decentralizovaný paralelní vývoj projektů, bývají tato čísla u různých uživatelů různá. Z tohoto důvodu uděluje Mercurial každé revizi také globální ID changesetu. Jsou to čtyřicetimístná hexadecimální čísla, jež mohou být zkrácena na libovolně krátký počet znaků, pokud mají jednoznačný význam, jako např. "e38487".

Větvení a slučování se může vyskytnout kdekoliv v historii projektu. Každá nesloučená větev vytváří nové čelo (head) historie. V naší ukázce jsou čely revize 5 a 6. Revize 6 je považována za tip (hrot) repozitáře, čelo s nejvyšším číslem revize. Revize 4 je slučovací, protože má dva rodičovské changesety (revize 2 a 3).

6. Klonování, slučování, akce pull a update

Začněme s Alenkou, jejíž repozitář vypadá následovně:

Pracovní adresář (working directory) je opět uváděn jako poslední (potenciální) changeset.

Bertík si vytvoří klon Alenčina projektu ve svém vlastním počítači:

Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny e,f, které postupně zaregistruje příkazem commit:

Alenka si vytvoří svou vlastní paralelní změnu g. Odlišné repozitáře v této chvíli představují dvě odlišné větve jejich společného projektu.

Nyní se Bertík synchronizuje s Alenkou pomocí příkazu pull. Tímto příkazem zkopíruje všechny změny Alenčina repozitáře (zde tedy pouze změnu g) do svého repozitáře. Jeho pracovní adresář však zůstává nezměněn.

Protože nejnovějším čelem v Bertíkově repozitáři je Alenčin changeset g, je nositelem označení tip.

Bertík dále provede příkaz merge (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) repozitáře. Jeho pracovní adresář má nyní dvě rodičovské revize (f, g):

Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík příkazem commit slučující changeset h ve svém repozitáři:

Když si nyní Alenka přetáhne příkazem hg pull změny od Bertíka, přejdou do jejího repozitáře revize e,f a h:

Všimněme si, že po provedení příkazu pull je Alenčin pracovní adresář stále potomkem revize g. Alenka musí ještě provést příkaz update aby její pracovní adresář ukazoval na slučující changeset h a aby aktualizoval soubory v jejím pracovním adresáři vzhledem k revizi h.

Nyní jsou Alenčin a Bertíkův repozitáře opět plně synchronizovány.

7. Decentralizovaný systém

Mercurial je úplně decentralizovaný systém bez centrálního repozitáře. Uživatelé si mohou volně definovat své konstelace pro sdílení změn (viz CommunicatingChanges), včetně vyčlenění jednoho repozitáře jako centrálního:

Na rozdíl od centralizovaných systémů správy verzí, u nichž experimentování může končit pohromou, u systémů DVCS, jako je Mercurial si prostě vytvoříme klon a experimentujeme. Pokud jsme s výsledkem spokojeni, předáme jej dál, pokud ne, můžeme klonovaný repozitář smazat a zkusit něco jiného.