|
Size: 10858
Comment:
|
Size: 11309
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. Do tohoto repozitáře se ukládají akcí ''commit'' změny sledovaných (také verzovaných) souborů, které se nacházejí v projektovém adresáři. Další složky a soubory tohoto adresáře vytvářejí tak zvaný '''pracovní prostor''', neboli [[WorkingDirectory|pracovní adresář]]. Repozitář obsahuje historii projektu, pracovní adresář obsahuje časový snímek (snapshot) projektu v určitém bodě historie. Jeho skladba je tedy proměnná. Často se nepřesně jako repozitář označuje celý adresář projektu. == Co je v repozitáři == Změny projektu se ukládají ve složce .hg/store : |
| Line 40: | Line 38: |
| label = "záznam v repozitáři"; | label = "složka .hg/store"; |
| Line 51: | Line 49: |
| 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 72: |
| label = "repozitář"; | label = "store"; |
| Line 86: | Line 85: |
| 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 88: |
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 117: |
| 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 131: |
| 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 144: |
| 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 157: |
| Alenka si vytvoří svou vlastní paralelní změnu g: | Alenka si vytvoří svou vlastní paralelní změnu '''g''': |
| Line 170: | Line 169: |
| 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 185: |
| 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 205: |
| 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 224: |
| 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 243: |
| 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 262: |
| 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 266: |
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 286: |
| 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 290: |
| Line 296: | Line 295: |
| 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 297: |
| 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. Do tohoto repozitáře se ukládají akcí commit změny sledovaných (také verzovaných) souborů, které se nacházejí v projektovém adresáři.
Další složky a soubory tohoto adresáře vytvářejí tak zvaný pracovní prostor, neboli pracovní adresář.
Repozitář obsahuje historii projektu, pracovní adresář obsahuje časový snímek (snapshot) projektu v určitém bodě historie. Jeho skladba je tedy proměnná.
Často se nepřesně jako repozitář označuje celý adresář projektu.
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.