Differences between revisions 33 and 36 (spanning 3 versions)
Revision 33 as of 2011-03-17 19:55:02
Size: 10201
Editor: Tovim
Comment:
Revision 36 as of 2011-03-17 20:43:50
Size: 10434
Editor: Tovim
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
= Základní pojmy Mercurialu = == Základní pojmy Mercurialu ==
Line 13: Line 13:
Line 128: Line 129:
Bertík si vytvoří [[Clone|klon]] tohoto repozitáře a tím získá úplnou, nezávislou lokální kopii Alenčina uložtě ve svém vlastním adresáři: Bertík si vytvoří [[Clone|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:
Line 164: Line 165:
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): 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:
Line 180: Line 181:
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í": Bertík dále provede příkaz [[Merge|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):
Line 197: Line 198:
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: Po kontrole, že sloučení je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|sloučený changeset]] '''h''' ve svém 'store':
Line 216: Line 217:
Když 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, přejdou do jejího 'store' revize '''e''','''f''' a '''h''':
Line 235: Line 236:
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š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.
Line 257: Line 258:
== Decentralizovaný systém ==

Mercurial je decentralizovaný systém. Uživatelé si mohou zcela volně definovat své topologie pro sdílení změn (viz CommunicatingChanges):
== 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):
Line 279: Line 280:
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. 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.

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

Co je v repozitáři

Repozitář Mercurialu obsahuje pracovní adresář a úložný prostor:

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ů ze zadaného času (např. rev. 2) včetně tagů a ignorovaných souborů, které jsou rovněž verzovány.

Potvrzení změn

Provedením příkazu commit se změny v 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 pro pracovní adresář byla aktuální revize 2 v době, kdy už existovala revize 3. Revize 4 tvoří novou větev v historii changesetů.

Revize, changesety, čela a tip

Mercurial sdružuje změny jednoho či více souborů do jednotlivých atomických (nedělitelných) changesetů, které jsou revizemi celého projektu. Každému changesetu je přiřazeno pořadové čí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í 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á nesloučená větev vytváří nové čelo (head) historie revizí. 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).

Klonování, slučování, akce Pull a Update

Začněme s Alenkou, jejíž repozitář vypadá následovně:

Pracovní adresář 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 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á 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:

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, že sloučení je v pořádku, vytvoří Bertík příkazem commit sloučený changeset h ve svém 'store':

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:

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 sloučeným changesetem h (tip). Ten se stane rodičovským changesetem jejího pracovního adresáře.

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):

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.

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.


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