|
Size: 10677
Comment:
|
Size: 12962
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| 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: [[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ář]]: |
#pragma section-numbers 2 #language cs ## page was renamed from CzechUnderstandingHg ## page was renamed from CzechUnderstandingMercurial ## page was renamed from Základy Mercurialu = 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ů. Postupný výklad viz [[CzechTutorial|Tutorial Mercurialu]]. <<TableOfContents>> == Pracovní adresář - repozitórium == Pracovní adresář v Mercuriálu má tyto vlastnosti: 1. Je to adresář, ve kterém právě pracujeme a je součástí souborového systému v počítači. Od běžného pracovního adresáře se liší tím, že jeho chování je ovlivňováno programem Mercuriál. Zaslouží si tedy vlastní označení - například '''repozitórium'''. 2. Obsahuje složku '''.hg''' neboli '''repozitář''' a případně další provozní soubory (.hgrc, .hgignore, ...). 3. Obsahuje soubory a složky, které jsou součástí projektu. Přítomnost všech těchto složek v adresáři je Mercuriálem reflektovaná, složky jsou přitom pojímány jenom jako objekty na cestě k souborům. Soubory, které jsou uvedeny v souboru ''.hgignore'', jsou Mercuriálem ignorovány. Soubory, jejichž název byl alespoň jednou akcí "commit" uložen do složky ''.hg/store/'' repozitáře, jsou soubory sledované. Míra pozornosti, které je soubor v pracovním adresáři vystaven, se označuje jako '''statut''' souboru a má tyto kategorie: . ''?'' - neznámý (nesledovaný) soubor, o němž Mercurial ví jen to, že existuje v repozitóriu . ''I'' - původně neznámý soubor, zařazený do seznamu ignorovaných souborů . ''A'' - původně neznámý soubor, zařazený jako kandidát pro komit . ''M'' - změněný sledovaný soubor, je kandidátem pro komit . ''!'' - původně sledovaný soubor, ručně smazaný, přejmenovaný či přemístěný . ''R'' - soubor, odebraný ze sledování příkazem ´´hg remove´´ 4. Je to '''pracovní kopie''' vybrané revize repozitáře, která umožňuje manipulaci se soubory a složkami projektu jako v normálním pracovním adresáři. Složení a obsah sledovaných souborů v pracovní kopii se mění v závislosti na nastavené '''aktuální''' revizi (viz hg update). V instruktážních schematech se pracovní kopie (pracovní adresář) zobrazuje jako potenciální changeset, vycházející z aktuální rodičovské revize. Komitované změny pracovní kopie představují nový changeset. Nekomitovaným změnám pracovní kopie se říká ''lokální modifikace''. Nemá-li pracovní kopie žádné lokální modifikace, říkáme, že je ''čistá''. Ideální skladba názvů popisovaných entit by tedy mohla být ''repozitórium'' - ''repozitář'' - ''pracovní kopie''. Musíme se však smířit s tím, že v anglických textech a schematech se setkáme pouze s termíny ''repozitář'' - ''pracovní adresář'' nebo dokonce s jediným, vše zahrnujícím termínem ''repozitář''. Zcela běžně se pro jednu a tutéž komitovanou změnu používají slova ''revize'', ''changeset'' a ''komit''. Repozitórium budiž tedy vnímavý kořenový adresář projektu, který obsahuje složku '''.hg''', zvanou [[Repository|repozitář]] a další složky a soubory, které tvoří sledovaný (pracovní kopii) i nesledovaný obsah projektu. == Repozitář == Repozitář je technicky vzato složka '''.hg''' v repozitóriu. Následující ilustrace se pokouší naznačit situaci, kdy rodičovskou revizí pracovní kopie (pracovního adresáře) je revize č. 2, uložená ve složce .hg/store. Subsložka '''.hg/store''' obsahuje kompletní historii projektu. |
| Line 32: | Line 65: |
| label="working directory"; | label="pracovní adresář - repozitórium"; |
| Line 37: | Line 70: |
| "main.c" -> "main.h" -> ".hgignore" -> ".hgtags"; | "main.c" -> "main.h" -> ".hgignore" -> ".hg/"; |
| Line 40: | Line 73: |
| label = "store"; | label = "složka .hg/store"; |
| Line 47: | Line 80: |
| "main.c" -> "rev 2" [ltail=cluster_0, label="parent", labeldistance=5, minlen=2]; } }}} 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]]"): |
"main.h" -> "rev 2" [ltail=cluster_0, label="parent", labeldistance=5, minlen=2]; } }}} == Registrace změn - komit == Provedením příkazu ''hg commit'' se stav pracovního adresáře zapíše jako nový [[ChangeSet|changeset]] neboli [[Revision|revize]] do repozitáře. /* |
| Line 66: | Line 96: |
| label="working directory"; | label="pracovní adresář"; |
| Line 82: | Line 112: |
| "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 85: | Line 115: |
| }}} 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 již existovala revize 3 a aktuální revizí pracovního adresáře v té chvíli byla revize 2. Revize 4 zakládá novou '''[[Branch|větev]]''' v historii changesetů a je ''rodičem'' pracovního adresáře. == Revize, changesety, čela a tip == Mercurial sdružuje změny ve více souborech do jednotlivých atomických (nedělitelných) [[ChangeSet|changesetů]]. 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 105: | Line 136: |
| workingdir [label="{{<p1> p1 | <p2> p2} | working directory}"]; | workingdir [label="{{<p1> p1 | <p2> p2} | pracovní adresář}"]; |
| Line 114: | Line 145: |
| 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" } }}} [[Branch|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''' (hrot) repozitáře, čelo s nejvyšším číslem revize. Revize 4 je [[MergeChangeset|slučovací]], 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ě: {{{#!dot digraph { label="Alenčin repozitář" |
| Line 135: | Line 163: |
| 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ář (working directory) je opět uváděn jako poslední (potenciální) changeset. Bertík si vytvoří klon Alenčina projektu ve svém vlastním počítači: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 147: | Line 176: |
| 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é postupně zaregistruje příkazem commit: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 160: | Line 189: |
| 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'''. Odlišné repozitáře v této chvíli představují dvě odlišné [[Branch|větve]] jejich společného projektu. {{{#!dot digraph { label="Alenčin repozitář" |
| Line 173: | Line 201: |
| 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''. Tímto příkazem zkopíruje všechny změny Alenčina repozitáře (zde tedy pouze změnu g) do svého repozitáře. Jeho pracovní adresář však zůstává nezměněn. {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 190: | Line 217: |
| 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 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|merge]] (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) repozitáře. Jeho pracovní adresář má nyní dvě rodičovské revize (f, g): {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 210: | Line 237: |
| 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 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: {{{#!dot digraph { label="Bertíkův repozitář" |
| Line 231: | Line 256: |
| 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 ''hg pull'' změny od Bertíka, přejdou do jejího repozitáře revize '''e''','''f''' a '''h''': {{{#!dot digraph { label="Alenčin repozitář" |
| Line 250: | Line 275: |
| 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šimněme si, že po provedení příkazu ''pull'' je Alenčin pracovní adresář stále potomkem revize '''g'''. Alenka musí ještě provést příkaz ''update'' aby její pracovní adresář ukazoval na slučující changeset '''h''' a aby aktualizoval soubory v jejím pracovním adresáři vzhledem k revizi '''h'''. {{{#!dot digraph { label="Alenčin repozitář" |
| Line 271: | Line 294: |
| 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áře opět plně synchronizovány. == Decentralizovaný systém == Mercurial je úplně decentralizovaný systém bez centrá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: {{{#!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á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. ##Podrobnější text o používání Mercurialu viz [[CzechTutorial|Tutoriál pro Mercurial]]. |
| Line 311: | Line 324: |
| 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ů. Postupný výklad viz Tutorial Mercurialu.
Contents
1. Pracovní adresář - repozitórium
Pracovní adresář v Mercuriálu má tyto vlastnosti:
Je to adresář, ve kterém právě pracujeme a je součástí souborového systému v počítači. Od běžného pracovního adresáře se liší tím, že jeho chování je ovlivňováno programem Mercuriál. Zaslouží si tedy vlastní označení - například repozitórium.
Obsahuje složku .hg neboli repozitář a případně další provozní soubory (.hgrc, .hgignore, ...).
- Obsahuje soubory a složky, které jsou součástí projektu. Přítomnost všech těchto složek v adresáři je Mercuriálem reflektovaná, složky jsou přitom pojímány jenom jako objekty na cestě k souborům.
Soubory, které jsou uvedeny v souboru .hgignore, jsou Mercuriálem ignorovány. Soubory, jejichž název byl alespoň jednou akcí "commit" uložen do složky .hg/store/ repozitáře, jsou soubory sledované.
Míra pozornosti, které je soubor v pracovním adresáři vystaven, se označuje jako statut souboru a má tyto kategorie:
? - neznámý (nesledovaný) soubor, o němž Mercurial ví jen to, že existuje v repozitóriu
I - původně neznámý soubor, zařazený do seznamu ignorovaných souborů
A - původně neznámý soubor, zařazený jako kandidát pro komit
M - změněný sledovaný soubor, je kandidátem pro komit
! - původně sledovaný soubor, ručně smazaný, přejmenovaný či přemístěný
R - soubor, odebraný ze sledování příkazem ´´hg remove´´
Je to pracovní kopie vybrané revize repozitáře, která umožňuje manipulaci se soubory a složkami projektu jako v normálním pracovním adresáři. Složení a obsah sledovaných souborů v pracovní kopii se mění v závislosti na nastavené aktuální revizi (viz hg update).
V instruktážních schematech se pracovní kopie (pracovní adresář) zobrazuje jako potenciální changeset, vycházející z aktuální rodičovské revize. Komitované změny pracovní kopie představují nový changeset. Nekomitovaným změnám pracovní kopie se říká lokální modifikace. Nemá-li pracovní kopie žádné lokální modifikace, říkáme, že je čistá.
Ideální skladba názvů popisovaných entit by tedy mohla být repozitórium - repozitář - pracovní kopie. Musíme se však smířit s tím, že v anglických textech a schematech se setkáme pouze s termíny repozitář - pracovní adresář nebo dokonce s jediným, vše zahrnujícím termínem repozitář.
Zcela běžně se pro jednu a tutéž komitovanou změnu používají slova revize, changeset a komit.
Repozitórium budiž tedy vnímavý kořenový adresář projektu, který obsahuje složku .hg, zvanou repozitář a další složky a soubory, které tvoří sledovaný (pracovní kopii) i nesledovaný obsah projektu.
2. Repozitář
Repozitář je technicky vzato složka .hg v repozitóriu.
Následující ilustrace se pokouší naznačit situaci, kdy rodičovskou revizí pracovní kopie (pracovního adresáře) je revize č. 2, uložená ve složce .hg/store.
Subsložka .hg/store obsahuje kompletní historii projektu.
3. Registrace změn - komit
Provedením příkazu hg commit se stav pracovního adresáře zapíše jako nový changeset neboli revize do repozitáře.
