|
Size: 10677
Comment:
|
Size: 10398
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]] )'' <<Obsah>> == 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. Skladba i stav souborů se mění podle aktuální revize. Aktuální skladba souborů kořenového adresáře se nazývá [[WorkingDirectory|pracovní adresář]]: |
<<TableOfContents>> == Co je v repozitáři == [[Repository|Repozitář]] Mercurialu obsahuje [[WorkingDirectory|pracovní adresář]]a úložný prostor: |
| Line 32: | Line 24: |
| label="working directory"; | label="pracovní adresář"; |
| Line 40: | Line 32: |
| label = "store"; | label = "záznam v repozitáři"; |
| Line 51: | Line 43: |
| The store contains the '''complete''' history of the project. Unlike traditional [[SCM|SCMs]], where there's only one central copy of this history, every working directory is paired with a private copy of the history. This allows development to go on in parallel. The working directory contains a copy of the project's files at a given point in time (eg rev 2), ready for editing. Because [[Tag|tags]] and [[.hgignore|ignored files]] are revision-controlled, they are also included. == Committing Changes == When you [[Commit|commit]], the state of the working directory relative to its [[Parent|parents]] is recorded as a new [[ChangeSet|changeset]] (also called a new "[[Revision|revision]]"): |
Ú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 66: | Line 57: |
| label="working directory"; | label="pracovní adresář"; |
| Line 74: | Line 65: |
| label = "store"; | label = "repozitář"; |
| Line 82: | Line 73: |
| "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="parent before commit"] | "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="rodič rev. 3 a 4"] |
| Line 87: | Line 78: |
| Note here that revision 4 is a '''[[Branch|branch]]''' of revision 2, which was the revision in the working directory. Now revision 4 is the working directory's '''parent'''. == Revisions, Changesets, Heads, and Tip == Mercurial groups related changes to multiple files into single atomic [[ChangeSet|changesets]], which are revisions of the whole project. These each get a sequential [[RevisionNumber|revision number]]. Because Mercurial allows distributed parallel development, these revision numbers may disagree between users. 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". |
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. == Revize, changesety, čela a tip == 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 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 105: | Line 98: |
| workingdir [label="{{<p1> p1 | <p2> p2} | working directory}"]; | workingdir [label="{{<p1> p1 | <p2> p2} | pracovní adresář}"]; |
| Line 114: | Line 107: |
| 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 (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. == 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 135: | Line 126: |
| 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" |
Pracovní adresář je pro úplnost 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 uložiště ve svém vlastním adresáři: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 147: | Line 139: |
| 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í může pracovat nezávisle na Alence. Vytvoří dvě změny '''e''','''f''', které potvrdí příkazem [[Commit|commit]]: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 160: | Line 152: |
| 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 173: | Line 164: |
| 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. 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): {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 190: | Line 179: |
| 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" |
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í": {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 210: | Line 197: |
| 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í je v pořádku, vytvoří Bertík příkazem commit [[MergeChangeset|sloučený changeset]] '''h''' ve svém repozitáři: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 231: | Line 216: |
| 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" |
Když 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 250: | Line 235: |
| 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š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. {{{#!dot digraph { label="Alenčin repozitář" |
| Line 271: | Line 254: |
| 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" } }}} 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. == 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ší text o používání Mercurialu viz [[CzechTutorial|Tutoriál pro Mercurial]]. |
| Line 311: | 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í 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.