|
Size: 10760
Comment:
|
Size: 10858
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 86: | Line 86: |
| 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 aktuální při vzniku revize 4. Revize 4 je '''rodič''' revizí 3 a 4. | 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. |
| Line 93: | Line 93: |
So Mercurial also assigns each revision a global [[ChangeSetID|changeset ID]]. Changeset IDs are 40-digit hexadecimal numbers, but they can be abbreviated to any unambiguous prefix, like "e38487". |
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". |
| Line 107: | Line 106: |
| workingdir [label="{{<p1> p1 | <p2> p2} | working directory}"]; | workingdir [label="{{<p1> p1 | <p2> p2} | pracovní adresář}"]; |
| Line 116: | Line 115: |
| label="example repository" } }}} Branches and [[Merge|merges]] in the revision history can occur at any point. Each unmerged branch creates a new [[Head|head]] of the revision history. Here, revisions 5 and 6 are heads. Mercurial considers revision 6 to be the [[Tip|tip]] of the repository, the head with the highest revision number. Revision 4 is a [[MergeChangeset|merge changeset]], as it has ''two'' parent changesets (revisions 2 and 3). == Cloning, Making Changes, Merging, Pulling and Updating == Let's start with a user Alice, who has a repository that looks like: {{{#!dot digraph { label="Alice's repo" |
label="příklad záznamu v repozitáři" } }}} 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 == Začněme s Alenkou, jejíž repozitář vypadá následovně: {{{#!dot digraph { label="Alenčin repozitář" |
| Line 137: | Line 134: |
| Bob [[Clone|clones]] this repo, and ends up with a complete, independent, local copy of Alice's store and a clean checkout of the tipmost revision d in his working directory: {{{#!dot digraph { label="Bob's repo" |
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: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 149: | Line 145: |
| Bob can now work independently of Alice. He then [[Commit|commits]] two changes e and f: {{{#!dot digraph { label="Bob's repo" |
Bertík nyní nezávisle na Alence vytvoří dvě změny e,f, které potvrdí příkazem [[Commit|commits]]: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 162: | Line 158: |
| Alice then makes her own change g in parallel, which causes her repository store to diverge from Bob's, thus creating a [[Branch|branch]]: {{{#!dot digraph { label="Alice's repo" |
Alenka si vytvoří svou vlastní paralelní změnu g: {{{#!dot digraph { label="Alenčin repozitář" |
| Line 175: | Line 170: |
| Bob then [[Pull|pulls]] Alice's repo to synchronize. This copies all of Alice's changes into Bob's repository store (here, it's just a single change g). Note that Bob's working directory is '''not''' changed by the pull: {{{#!dot digraph { label="Bob's repo" |
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]]: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 192: | Line 185: |
| Because Alice's '''g''' is the newest head in Bob's repository, it's now the '''tip'''. Bob then does a [[Merge|merge]], which combines the last change he was working on (f) with the tip in his repository. Now, his working directory has two parent revisions (f and g): {{{#!dot digraph { label="Bob's repo" |
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): {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 212: | Line 204: |
| After examining the result of the merge in his working directory and making sure the merge is perfect, Bob commits the result and ends up with a new [[MergeChangeset|merge changeset]] h in his store: {{{#!dot digraph { label="Bob's repo" |
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: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 233: | Line 223: |
| Now if Alice '''pulls''' from Bob, she will get Bob's changes e, f, and h into her store: {{{#!dot digraph { label="Alice's repo" |
Pokud si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, získá změny e,f a h: {{{#!dot digraph { label="Alenčin repozitář" |
| Line 252: | Line 242: |
| Note that Alice's working directory was not changed by the pull. She has to do an [[Update|update]] to synchronize her working directory to the merge changset h. This changes the parent changeset of her working directory to changeset h and updates the files in her working directory to revision h. {{{#!dot digraph { label="Alice's repo" |
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. {{{#!dot digraph { label="Alenčin repozitář" |
| Line 273: | Line 261: |
| Now Alice and Bob are fully synchronized again. == A Decentralized System == Mercurial is a completely decentralized system, and thus has no internal notion of a central repository. Thus users are free to define their own topologies for sharing changes (see CommunicatingChanges): {{{#!dot digraph { Alice -> Central Central -> Alice Bob -> Central Alice -> Bob Alice -> Carl Carl -> Central Bob -> Carl Carl -> Bob "Carl's Laptop" -> Carl Carl -> "Carl's Laptop" "Carl's Laptop" -> Central Central [style=fill;color=blue;label="Main Public Repo"] label="A Mercurial Network" } }}} Unlike a centralized version control system in which experimentation can be disastrous, with a DVCS like Mercurial, you just clone and experiment. If you like the results, push them back, otherwise wipe the cloned repository and try something else. == What Mercurial can't do == Many SVN/CVS users expect to host related projects together in one repository. This is really not what Mercurial was made for, so you should try a different way of working. In particular, this means that you cannot check out only one directory of a repository. If you absolutely need to host multiple projects in a kind of meta-repository though, you could try the [[subrepos|Subrepositories]] feature that was introduced with Mercurial 1.3 or the older ForestExtension. For a hands-on introduction to using Mercurial, see the [[Tutorial]]. |
Nyní jsou Alenčin a Bertíkův repozitář opět stejné. == Decentralizovaný systém == Mercurial je decentralizovaný systém. Uživatelé si mohou zcela volně definovat své topologie pro sdílení změn (viz CommunicatingChanges): {{{#!dot digraph { Alenka -> Centrum Centrum -> Alenka Bertík -> Centrum Alenka -> Bertík Alenka -> Karel Karel -> Centrum Bertík -> Karel Karel -> Bertík "Karlův laptop" -> Karel Karel -> "Karlův laptop" "Karlův laptop" -> Centrum Centrum [style=fill;color=blue;label="Main Public Repo"] label="Síť Mercurialu" } }}} 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. == 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 [[subrepos|Subrepositář]], který byl zaveden v Mercurialu 1.3 nebo starší ForestExtension. Podrobnější úvod k používání Mercurialu lze nalézt v [[CzechTutorial]]. |
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ů.
See the Tutorial for step-by-step instructions.
(Translations: Brazilian Portuguese, Chinese, Czech, French, German, Italian, Japanese, Korean, Russian, Spanish, Thai )
Contents
Co je repozitář
Termín 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 pracovním adresáři.Obsah pracovního adresáře se mění podle nastavené aktuální revize:
Repozitář obsahuje úplnou historii projektu. Na rozdíl od tradičních 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ů ignorovaných.
Předávání 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:
Výše uvedená ilustrace není příliš ilustrativní. Vězme, že revize 4 byla vytvořena po revizi 3 jako větvení revize 2, jež byla při vzniku revize 4 aktuální. Revize 4 je rodič revizí 3 a 4.
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 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í 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".
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 (revisions 2 and 3). Pracovní adresář je ve schematu potenciálním changesetem.
Klonování, slučování, akce Pull a Update
Začněme s Alenkou, jejíž repozitář vypadá následovně:
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í nezávisle na Alence vytvoří dvě změny e,f, které potvrdí příkazem commits:
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 (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á větev:
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říkazmerge (sloučení), který spojí jeho poslední změnu (f) s tipem repozitáře. Nyní má jeho repozitář dvě rodičovské revize (f,g):
Po kontrole, že sloučení proběhlo v pořádku, vytvoří Bertík příkazem commit sloučený changeset h ve svém uložišti:
Pokud si nyní Alenka přetáhne (příkazem pull) změny od Bertíka, získá změny e,f a h:
Vězme, že provedením příkazu pull se Alenčin pracovní adresář nezměnil. Musí ještě provést příkaz update aby synchronizovala svůj pracovní adresář se staženým changesetem h.
Nyní jsou Alenčin a Bertíkův repozitář opět stejné.
Decentralizovaný systém
Mercurial je decentralizovaný systém. Uživatelé si mohou zcela volně definovat své topologie pro sdílení změn (viz CommunicatingChanges):
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.
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.
Podrobnější úvod k používání Mercurialu lze nalézt v CzechTutorial.