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. Mlhovina Hg

Pro pochopení práce s Mercuriálem je důležité přesné vymezení pojmu pracovní adresář. Četbou souvisejících textů lze dojít k závěru, že pracovní adresář (working directory) je:

1. pracovní kopie (working copy) vybrané revize repozitáře - implicitně revize poslední.

2. vnímavý kořenový adresář složky .hg (repozitáře); kromě této složky obsahuje pracovní adresář pracovní kopii ad a) a případně další nesledované soubory či složky, které nejsou v repozitáři registrovány.

Uvedenou definici lze ovšem parafrázovat také takto: pracovní adresář je kořenový adresář, který obsahuje pracovní adresář -- neboli "sám sebe", což je vlastně nonsens, byť docela často prezentovaný.

Kdybychom se mohli dohodnout, že pro kopii aktuální revize budeme důsledně používat termín pracovní kopie, mohli bychom přehledně a pravdivě říci, že

• Pracovní adresář je vnímavý kořenový adresář složky .hg (repozitáře), obsahující pracovní kopii a další (nesledované) položky projektu.

Dohodnout se ale nemůžeme, protože "pracovní adresář" je dlouhodobě zavedené označení pro pracovní kopii ve smyslu ad a.

Další, byť méně šikovnou možností je použít pro pracovní adresář ve smyslu ad b) jiné označení, například v následujícím textu použité repozitórium (posvěcené uložiště cenností). Potom lze tvrdit, že

• Repozitórium je vnímavý kořenový adresář složky .hg (repozitáře), obsahující pracovní adresář a další (nesledované) položky.

Až se z nás stanou zkušení Mercuriáloví mazáci, můžeme případně pro všechny tři entity (pracovní adresář, repozitář, pracovní kopie) používat jeden termín repozitář - tak, jak se s tím v textech rovněž setkáváme. V úvodních, instruktivních textech je ovšem důležité mezi těmito pojmy rozlišovat.

2. Repozitórium

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

Slovem "vnímavý" se míní skutečnost, že obsah a složení souborů či složek v repozitóriu se mění v závislosti na nastavené aktuální revizi, jejíž obsah je prezentován pracovním adresářem.

Soubory v repozitóriu mohou mít různý statut podle toho, jak jsou zapojeny do systému Mercurial:

• ? - neznámý 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´´

3. Pracovní adresář

Pracovní adresář je pracovní kopie vybrané revize repozitáře, která umožňuje manipulaci se souboury a složkami projektu jako v normálním pracovním adresáři.

V systému Mercuriálu je pracovní adresář prezentován jako editovatelný přímý potomek (dítě) aktuálního changesetu (případně changesetů při nekomitovaném sloučení), jímž může být kterýkoliv changeset, zpravidla ten poslední.

Obsah a složení souborů či složek v pracovním adresáři (potažmo v repozitóriu) odpovídají obsahu a složení souborů či složek aktuálního changesetu (připadně changesetů) v čase jeho vytvoření (komitu).

Anekdotický důsledek této skutečnosti je například to, že můžeme v repozitóriu postrádat soubor, který jsme do něj (i do repozitáře) zcela určitě vložili a to jenom proto, že pracovní adresář je aktuálně lokalizován pro revizi, ve které postrádaný soubor ještě neexistoval.

Komitované změny pracovního adresáře představují nový changeset. Nekomitovaným změnám pracovního adresáře se říká lokální modifikace. Nemá-li pracovní adresář žádné lokální modifikace, říkáme, že je čistý.

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

4. 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ího adresáře (repozitória) je revize č. 2, uložená ve složce .hg/store.

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

Na rozdíl od repozitória sleduje repozitář pouze tyto stavy souborů:

• n -- normální
• a -- přidaný
• r -- odebraný
• m -- sloučený

Repozitář obsahuje celou historii projektu, repozitórium (potažmo pracovní adresář) obsahuje časový snímek projektu v určitém bodě historie.

*/

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.