Differences between revisions 74 and 115 (spanning 41 versions)
Revision 74 as of 2012-12-15 10:33:55
Size: 11249
Editor: Tovim
Comment:
Revision 115 as of 2018-08-03 18:27:01
Size: 13437
Editor: Tovim
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
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ů. 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]].
Line 11: Line 11:
== Repozitórium ==

Repozitórium je pracovní adresář Mercuriálu, který se od běžného pracovního adresáře liší tím, že jeho chování je ovlivňováno programem Mercurial:

 1. Obsahuje složku '''.hg''' neboli '''repozitář''' a případně další provozní soubory (.hgrc, .hgignore, ...).

 2. Obsahuje soubory a složky, které jsou součástí projektu. Přítomnost všech těchto polož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`, `pull` či `push` uložen do složky ''.hg/store/'' repozitáře, jsou soubory sledované.

Míra pozornosti, které je soubor v repozitóriu 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´´

Sledované soubory jsou v repozitóriu zastoupeny v závislosti na (vybrané) '''aktuální''' revizi. Aktuálně nastavená starší revize jako ''aktuální'' může v repozitóriu prezentovat soubor, který jsme později z repozitória odebrali!

Nesledované soubory (včetně ignorovaných) jsou v repozitóriu přítomny trvale - pokud nejsou smazány.

Repozitórium je tedy vnímavý kořenový adresář projektu, který obsahuje složku '''.hg''', zvanou '''repozitář''' a další soubory a složky, které tvoří sledovaný i nesledovaný obsah projektu.

Line 13: Line 40:
Přísně vzato, [[Repository|repozitářem]] je pouze složka '''.hg''', nalézající se v adresáři projektu. Adresář projektu, kterému se také říká [[WorkingDirectory|pracovní adresář]], obsahuje další sledované i nesledované soubory a složky. Sledované (verzované) položky jsou ty, které jsou registrovány v repozitáři.

Změny sledovaných souborů se akcí ''commit'' ukládají jako revize, neboli changesety, do složky store v repozitáři.

Skladba a obsah souborů v pracovním adresáři (tak, jak je vidíme např. v Průzkumníku Windows) se mění v závislosti na momentálně nastavené aktuální revizi. Deklaraci aktuální revize lze změnit pouze další deklarací, třeba i v jiné seanci.

Repozitář tedy obsahuje historii projektu, pracovní adresář obsahuje časový snímek projektu v určitém bodě historie.

Často se nepřesně jako repozitář označuje celý adresář projektu. Pracovní adresář má ale také dva významy. Jak lze vidět ve schematech 5. odstavce, je jako pracovní adresář (working directory) označován poslední, nekomitovaný changeset.

Dalším mlhavým termínem je lokální kopie. Tímto souslovím je často označován aktuální obsah pracovního adresáře, který jak už víme, reflektuje aktuální revizi.

== Co je v repozitáři ==
Změny projektu se ukládají ve složce .hg/store :

{{{#!dot
digraph G {
[[CzechRepository|Repozitář]] je stručně vzato složka '''.hg''' v repozitóriu. Se složkou .hg se nemá manipulovat. Subsložka ''.hg/store'', obsahuje kompletní historii projektu.


== Pracovní kopie ==

Uživatelský přístup (možnost prohlížení a editace souborů) k jednotlivým changesetům repozitáře zajišťuje mechanizmus tak zvané "pracovní kopie", která je vždy spojena s určitým (aktuálním) changesetem. Pracovní kopie je editovatelná kopie rodičovského changesetu, jímž nemusí vždy být changeset poslední.


{{{#!dot
 digraph G {
Line 31: Line 51:
 compound=true;  compound=false;
Line 33: Line 53:
 subgraph cluster_0 {
  label="pracovní adresář";
  style=filled;
  color=lightgrey;
  node [style=filled,color=white];
  edge [style=invis];
  "main.c" -> "main.h" -> ".hgignore" -> ".hgtags";
 }
 
Line 42: Line 55:
  label = "složka .hg/store";   label = "Repozitář (.hg/store)";
Line 47: Line 60:
  "rev 0" -> "rev 1" -> "rev 2" -> "rev 3" [dir=back, label="parent"];   "rev 0" -> "rev 1" -> "rev 2" -> "Pracovní kopie" [dir=back, label="parent"];
Line 49: Line 62:
## "main.c" -> "rev 2" [ltail=cluster_0, label="parent", labeldistance=5, ##minlen=2];
}
}}}

Složka '''store''' obsahuje kompletní historii projektu. Na rozdíl od tradičních SCM, kde existuje pouze jedna centrální kopie historie, zde má každý adresář projektu 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 [[Tag|tagy]] a [[.hgignore|ignorované soubory]] jsou také verzovány, jsou rovněž (pokud existují) součástí pracovního adresáře.

== Registrace změn ==
Provedením příkazu '''commit''' se stav pracovního adresáře zapíše jako nový [[ChangeSet|changeset]] neboli [[Revision|revize]] do repozitáře.


{{{#!dot
digraph G {
 compound=true;
 rankdir = LR
 background="#999999";
 subgraph cluster_0 {
  label="pracovní adresář";
  style=filled;
  color=lightgrey;
  node [style=filled,color=white];
  edge [style=invis];
  "main.c"-> "main.h" -> ".hgignore" -> ".hgtags"
 }
 subgraph cluster_1 {
  label = "store";
  labelloc = b;
  style=filled;
  color="#eeeeee";
  node [shape=box,style=filled,color=lightgray];
  "rev 0" -> "rev 1" -> "rev 2" -> "rev 3" [dir=back];
  "rev 2" -> "rev 4" [dir=back];
 }
 "rev 2" -> ".hgtags" [dir=back, style=dotted, lhead=cluster_0, label="rodič rev. 3 a 4"]
 "rev 4" -> ".hgtags" [dir=back, color=red, lhead=cluster_0, headlabel="commit", labelfontcolor=red ]
}
}}}

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 tvoří novou '''[[Branch|větev]]''' v historii changesetů.

== Revize, changesety, čela a tip ==
Mercurial sdružuje změny ve vícerých 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".
}}}

Složení a obsah souborů v pracovní kopii se mění v závislosti na aktuálním rodiči této pracovní kopie.

Změnu rodiče zařídí příkaz `hg update` nebo `hg update -r X`, který orientuje pracovní kopii na poslední revizi (tip) aktuální větve nebo na vybranou revizi X.

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á''.

<!> V anglických textech se pro označení popisovaných tří entit (repozitórium, repozitář, pracovní kopie) používají termíny dva - repozitář a pracovní adresář, někdy dokonce termín jeden - repozitář. Pracovní kopie je v programu Mercurial a !TotoiseHg vedena jako pracovní adresář.

<!> Zcela běžně se pro jednu a tutéž komitovanou změnu používají slova ''revize'', ''changeset'' a ''komit''.


== Changeset, commit, merge ==

Mercurial sdružuje změny ve více souborech do jednotlivých atomických (nedělitelných) changesetů. 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".
Line 119: Line 104:
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''' 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).

== Klonování, slučování, akce pull a update ==
Začněme s Alenkou, jejíž repozitář vypadá následovně:
[[CzechBranch|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''' (hrot) repozitáře, čelo s nejvyšším číslem revize. Revize 4 je ''slučovací'', protože má dva rodičovské changesety (revize 2 a 3).

Provedením příkazu '''hg commit''' se stav pracovní kopie zapíše jako nový changeset neboli revize do repozitáře.
Pokud byla rodičem pracovní kopie revize, která měla potomka, vytvoří se nové [[CzechBranch|čelo]].

Alternativně lze v repozitáři vytvořit nový changeset jeho stažením z jiného repozitáře přikazem '''hg pull'''. Tento příkaz stáhne všechny rozdílné changesety ze vzdáleného repozitáře a vloží je do lokálního repozitáře za poslední místní changeset.

Tím dojde k trvalé změně lokálního repozitáře, přičemž mohou vzniknout dvě rozdílné situace:

 a. Přidané revize nekolidují s revizemi stávajícími a hrotem (tipem) upraveného repozitáře se stává nejnovější přenesená revize. Pro synchronizaci repozitória s repozitářem (pracovní kopie je stále napojena na původní místní changeset) postačí příkaz `hg update`.

 a. Přidané revize nějakým způsobem kolidují se stávajícími revizemi a v repozitáři se vytvářejí dvě čela.
  * Je nutné provést příkaz `hg merge`, který buď proběhne bez účasti uživatele, jde-li o změny nekonfliktní, které umí Mercuriál sám vyhodnotit
  * nebo je zapotřebí v rámci příkazu ''hg merge'' provést ruční řešení konfliktů například nástrojem KDiff3.

Sloučením se vytvoří nový changeset, který je nutno předat do repozitáře příkazem `hg commit`.


== Alenka a Bertík ==

Postup při klonování, přenášení changesetů a slučování si ukážeme na ilustrativní ukázce. Pracovní kopii budeme ve shodě se zavedenými zvyklostmi označovat ve schematech jako "pracovní adresář" neboli '''working directory'''. Budeme tedy používat názvy ''repozitórium, repozitář, pracovní adresář''.

Začneme s Alenkou, jejíž repozitář vypadá následovně:
Line 133: Line 137:
Pracovní adresář (working directory) je opět 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 repozitáře ve svém vlastním adresáři:
Bertík si vytvoří klon Alenčina projektu ve svém vlastním počítači (hg clone):
Line 146: Line 148:
Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny '''e''','''f''', které postupně potvr příkazem [[Commit|commit]]: Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny '''e''','''f''', které postupně zaregistruje příkazem hg commit:
Line 159: Line 161:
Alenka si vytvoří svou vlastní paralelní změnu '''g''': Alenka si vytvoří svou vlastní paralelní změnu '''g'''. Odlišné repozitáře v této chvíli představují dvě odlišné [[CzechBranch|větve]] jejich společného projektu.
Line 171: Line 173:
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. Nyní se Bertík synchronizuje s Alenkou pomocí příkazu ''hg 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. V repozitáři jsou dvě čela a Bertík je vyzván aby provedl příkaz '''hg merge'''.
Line 190: Line 192:
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): Po provedení příkazu ''merge'' (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) repozitáře, vznikne v pracovním adresáři potenciální changeset, která má dvě rodičovské revize (f, g):
Line 207: Line 209:
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: Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík ve svém repozitáři příkazem commit ''slučující changeset'' '''h'''. Pracovní kopie alias pracovní adresář se posune za tento changest :
Line 226: Line 228:
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''': 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''':
Line 245: Line 247:
Všimneme 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|update]] aby její pracovní adresář ukazoval na slučující changeset '''h'''.  Všimněme si, že po provedení příkazu ''hg pull'' je Alenčin pracovní adresář stále potomkem revize '''g'''. Alenka musí ještě provést příkaz ''hg update'' aby její pracovní adresář reflektoval slučující changeset '''h'''.
Line 264: Line 266:
Nyní jsou Alenčin a Bertíkův repozitář plně synchronizovány. Nyní jsou Alenčin a Bertíkův repozitáře opět plně synchronizovány.
Line 268: Line 270:
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: Mercurial je zcela decentralizovaný systém bez centrálního repozitáře. Uživatelé si mohou volně definovat své konstelace pro sdílení změn (viz [[CzechCommunicatingChanges|Přenos změn]]), včetně vyčlenění jednoho repozitáře jako centrálního:
Line 290: Line 292:


##Podrobnější text o používání Mercurialu viz [[CzechTutorial|Tutoriál pro Mercurial]].
----
== Viz také ==

 .[[CzechRepository|Repozitář]]
 .[[CzechBranch|Větev neboli branch]]
 .[[CzechBookmarks|Záložky neboli bookmarks]]
 .[[CzechCommunicatingChanges|Přenos změn]]

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.

1. Repozitórium

Repozitórium je pracovní adresář Mercuriálu, který se od běžného pracovního adresáře liší tím, že jeho chování je ovlivňováno programem Mercurial:

  1. Obsahuje složku .hg neboli repozitář a případně další provozní soubory (.hgrc, .hgignore, ...).

  2. Obsahuje soubory a složky, které jsou součástí projektu. Přítomnost všech těchto polož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, pull či push uložen do složky .hg/store/ repozitáře, jsou soubory sledované.

Míra pozornosti, které je soubor v repozitóriu 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´´

Sledované soubory jsou v repozitóriu zastoupeny v závislosti na (vybrané) aktuální revizi. Aktuálně nastavená starší revize jako aktuální může v repozitóriu prezentovat soubor, který jsme později z repozitória odebrali!

Nesledované soubory (včetně ignorovaných) jsou v repozitóriu přítomny trvale - pokud nejsou smazány.

Repozitórium je tedy vnímavý kořenový adresář projektu, který obsahuje složku .hg, zvanou repozitář a další soubory a složky, které tvoří sledovaný i nesledovaný obsah projektu.

2. Repozitář

Repozitář je stručně vzato složka .hg v repozitóriu. Se složkou .hg se nemá manipulovat. Subsložka .hg/store, obsahuje kompletní historii projektu.

3. Pracovní kopie

Uživatelský přístup (možnost prohlížení a editace souborů) k jednotlivým changesetům repozitáře zajišťuje mechanizmus tak zvané "pracovní kopie", která je vždy spojena s určitým (aktuálním) changesetem. Pracovní kopie je editovatelná kopie rodičovského changesetu, jímž nemusí vždy být changeset poslední.

Složení a obsah souborů v pracovní kopii se mění v závislosti na aktuálním rodiči této pracovní kopie.

Změnu rodiče zařídí příkaz hg update nebo hg update -r X, který orientuje pracovní kopii na poslední revizi (tip) aktuální větve nebo na vybranou revizi X.

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

<!> V anglických textech se pro označení popisovaných tří entit (repozitórium, repozitář, pracovní kopie) používají termíny dva - repozitář a pracovní adresář, někdy dokonce termín jeden - repozitář. Pracovní kopie je v programu Mercurial a TotoiseHg vedena jako pracovní adresář.

<!> Zcela běžně se pro jednu a tutéž komitovanou změnu používají slova revize, changeset a komit.

4. Changeset, commit, merge

Mercurial sdružuje změny ve více souborech do jednotlivých atomických (nedělitelných) changesetů. 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 (hrot) repozitáře, čelo s nejvyšším číslem revize. Revize 4 je slučovací, protože má dva rodičovské changesety (revize 2 a 3).

Provedením příkazu hg commit se stav pracovní kopie zapíše jako nový changeset neboli revize do repozitáře. Pokud byla rodičem pracovní kopie revize, která měla potomka, vytvoří se nové čelo.

Alternativně lze v repozitáři vytvořit nový changeset jeho stažením z jiného repozitáře přikazem hg pull. Tento příkaz stáhne všechny rozdílné changesety ze vzdáleného repozitáře a vloží je do lokálního repozitáře za poslední místní changeset.

Tím dojde k trvalé změně lokálního repozitáře, přičemž mohou vzniknout dvě rozdílné situace:

  1. Přidané revize nekolidují s revizemi stávajícími a hrotem (tipem) upraveného repozitáře se stává nejnovější přenesená revize. Pro synchronizaci repozitória s repozitářem (pracovní kopie je stále napojena na původní místní changeset) postačí příkaz hg update.

  2. Přidané revize nějakým způsobem kolidují se stávajícími revizemi a v repozitáři se vytvářejí dvě čela.
    • Je nutné provést příkaz hg merge, který buď proběhne bez účasti uživatele, jde-li o změny nekonfliktní, které umí Mercuriál sám vyhodnotit

    • nebo je zapotřebí v rámci příkazu hg merge provést ruční řešení konfliktů například nástrojem KDiff3.

Sloučením se vytvoří nový changeset, který je nutno předat do repozitáře příkazem hg commit.

5. Alenka a Bertík

Postup při klonování, přenášení changesetů a slučování si ukážeme na ilustrativní ukázce. Pracovní kopii budeme ve shodě se zavedenými zvyklostmi označovat ve schematech jako "pracovní adresář" neboli working directory. Budeme tedy používat názvy repozitórium, repozitář, pracovní adresář.

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

Bertík si vytvoří klon Alenčina projektu ve svém vlastním počítači (hg clone):

Bertík nyní může pracovat nezávisle na Alence. Vytvoří dvě změny e,f, které postupně zaregistruje příkazem hg commit:

Alenka si vytvoří svou vlastní paralelní změnu g. Odlišné repozitáře v této chvíli představují dvě odlišné větve jejich společného projektu.

Nyní se Bertík synchronizuje s Alenkou pomocí příkazu hg 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. V repozitáři jsou dvě čela a Bertík je vyzván aby provedl příkaz hg merge.

Protože nejnovějším čelem v Bertíkově repozitáři je Alenčin changeset g, je nositelem označení tip.

Po provedení příkazu merge (sloučení), který spojí jeho poslední revizi (f) s posledním changesetem (tipem) repozitáře, vznikne v pracovním adresáři potenciální changeset, která má dvě rodičovské revize (f, g):

Po kontrole pracovního adresáře, že sloučení je v pořádku, vytvoří Bertík ve svém repozitáři příkazem commit slučující changeset h. Pracovní kopie alias pracovní adresář se posune za tento changest :

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:

Všimněme si, že po provedení příkazu hg pull je Alenčin pracovní adresář stále potomkem revize g. Alenka musí ještě provést příkaz hg update aby její pracovní adresář reflektoval slučující changeset h.

Nyní jsou Alenčin a Bertíkův repozitáře opět plně synchronizovány.

6. Decentralizovaný systém

Mercurial je zcela decentralizovaný systém bez centrálního repozitáře. Uživatelé si mohou volně definovat své konstelace pro sdílení změn (viz Přenos změn), 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. Viz také

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