|
Size: 10858
Comment:
|
Size: 10399
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #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 11: |
| 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 14: |
| == 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: |
== Co je v repozitáři == [[Repository|Repozitář]] Mercurialu obsahuje [[WorkingDirectory|pracovním adresář]]a úložný prostor: |
| Line 51: | Line 43: |
| 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: |
Úložný prostor obsahuje **úplnou** historii projektu. Na rozdíl od tradičních [[SCM|SCM]], kde existuje pouze jedna centrální kopie této historie, je každý pracovní adresář spojen se svou vlastní kopii historie. To umožňuje paralelní vývoj projektů. Pracovní adresář obsahuje projektové soubory, odpovídající zadané aktuální revizi, včetně souborů [[Tag|.hgtags]] a [[.hgignore|.hgignore]]. == Potvrzení 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: |
| Line 86: | Line 78: |
| 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 revize 2 byla "zpřítomněna" pro [[WorkingDirectory|pracovní adresář]] v době, kdy už existovala revize 3. Revize 4 tvoří novou '''[[Branch|větev]]''' v historii changesetů a je zároveň '''rodičem''' aktuálního pracovního adresáře. |
| Line 92: | Line 84: |
| 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". |
Každému changesetu je přiřazeno pořadové [[RevisionNumber|číslo revize]]. Protože Mercurial umožňuje rozdělený paralelní vývoj projektů, bývají tato čísla 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ř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 111: |
| 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. | 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 (revize 2 a 3). Pracovní adresář je ve schematu uveden jenom pro úplnost; nemusí být vždy synchronizován jen s posledním changesetem. |
| Line 134: | Line 126: |
| Pracovní adresář je pro úplnost uváděn jako poslední (potenciální) changeset. |
|
| Line 145: | Line 139: |
| 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é potvrdí příkazem [[Commit|commit]]: |
| Line 158: | Line 152: |
| Alenka si vytvoří svou vlastní paralelní změnu g: | Alenka si vytvoří svou vlastní paralelní změnu '''g''': |
| Line 170: | Line 164: |
| 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 přitáhne všechny změny Alenčina repozitáře (zde pouze změnu g) do svého repozitáře. 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]] '''g''' (tip): |
| Line 185: | Line 179: |
| 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): |
Bertík dále provede příkaz [[Merge|merge]] (sloučení), který spojí jeho poslední změnu (f) s posledním changesetem (tipem) repozitáře (g). K tomuto sloučení dojde pouze v pracovním adresáři, repozitář o něm ještě "neví": |
| Line 204: | Line 197: |
| 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, že sloučení je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|sloučený changeset]] '''h''' ve svém repozitáři: |
| Line 223: | Line 216: |
| 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) změny od Bertíka, získá změny '''e''','''f''' a '''h''': |
| Line 242: | Line 235: |
| 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 provedením příkazu pull se Alenčin pracovní adresář nezměnil. Ta musí ještě provést příkaz [[Update|update]] aby synchronizovala svůj pracovní adresář se staženým changesetem '''h''' (tip) v repozitáři. |
| Line 286: | Line 279: |
| 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á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. |
| Line 296: | Line 289: |
| 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 291: |
| 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. Co je v repozitáři
Repozitář Mercurialu obsahuje pracovním adresářa úložný prostor:
Úložný prostor obsahuje **úplnou** historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie této historie, je každý pracovní adresář spojen se svou vlastní kopii historie. To umožňuje paralelní vývoj projektů.
Pracovní adresář obsahuje projektové soubory, odpovídající zadané aktuální revizi, včetně souborů .hgtags a .hgignore.
2. Potvrzení změn
Provedením příkazu commit se změny v aktuálním pracovním adresáři zapíší do nového changesetu (neboli nové revize). Změny se vztahují k rodičovské revizi:
Revize 4 byla vytvořena v situaci, kdy revize 2 byla "zpřítomněna" pro pracovní adresář v době, kdy už existovala revize 3. Revize 4 tvoří novou větev v historii changesetů a je zároveň rodičem aktuálního pracovního adresáře.
3. Revize, changesety, čela a tip
Mercurial sdružuje provedené změny do atomických (nedělitelných) changesetů, které jsou revizemi v rámci jednoho repozitáře. Každému changesetu je přiřazeno pořadové číslo revize. Protože Mercurial umožňuje rozdělený paralelní vývoj projektů, bývají tato čísla v různých repozitářích různá. Kromě lokálních pořadových čísel má každá revize 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 revizí. Každé rozvětvení 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 sloučený changeset, protože má dva rodičovské changesety (revize 2 a 3). Pracovní adresář je ve schematu uveden jenom pro úplnost; nemusí být vždy synchronizován jen s posledním changesetem.
4. Klonování, slučování, akce Pull a Update
Začněme s Alenkou, jejíž repozitář vypadá následovně:
Pracovní adresář je pro úplnost 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 uložiště ve svém vlastním adresáři:
Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny e,f, které 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 přitáhne všechny změny Alenčina repozitáře (zde pouze změnu g) do svého repozitáře. Protože Bertíkova změna e a Alenčina změna g mají stejného rodiče, vytvoří se za revizí d nová větev g (tip):
Bertík dále provede příkaz merge (sloučení), který spojí jeho poslední změnu (f) s posledním changesetem (tipem) repozitáře (g). K tomuto sloučení dojde pouze v pracovním adresáři, repozitář o něm ještě "neví":
Po kontrole, že sloučení je v pořádku, vytvoří Bertík příkazem commit sloučený changeset h ve svém repozitáři:
Když si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, získá změny e,f a h:
Všimneme si, že provedením příkazu pull se Alenčin pracovní adresář nezměnil. Ta musí ještě provést příkaz update aby synchronizovala svůj pracovní adresář se staženým changesetem h (tip) v repozitáři.
Nyní jsou Alenčin a Bertíkův repozitář opět stejné.
5. Decentralizovaný systém
Mercurial je decentralizovaný systém. Uživatelé si mohou zcela volně definovat své topologie pro sdílení změn (viz CommunicatingChanges):
Na rozdí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.
6. 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.