|
Size: 10940
Comment:
|
Size: 11281
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| Přísně vzato, '''repozitář''' je složka .hg, nalézající se v kořenovém adresáři projektu. Další složky a soubory kořenového adresáře vytvářejí tak zvaný pracovní prostor, neboli '''pracovní adresář'''. | Přísně vzato, '''repozitář''' je složka .hg, nalézající se v kořenovém adresáři projektu. Další složky a soubory kořenového adresáře vytvářejí tak zvaný '''pracovní prostor''', neboli [[WorkingDirectory|pracovní adresář]]. |
| Line 20: | Line 20: |
| [[Repository|Repozitář]] Mercurialu obsahuje [[WorkingDirectory|pracovní adresář]] a úložný prostor: | [[Repository|Repozitáře]] Mercurialu obsahují (kromě jiného) složku '''store''': |
| Line 36: | Line 36: |
| label = "složka store"; | label = "složka .git/store"; |
| Line 49: | Line 49: |
| Pracovní adresář obsahuje kopii projektových souborů ze zadaného času (např. rev. 2) včetně [[Tag|tagů]] a [[.hgignore|ignorovaných souborů]], které jsou rovněž verzovány. | 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 rovněž verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře. |
| Line 52: | Line 52: |
| Provedením příkazu [[Commit|commit]] se změny v pracovním adresáři zapíší do nového [[ChangeSet|changesetu]] (neboli nové [[Revision|revize]]). Změny se vztahují k [[Parent|rodičovské]] revizi: | Provedením příkazu [[Commit|commit]] se stav pracovního adresáře vztažený ke svým [[Parents|rodičům]] zapíše jako nový [[ChangeSet|changeset]], nesprávně 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 bylo slovo '''verze'''. Následující ilustrace ale používá termín "revize". |
| Line 81: | Line 83: |
| Revize 4 byla vytvořena v situaci, kdy pro [[WorkingDirectory|pracovní adresář]] byla aktuální revize 2 v době, kdy už existovala revize 3. Revize 4 tvoří novou '''[[Branch|větev]]''' v historii changesetů. | Revize 4 byla vytvořena v situaci, kdy již existovala revize 3 a aktuální revizí pracovního adresáře byla revize 2. Revize 4 tvoří novou '''[[Branch|větev]]''' v historii changesetů. |
| Line 84: | Line 86: |
| Mercurial sdružuje změny jednoho či více souborů do jednotlivých atomických (nedělitelných) [[ChangeSet|changesetů]], které jsou revizemi celého projektu. Každému changesetu je přiřazeno pořadové [[RevisionNumber|číslo revize]]. Protože Mercurial umožňuje necentralizovaný paralelní vývoj projektů, bývají tato čísla u různých uživatelů různá. Proto Mercurial uděluje 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". |
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 113: | Line 115: |
| Větvení a [[Merge|slučování]] se může vyskytnout kdekoliv v historii revizí. Každá nesloučená větev vytváří nové [[Head|čelo]] (head) historie revizí. 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). | 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). |
| Line 127: | Line 129: |
| Pracovní adresář je opět uváděn jako poslední (potenciální) changeset. | Pracovní adresář (working directory) je opět uváděn jako poslední (potenciální) changeset. |
| Line 165: | Line 167: |
| 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 'store' 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''', která jako nejnovější nese také označení '''tip'''. Všimneme si, že se Bertíkův pracovní adresář přikazem '''pul''' nezměnil: | 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 179: | Line 182: |
Protože nejnovějším čelem v Bertíkově repozitáři je Alenčin changeset '''g''', je nositelem označení ''tip''. |
|
| Line 198: | Line 203: |
| Po kontrole, že sloučení je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|sloučený changeset]] '''h''' ve svém 'store': | 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 217: | Line 222: |
| Když si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, přejdou do jejího 'store' revize '''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 236: | Line 241: |
| 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 sloučeným changesetem '''h''' (tip). Ten se stane rodičovským changesetem jejího pracovního adresáře. | Všimneme si, že provedením příkazu pull se Alenčin pracovní adresář rovněž nezměnil. Ta musí ještě provést příkaz [[Update|update]] aby synchronizovala svůj pracovní adresář se slučujícím changesetem '''h'''. Ten se stane rodičovským changesetem jejího pracovního adresáře. |
| Line 255: | Line 260: |
| Nyní jsou Alenčin a Bertíkův repozitář opět stejné. == Necentralizovaný systém == Mercurial je zcela necentralizovaný (distributed) systém. Uživatelé si mohou volně definovat své topologie pro sdílení změn (viz CommunicatingChanges): |
Nyní jsou Alenčin a Bertíkův repozitář plně synchronizovány. == 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: |
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ář je složka .hg, nalézající se v kořenovém adresáři projektu. Další složky a soubory kořenového 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ý kořenový adresář.
2. Co je v repozitáři
Repozitáře Mercurialu obsahují (kromě jiného) složku store:
Složka store 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 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 rovněž verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře.
3. Potvrzení změn
Provedením příkazu commit se stav pracovního adresáře vztažený ke svým rodičům zapíše jako nový changeset, nesprávně 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 bylo 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 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činy složky 'store' 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 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) jeho repozitáře (g). 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 provedením příkazu pull se Alenčin pracovní adresář rovněž nezměnil. Ta musí ještě provést příkaz update aby synchronizovala svůj pracovní adresář se slučujícím changesetem h. Ten se stane rodičovským changesetem jejího pracovního adresáře.
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.