Differences between revisions 81 and 83 (spanning 2 versions)
Revision 81 as of 2013-11-14 16:42:58
Size: 12110
Editor: Tovim
Comment:
Revision 83 as of 2013-11-14 20:00:08
Size: 11334
Editor: Tovim
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
== Repozitář ==

Přísně vzato, [[Repository|repozitářem]] je pouze složka '''.hg''', nalézající se ve vnímavé (sentient) nadřazené (kořenové) složce projektu, které můžeme pro lepší odlišení významů označit jako '''repozitórium'''. Kromě výše uvedeného repozitáře obsahuje repoziórium další složky a soubory, jejichž skladba (jak ji vidíme např. v Průzkumníku Windows) se mění v závislosti na momentálně nastavené aktuální revizi.
== Repozitórium, repozitář, pracovní adresář ==

[[Repository|Repozitórium]] je vnímavá (sentient) projektová složka, která obsahuje složku '''.hg''', zvanou [[Repository|repozitář]] a další složky a soubory, které tvoří obsah pomyslného [[WorkingDirectory|pracovního adresáře]], jehož skladba se mění v závislosti na momentálně nastavené aktuální revizi. Pracovní adresář se zkratkovitě definuje jako "sada změn, kterou hodláme komitovat".
Line 17: Line 17:
Šedou eminencí uvnitř repozitória je tak zvaný [[WorkingDirectory|pracovní adresář]] (někdy označovaný jako ''pracovní kopie''), což je vlastně pomyslný útvar, napojený na aktuální revizi, v němž se provádějí veškeré změny v obsahu i složení souborů před tím, než jsou převedeny (komitovány) do repozitáře.
Chtělo by se říci, že pracovní adresář je vlastně repozitórium ale až uvidíme schemata ve kterých je pracovní adresář pomyslným pokračováním aktuální (většinou poslední) revize, přijde nám srozumitelnější tyto dva pojmy od sebe rozlišovat. Pracovní adresář se zkratkovitě definuje jako "sada změn, kterou hodláme komitovat".

Soubory v repozitóriu jsou sledované (sledují se jejich změny, případně jejich přítomnost či nepřítomnost) i nesledované (jsou přítomné ale jsou vedeny jako ignorované). Změny sledovaných souborů lze akcí ''commit'' uložit jako revize, neboli changeset, do složky store v repozitáři.

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

Často se slovem "repozitář" označuje nepřesně jak repozitórium, tak i repozitář. Jak lze vidět ve schematech 5. odstavce, je jako pracovní adresář (working directory) označován poslední, nekomitovaný changeset.

Dalším mlhavým termínem je lokální kopie. Tímto souslovím je často označován aktuální obsah pracovního adresáře, který jak už víme, reflektuje aktuální revizi. Základní význam tohoto sousloví je samozřejmě místní kopie v počítači.
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

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

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

Repozitář obsahuje historii projektu, repozitórium (potažmo pracovní adresář) obsahuje časový snímek projektu v určitém bodě historie. Často se slovem "repozitář" označuje nepřesně jak repozitórium, tak i repozitář.

Zcela běžně se pro jedno a totéž (komitovaná změna) používají slova ''revize'' a ''changeset''.
Line 56: Line 64:
Složka '''store''' obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, zde má každý adresář projektu svou vlastní kopii historie. To umožňuje paralelní vývoj projektů. Složka '''.hg/store''' obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, zde má každý adresář projektu (repozitórium) svou vlastní kopii historie. To umožňuje paralelní vývoj projektů.

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ů.

1. Repozitórium, repozitář, pracovní adresář

Repozitórium je vnímavá (sentient) projektová složka, která obsahuje složku .hg, zvanou repozitář a další složky a soubory, které tvoří obsah pomyslného pracovního adresáře, jehož skladba se mění v závislosti na momentálně nastavené aktuální revizi. Pracovní adresář se zkratkovitě definuje jako "sada změn, kterou hodláme komitovat".

Aktuální revizí je většinou revize poslední (tip) ale může jí být kterákoliv jiná revize, označená jako aktuální.

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 ! původně sledovaný soubor, ručně smazaný, přejmenovaný či přemístěný R soubor, odebraný ze sledování příkazem ´´hg remove´´

Repozitář obsahuje historii projektu, repozitórium (potažmo pracovní adresář) obsahuje časový snímek projektu v určitém bodě historie. Často se slovem "repozitář" označuje nepřesně jak repozitórium, tak i repozitář.

Zcela běžně se pro jedno a totéž (komitovaná změna) používají slova revize a changeset.

2. Co je v repozitáři

Změny projektu se ukládají ve složce .hg/store :

Složka .hg/store obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, zde má každý adresář projektu (repozitórium) svou vlastní kopii historie. To umožňuje paralelní vývoj projektů.

Pracovní adresář obsahuje kopii projektových souborů v učitém časovém bodě (např. rev. 2) připravených k editování. Protože tagy a ignorované soubory jsou také verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře.

3. Registrace změn

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

Revize 4 byla vytvořena v situaci, kdy již existovala revize 3 a aktuální revizí pracovního adresáře v té chvíli byla revize 2. Revize 4 tvoří novou větev v historii changesetů.

4. Revize, changesety, čela a tip

Mercurial sdružuje změny ve vícerých 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 repozitáře, čelo s nejvyšším číslem revize. Revize 4 je slučovací changeset, protože má dva rodičovské changesety (revize 2 a 3).

5. 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ě potvrdí příkazem commit:

Alenka si vytvoří svou vlastní paralelní změnu g:

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 pouze změnu g) do svého repozitáře.

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 pull) změny od Bertíka, přejdou do jejího repozitáře revize e,f a h:

Všimneme 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.

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

6. Decentralizovaný systém

Mercurial je úplně decentralizovaný systém bez cenrá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.


CzechUnderstandingMercurial (last edited 2018-08-03 18:27:01 by Tovim)