|
Size: 10858
Comment:
|
Size: 11987
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 #language cs ## page was renamed from CzechUnderstandingHg ## page was renamed from CzechUnderstandingMercurial ## page was renamed from Základy Mercurialu = Základní pojmy Mercurialu = |
|
| Line 3: | Line 9: |
| See the [[Tutorial]] for step-by-step instructions. ''(Translations: [[BrazilianPortugueseUnderstandingMercurial|Brazilian Portuguese]], [[ChineseUnderstandingMercurial|Chinese]], [[CzechUnderstandingMercurial|Czech]], [[FrenchUnderstandingMercurial|French]], [[GermanUnderstandingMercurial|German]], [[ItalianUnderstandingMercurial|Italian]], [[JapaneseUnderstandingMercurial|Japanese]], [[KoreanUnderstandingMercurial|Korean]], [[RussianUnderstandingMercurial|Russian]], [[SpanishUnderstandingMercurial|Spanish]], [[ThaiUnderstandingMercurial|Thai]] )'' |
|
| Line 22: | Line 11: |
| == Co je repozitář == Termín [[Repository|repozitář]] má dva významy. V užším smyslu to je složka *.hg* v adresáři projektu. V šírším smyslu to je úložný prostor pro zaznamenávání změn. Soubory a složky měněných souborů jsou přítomny či nepřítomny v adresáři projektu, neboli v [[WorkingDirectory|pracovním adresáři]].Obsah pracovního adresáře se mění podle nastavené aktuální revize: |
== Repozitář == Přísně vzato, [[Repository|repozitářem]] je pouze složka '''.hg''', nalézající se v adresáři projektu. Adresář projektu, kterému se také říká [[WorkingDirectory|pracovní adresář]], obsahuje další sledované i nesledované soubory a složky. Sledované (verzované) položky jsou ty, které jsou registrovány v repozitáři. Změny sledovaných (verzovaných) souborů se akcí ''commit'' ukládají jako revize, neboli changesety, do složky store v repozitáři. Skladba a obsah souborů v pracovním adresáři (tak, jak je vidíme např. v Průzkumníku Windows) se mění v závislosti na momentálně nastavené aktuální revizi. Deklaraci aktuální revize lze změnit pouze další deklarací, třeba i v jiné seanci Repozitář tedy obsahuje historii projektu, pracovní adresář obsahuje časový snímek projektu v určitém bodě historie. Často se nepřesně jako repozitář označuje celý adresář projektu. Pracovní adresář má ale také dva významy. 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. == Co je v repozitáři == Změny projektu se ukládají ve složce .hg/store : |
| Line 40: | Line 42: |
| label = "záznam v repozitáři"; | label = "složka .hg/store"; |
| Line 51: | Line 53: |
| Repozitář obsahuje '''úplnou''' historii projektu. Na rozdíl od tradičních [[SCM|SCM]], kde existuje pouze jedna centrální kopie této historie, má každý pracovní adresář v Mercurialu svou vlastní kopii. To umožňuje paralelní vývoj projektů. Pracovní adresář tedy obsahuje editovatelné kopie souborů, odpovídající zadané aktuální revizi - včetně souborů [[.hgignore|ignorovaných]]. == Předávání změn == Provedením příkazu [[Commit|commit]], se změny v aktuálním pracovním adresáři zapíší do nového [[ChangeSet|changesetu]] (neboli nové "[[Revision|revize]]"). Změny se vztahují k [[Parent|rodičovské]] revizi: |
Složka '''store''' obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, je každý adresář projektu spojen se 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 [[Tag|tagy]] a [[.hgignore|ignorované soubory]] jsou také verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře. == Registrace změn == Provedením příkazu '''commit''' se stav pracovního adresáře zapíše jako nový [[ChangeSet|changeset]], nepříliš přesně označovaný také jako [[Revision|revize]]. Přísně vzato, '''revize''' značí změnu souboru či složky. Jeden '''changeset''' (sada změn) může mít více revizí. Vhodnějším ekvivalentem pro slovo "changeset" by mohlo být slovo '''verze'''. Následující ilustrace ale používá termín "revize". |
| Line 73: | Line 76: |
| label = "repozitář"; | label = "store"; |
| Line 86: | Line 89: |
| Výše uvedená ilustrace není příliš ilustrativní. Vězme, že revize 4 byla vytvořena po revizi 3 jako '''[[Branch|větvení]]''' revize 2, jež byla při vzniku revize 4 aktuální. Revize 4 je '''rodič''' revizí 3 a 4. | 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 '''[[Branch|větev]]''' v historii changesetů. |
| Line 89: | Line 92: |
Mercurial sdružuje provedené změny do atomických (nedělitelných) [[ChangeSet|changesetů]], které jsou revizemi v rámci jednoho repozitáře. Každému changesetu je přiřazeno pořadové [[RevisionNumber|číslo revize]]. Protože Mercurial umožňuje rozptýlený paralelní vývoj projektů, bývají tato čísla revizí v různých repozitářích různá. Kromě lokálních pořadových čísel má každá revize také globální [[ChangeSetID|ID changesetu]]. Jsou to čtyřiceti místná hexadecimální čísla, jež mohou být zkrácena na libovolně krátký počet znaků s jednoznačným významem, jako např. "e38487". |
Mercurial sdružuje změny ve vícerých souborech do jednotlivých atomických (nedělitelných) [[ChangeSet|changesetů]], které jsou revizemi (verzemi) celého projektu. Každému changesetu je přiřazeno pořadové [[RevisionNumber|čí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í [[ChangeSetID|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". |
| Line 119: | Line 121: |
| Větvení a [[Merge|slučování]] se může vyskytnout kdekoliv v historii revizí. Každé rozvětvení vytváří nové [[Head|čelo]] (head) historie. V naší ukázce jsou čely revize 5 a 6. Revize 6 je považována za [[Tip|tip]] repozitáře, čelo s nejvyšším číslem revize. Revize 4 je [[MergeChangeset|sloučený changeset]], protože má ''dva'' rodičovské changesety (revisions 2 and 3). Pracovní adresář je ve schematu potenciálním changesetem. == Klonování, slučování, akce Pull a Update == |
Větvení a [[Merge|slučování]] se může vyskytnout kdekoliv v historii projektu. Každá nesloučená větev vytváří nové [[Head|čelo]] (head) historie. V naší ukázce jsou čely revize 5 a 6. Revize 6 je považována za [[Tip|tip]] repozitáře, čelo s nejvyšším číslem revize. Revize 4 je [[MergeChangeset|slučovací changeset]], protože má dva rodičovské changesety (revize 2 a 3). == Klonování, slučování, akce pull a update == |
| Line 134: | Line 135: |
| Bertík si vytvoří [[Clone|klon]] tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčina uložiště ve svém vlastním adresáři: | Pracovní adresář (working directory) je opět uváděn jako poslední (potenciální) changeset. Bertík si vytvoří [[Clone|klon]] tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčina repozitáře ve svém vlastním adresáři: |
| Line 145: | Line 148: |
| Bertík nyní nezávisle na Alence vytvoří dvě změny e,f, které potvrdí příkazem [[Commit|commits]]: | Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny '''e''','''f''', které postupně potvrdí příkazem [[Commit|commit]]: |
| Line 158: | Line 161: |
| Alenka si vytvoří svou vlastní paralelní změnu g: | Alenka si vytvoří svou vlastní paralelní změnu '''g''': |
| Line 170: | Line 173: |
| Nyní se Bertík synchronizuje s Alenkou pomocí příkazu [[Pull|pull]]. Tímto příkazem přitáhne všechny změny Alenčina repozitáře (zde pouze změnu g) do svého repozitáře (zatím však nezměnil svůj pracovní adresář). Protože Bertíkova změna 'e' a Alenčina změna 'g' mají stejného rodiče, vytvoří se za revizí 'd' nová [[Branch|větev]]: | Nyní se Bertík synchronizuje s Alenkou pomocí příkazu [[Pull|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. |
| Line 185: | Line 189: |
| Protože Alenčino *géčko* je nejnovějším čelem Bertíkova repozitáře, je to také jeho '''tip'''. Bertík dále provede příkaz[[Merge|merge]] (sloučení), který spojí jeho poslední změnu (f) s tipem repozitáře. Nyní má jeho repozitář dvě rodičovské revize (f,g): |
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|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): |
| Line 204: | Line 209: |
| Po kontrole, že sloučení proběhlo v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|sloučený changeset]] h ve svém uložišti: | Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|slučující changeset]] '''h''' ve svém repozitáři: |
| Line 223: | Line 228: |
| Pokud si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, získá změny e,f a h: | Když si nyní Alenka přetáhne (příkazem [[Pull|pull]]) změny od Bertíka, přejdou do jejího repozitáře revize '''e''','''f''' a '''h''': |
| Line 242: | Line 247: |
| Vězme, že provedením příkazu pull se Alenčin pracovní adresář nezměnil. Musí ještě provést příkaz [[Update|update]] aby synchronizovala svůj pracovní adresář se staženým changesetem 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|update]] aby její pracovní adresář ukazoval na slučující changeset '''h'''. |
| Line 261: | Line 266: |
| Nyní jsou Alenčin a Bertíkův repozitář opět stejné. | Nyní jsou Alenčin a Bertíkův repozitář plně synchronizovány. |
| Line 265: | Line 270: |
Mercurial je decentralizovaný systém. Uživatelé si mohou zcela volně definovat své topologie pro sdílení změn (viz CommunicatingChanges): |
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: |
| Line 286: | Line 290: |
| Narozdíl od centralizovaných systémů správy verzí, u nichž experimentovámí 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. | 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. |
| Line 290: | Line 294: |
| Line 296: | Line 299: |
| Podrobnější úvod k používání Mercurialu lze nalézt v [[CzechTutorial]]. | ##Podrobnější text o používání Mercurialu viz [[CzechTutorial|Tutoriál pro Mercurial]]. |
| Line 298: | Line 301: |
| CategoryCzech CategoryCzech |
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ů.
Contents
1. Repozitář
Přísně vzato, repozitářem je pouze složka .hg, nalézající se v adresáři projektu. Adresář projektu, kterému se také říká pracovní adresář, obsahuje další sledované i nesledované soubory a složky. Sledované (verzované) položky jsou ty, které jsou registrovány v repozitáři.
Změny sledovaných (verzovaných) souborů se akcí commit ukládají jako revize, neboli changesety, do složky store v repozitáři.
Skladba a obsah souborů v pracovním adresáři (tak, jak je vidíme např. v Průzkumníku Windows) se mění v závislosti na momentálně nastavené aktuální revizi. Deklaraci aktuální revize lze změnit pouze další deklarací, třeba i v jiné seanci
Repozitář tedy obsahuje historii projektu, pracovní adresář obsahuje časový snímek projektu v určitém bodě historie.
Často se nepřesně jako repozitář označuje celý adresář projektu. Pracovní adresář má ale také dva významy. 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.
2. Co je v repozitáři
Změny projektu se ukládají ve složce .hg/store :
Složka store obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, je každý adresář projektu spojen se 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, nepříliš přesně označovaný také jako revize.
Přísně vzato, revize značí změnu souboru či složky. Jeden changeset (sada změn) může mít více revizí. Vhodnějším ekvivalentem pro slovo "changeset" by mohlo být slovo verze. Následující ilustrace ale používá termín "revize".
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ů, které jsou revizemi (verzemi) celého projektu. 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 tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčina repozitáře ve svém vlastním adresář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.
7. Co Mercurial neumí
Mnozí uživatelé SVN/CVS mohou mylně očekávat, že lze v jednom repozitáři sledovat více projektů. Pro toto použití není Mercurial stavěn.
Pokud je nezbytně nutné hostovat více projektů v jednom místě, je možné zkusit nástroj Subrepositář, který byl zaveden v Mercurialu 1.3 nebo starší ForestExtension.