Martin Geisler avatar Martin Geisler committed 6a8fb4a

Wordwrap files

Comments (0)

Files changed (3)

 Základy Mercurialu
 ===================
 
-Začneme se základy Mercurialu. Doporučujeme, abyste si sami zkoušeli to, co provádí Alena a Bob. Jejich terminály jsou barevně odlišeny. Alenin je světle okrový, Bobův petrolkově zelený a terminál Karly (přijde na scénu později) je levandulový.
+Začneme se základy Mercurialu. Doporučujeme, abyste si sami zkoušeli
+to, co provádí Alena a Bob. Jejich terminály jsou barevně odlišeny.
+Alenin je světle okrový, Bobův petrolkově zelený a terminál Karly
+(přijde na scénu později) je levandulový.
 
-V anglickém originálu jsou příkazy příkladů psány v linuxovém terminálu (viz Mercurial Kick Start), v českém překladu jsou prezentovány zápisy a výstupy konzoly PowerShell ve Windows.
+V anglickém originálu jsou příkazy příkladů psány v linuxovém
+terminálu (viz Mercurial Kick Start), v českém překladu jsou
+prezentovány zápisy a výstupy konzoly PowerShell ve Windows.
 
 Později uvedeme několik cvičení na stejné téma, které jsme předtím
 prováděli s Alenou a Bobem.
 Mercurial lze použít na mnoha platformách, včetně Windows, Mac OS X a GNU/Linux:
 
 Windows:
-  Stačí nainstalovat program TortoiseHg_, který rovněž obsahuje kompletní instalaci   Mercurialu včetně řady grafických nástrojů pro práci s repozitářem.
+  Stačí nainstalovat program TortoiseHg_, který rovněž obsahuje
+  kompletní instalaci Mercurialu včetně řady grafických nástrojů pro
+  práci s repozitářem.
 
-  Po instalaci získáme pravým poklepem aktivované kontextové menu s přístupem k jednotlivým grafickým nástrojům. Z příkazového řádku terminálu nebo konzoly cmd.exe či Windows PowerShell budeme moci volat přikazy `hg a `hgtk`. Příkaz `hgtk` otevře grafický nástroj TortoiseHg.
-
+  Po instalaci získáme pravým poklepem aktivované kontextové menu s
+  přístupem k jednotlivým grafickým nástrojům. Z příkazového řádku
+  terminálu nebo konzoly cmd.exe či Windows PowerShell budeme moci
+  volat přikazy `hg a `hgtk`. Příkaz `hgtk` otevře grafický nástroj
+  TortoiseHg.
 
 Linux:
-  Instalujte Mercurial_ ze zdroje nebo pomocí správce paketů. Instalace ze zdroje je doporučována, protože je snadná: proveďte ``make local`` a symlink skriptu `hg` k adresáři v ``PATH``.
+  Instalujte Mercurial_ ze zdroje nebo pomocí správce paketů.
+  Instalace ze zdroje je doporučována, protože je snadná: proveďte
+  ``make local`` a symlink skriptu `hg` k adresáři v ``PATH``.
 
-  Pro instalaci TortoiseHg budete potřebovat vazby na PyGTK . Jsou k disposici ve většině distribucí. Potom následujte `these instructions`__. Tak získáte program `hgtk`.
+  Pro instalaci TortoiseHg budete potřebovat vazby na PyGTK . Jsou k
+  disposici ve většině distribucí. Potom následujte `these
+  instructions`__. Tak získáte program `hgtk`.
 
 Mac OS X:
-  Pro Mercurial_ jsou k disposici binární pakety. Vazby na PyGTK se v Mac OS X obtížně instalují, proto místo TortoiseHg doporučujeme použít Murky_.
+  Pro Mercurial_ jsou k disposici binární pakety. Vazby na PyGTK se v
+  Mac OS X obtížně instalují, proto místo TortoiseHg doporučujeme
+  použít Murky_.
 
 .. _TortoiseHg: http://tortoisehg.org/
 .. _Mercurial: http://mercurial.selenic.com/
 .. __: http://bitbucket.org/tortoisehg/stable/wiki/hgtk
 .. _Murky: http://bitbucket.org/snej/murky/
 
-V našich příkladech budeme používat příkazový řádek ale někdy si stav repozitáře prohlédneme v Průzkumníku repozitáře (`hgtk log`) z programu TortoiseHg.
+V našich příkladech budeme používat příkazový řádek ale někdy si stav
+repozitáře prohlédneme v Průzkumníku repozitáře (`hgtk log`) z
+programu TortoiseHg.
 
 Po instalace Mercurialu si zkuste zadat `hg version`:
 
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
-Je žádoucí, aby se ukázalo číslo verze > 1.4, nejlépe 1.6.3, případně ještě vyšší. Svou instalaci si můžete ověřit zadáním:
+Je žádoucí, aby se ukázalo číslo verze > 1.4, nejlépe 1.6.3, případně
+ještě vyšší. Svou instalaci si můžete ověřit zadáním:
 
 .. shelltest::
    :name: alice
     (specify a username in your .hgrc file)
    1 problems detected, please check your install!
 
-Jméno uživatele normálně po instalaci chybí. Zadáme jej vložením do konfiguračního souboru. V Unixových systémech to je ``HOME/.hgrc``, ve Windows je tímto souborem ``%HOME%\Mercurial.ini`` (viz `hg help config` pro všechny lokace nebo použijte `hgtk userconfig`). Vytvořte soubor s tímto obsahem::
+Jméno uživatele normálně po instalaci chybí. Zadáme jej vložením do
+konfiguračního souboru. V Unixových systémech to je ``HOME/.hgrc``, ve
+Windows je tímto souborem ``%HOME%\Mercurial.ini`` (viz `hg help
+config` pro všechny lokace nebo použijte `hgtk userconfig`). Vytvořte
+soubor s tímto obsahem::
 
    [ui]
    username = Firstname Lastname <example@example.net>
 
-kde si za Firstname Lastname dosadíte své jméno. My použijeme nejprve ``Alice <alice@example.net>``. Průběh `hg dubuginstall` by nyní již měl být bezproblémový.
+kde si za Firstname Lastname dosadíte své jméno. My použijeme nejprve
+``Alice <alice@example.net>``. Průběh `hg dubuginstall` by nyní již
+měl být bezproblémový.
 
 
 .. shelltest::
 Základní příkazy
 =================
 
-Nyní si stručně probereme základní příkazy. Jsou všechny podobné příkazům ze starších systémů jako je Subversion nebo CVS. Používáte-li TortoiseHg ve Windows, můžeté také nahlédnout do `quick start guide`_.
+Nyní si stručně probereme základní příkazy. Jsou všechny podobné
+příkazům ze starších systémů jako je Subversion nebo CVS. Používáte-li
+TortoiseHg ve Windows, můžeté také nahlédnout do `quick start guide`_.
 
 .. _quick start guide: http://tortoisehg.bitbucket.org/manual/1.1-cs/quick.html
 
    example
 
 
-Příkaz `hg init` vytvořil nový repozitář. Složku ``example`` jsme
-také mohli vytvořit předem a v ní přikázat pouze `hg init`.
+Příkaz `hg init` vytvořil nový repozitář. Složku ``example`` jsme také
+mohli vytvořit předem a v ní přikázat pouze `hg init`.
 
 Složku ``example`` podrobíme inspekci:
 
    ..
    .hg
 
-Jak můžete vidět, nový repozitář je prázdný až na složku ``.hg``. Sem Mercurial ukládá historii changesetů a několik dalších administrativních souborů.
+Jak můžete vidět, nový repozitář je prázdný až na složku ``.hg``. Sem
+Mercurial ukládá historii changesetů a několik dalších
+administrativních souborů.
 
 
 Vytvoření changesetu
    $ hg status
    ? hello.txt
 
-Odpověď nám říká, že ``hello.txt`` není Mercurialu znám, to jest, není jím sledován. To je stejné jako třeba v Subversion. Soubor můžeme přidat:
+Odpověď nám říká, že ``hello.txt`` není Mercurialu znám, to jest, není
+jím sledován. To je stejné jako třeba v Subversion. Soubor můžeme
+přidat:
 
 .. shelltest::
    :name: alice
    $ hg status
    A hello.txt
 
-Statut souboru se změnil na "A" (od slova přidán, neboli "added"). Soubor zatím není uložen v historii repozitáře - provedeme to příkazem "commit":
+Statut souboru se změnil na "A" (od slova přidán, neboli "added").
+Soubor zatím není uložen v historii repozitáře - provedeme to příkazem
+"commit":
 
 .. shelltest::
    :name: alice
    date:        Wed Mar 10 20:10:05 2010 +0000
    summary:     First version of hello
 
-Právě jsme úspěšně provedli první commit v Mercurialu. Upravme soubor a požádejme Mercurial aby nám ukázal, jak se soubory v pracovní kopii liší od poslední revize:
+Právě jsme úspěšně provedli první commit v Mercurialu. Upravme soubor
+a požádejme Mercurial aby nám ukázal, jak se soubory v pracovní kopii
+liší od poslední revize:
 
 .. shelltest::
    :name: alice
    $ echo "by Alice." >> hello.txt
    $ hg commit -m "Added author." ## -d "2010-03-10 20:15:00 UTC"
 
-Nyní požádáme Mercurial aby provedl anotaci souboru, to jest ukázal, kdy byl který řádek naposledy měněn:
+Nyní požádáme Mercurial aby provedl anotaci souboru, to jest ukázal,
+kdy byl který řádek naposledy měněn:
 
 .. shelltest::
    :name: alice
    1:
    1: by Alice.
 
-Zcela správně, Mercurial nám říká, že první řádek je z revize 0 a že oba následující řádky jsou z revize 1. TortoiseHg nabízí velmi pěkný interaktivní nástroj, viz `hgtk annotate`.
+Zcela správně, Mercurial nám říká, že první řádek je z revize 0 a že
+oba následující řádky jsou z revize 1. TortoiseHg nabízí velmi pěkný
+interaktivní nástroj, viz `hgtk annotate`.
 
-Anotace souborů je neocenitelná pomoc při hledání chyb; při nalezení chyby můžeme příkazem `annotate` zjistit, kdy byla tato chyba zavedena do souboru. Potom pomocí `hg log` získat příslušející komentář komitu, který může vysvětlit, o co se komitent pokoušel když měnil řádek.
+Anotace souborů je neocenitelná pomoc při hledání chyb; při nalezení
+chyby můžeme příkazem `annotate` zjistit, kdy byla tato chyba zavedena
+do souboru. Potom pomocí `hg log` získat příslušející komentář komitu,
+který může vysvětlit, o co se komitent pokoušel když měnil řádek.
 
 
 .. shelltest::
    date:        Wed Mar 10 20:15:00 2010 +0000
    summary:     Added author.
 
-Oba changesety v našem repozitáři tvoří posloupnou řadu. To se nejlépe uvidí
-pomocí standartní extenze `graphlog`__. Povolením dostupných extenzí lze velmi rozšířit
-schopnosti Mercurialu. Alena si extenzi graphlog jednoduše uvolní tak, že do svého konfiguračního souboru přidá zápis::
+Oba changesety v našem repozitáři tvoří posloupnou řadu. To se nejlépe
+uvidí pomocí standartní extenze `graphlog`__. Povolením dostupných
+extenzí lze velmi rozšířit schopnosti Mercurialu. Alena si extenzi
+graphlog jednoduše uvolní tak, že do svého konfiguračního souboru
+přidá zápis::
 
 
   [extensions]
 
 .. __: http://mercurial.selenic.com/wiki/GraphlogExtension
 
-Může potom zadat `hg help graphlog`, aby se o extenzi dozvěděla více. Extenze
-umožňuje Aleně použít další příkaz:
+Může potom zadat `hg help graphlog`, aby se o extenzi dozvěděla více.
+Extenze umožňuje Aleně použít další příkaz:
 
 .. shelltest::
    :name: alice
    :align: center
 
 
-Soubory pracovní kopie jsou vždy synchronizovány s určitým changesetem.
-Aktuální changeset se v `hgtk log`pozná podle většího kolečka ve sloupci s grafem a podle podtrženého textu ve sloupci s komentářem. Ve výstupu v `hg glog` je rodičovská revize pracovní kopie repozitáře označena znakem ``@``.
+Soubory pracovní kopie jsou vždy synchronizovány s určitým
+changesetem. Aktuální changeset se v `hgtk log`pozná podle většího
+kolečka ve sloupci s grafem a podle podtrženého textu ve sloupci s
+komentářem. Ve výstupu v `hg glog` je rodičovská revize pracovní kopie
+repozitáře označena znakem ``@``.
 
 
 
 Putování časem
 ----------------
 
-Pracovní kopii rodičovské revize lze změnit (nastavit aktuální changeset) příkazem
-`hg update`. To se hodí, když chceme přezkoušet starší verzi svého skriptu, například
-když chceme otestovat starší verzi svého softwéru v novém operačním systému.
-Aby si prohlédla svůj starší soubor, postoupí Alena zpět k revizi 0. Nejprve použije
-příkaz `hg parents`, aby zjistila, kde se ve větvi grafu nachází:
+Pracovní kopii rodičovské revize lze změnit (nastavit aktuální
+changeset) příkazem `hg update`. To se hodí, když chceme přezkoušet
+starší verzi svého skriptu, například když chceme otestovat starší
+verzi svého softwéru v novém operačním systému. Aby si prohlédla svůj
+starší soubor, postoupí Alena zpět k revizi 0. Nejprve použije příkaz
+`hg parents`, aby zjistila, kde se ve větvi grafu nachází:
 
 .. shelltest::
    :name: alice
    $ cat hello.txt
    Hello World
 
-ale ta novější verze není zapomenuta. Mercurial ji umí snadno vyzvednout:
+ale ta novější verze není zapomenuta. Mercurial ji umí snadno
+vyzvednout:
 
 .. shelltest::
    :name: alice
 
    by Alice.
 
-Příkaz `hg cat` je užitečný pro prohlížení starších verzí souborů bez použití `hg update`
-pro přenesení celého pracovního adresáře ke starší verzi. Přechod zpátky k poslední (tip)
-revizi je snadný, zadáme pouze `hg update` bez argumentu:
+Příkaz `hg cat` je užitečný pro prohlížení starších verzí souborů bez
+použití `hg update` pro přenesení celého pracovního adresáře ke starší
+verzi. Přechod zpátky k poslední (tip) revizi je snadný, zadáme pouze
+`hg update` bez argumentu:
 
 .. shelltest::
    :name: alice
 
 1. Použijte `hg init` pro vytvoření repozitáře ``kick-start``.
 
-2. Vstupte do ``kick-start`` a vytvořte několik souborů. Zapište je pro přidání příkazem
-   `hg add`. Můžete také vyzkoušet přikaz `hg revert` pro zrušení některého z přidaných
-   souborů.
+2. Vstupte do ``kick-start`` a vytvořte několik souborů. Zapište je
+   pro přidání příkazem `hg add`. Můžete také vyzkoušet přikaz `hg
+   revert` pro zrušení některého z přidaných souborů.
 
-3. Použijte `hg commit` pro registraci souborů. Nezadáte-li komentář komitu, otevře se
-   textový editor pro jeho zadání.
+3. Použijte `hg commit` pro registraci souborů. Nezadáte-li komentář
+   komitu, otevře se textový editor pro jeho zadání.
 
 4. Proveďte několik dalších komitů.
 
-5. Použijte `hg update` pro aktualizaci pracovního adresáře ke starší revizi.
-   Všimněte si výstupu `hg parents` a porovnejte jej s výstupem `hg tip`.
+5. Použijte `hg update` pro aktualizaci pracovního adresáře ke starší
+   revizi. Všimněte si výstupu `hg parents` a porovnejte jej s
+   výstupem `hg tip`.
 
-6. Zkuste provést komit, když uděláte změnu ve starší revizi. Dozvíte se, že
-   vytváříte nové "čelo". Čelo je changeset bez dětí. K zobrazení čel v repozitáři
-   použijte příkaz `hg heads` nebo si prohlédněte graf vyvolaný příkazem `hgtk log`.
+6. Zkuste provést komit, když uděláte změnu ve starší revizi. Dozvíte
+   se, že vytváříte nové "čelo". Čelo je changeset bez dětí. K
+   zobrazení čel v repozitáři použijte příkaz `hg heads` nebo si
+   prohlédněte graf vyvolaný příkazem `hgtk log`.
 
-   Všimněte si, že rodičovská revize pracovní kopie se stává rodičovskou revizí
-   příštího changesetu.
+   Všimněte si, že rodičovská revize pracovní kopie se stává
+   rodičovskou revizí příštího changesetu.
 
-7. Vícero čel představuje více odlišných linií vývoje. Normálně tyto linie sloučíte
-   příkazem `hg merge`. Pokud se změny nepřekrývají, bude sloučení snadné. V opačném
-   případě budete muset vyřešit konflikty - více o tom později.
+7. Vícero čel představuje více odlišných linií vývoje. Normálně tyto
+   linie sloučíte příkazem `hg merge`. Pokud se změny nepřekrývají,
+   bude sloučení snadné. V opačném případě budete muset vyřešit
+   konflikty - více o tom později.
 
-   Všimněte si, jak příkaz `hg parents` po příkazu `hg merge` vytiskne dva changesety.
-   Znamená to, že příští komit bude mít dva rodiče, které posléze uvidíte v `hg glog`
-   nebo v `hgtk log`.
+   Všimněte si, jak příkaz `hg parents` po příkazu `hg merge` vytiskne
+   dva changesety. Znamená to, že příští komit bude mít dva rodiče,
+   které posléze uvidíte v `hg glog` nebo v `hgtk log`.
 
 
 Spolupráce s ostatními
 =======================
 
-Alenin repozitář se v této chvíli nachází v jejím domovském adresáři. Její spolupracovník
-Bob chce na projektu rovněž pracovat. Jeho příkazy budeme uvádět na světlemodrém pozadí.
+Alenin repozitář se v této chvíli nachází v jejím domovském adresáři.
+Její spolupracovník Bob chce na projektu rovněž pracovat. Jeho příkazy
+budeme uvádět na světlemodrém pozadí.
 
 
 Klonování
 ----------
 
-V dalších příkladech bude Alena s Bobem sdílet společný lokální systém souborů.
-Může to docela dobře být systém v podnikové síti. Změny lze také přenášet prostřednictvím
-SSH a HTTP připojení - dokonce je lze posílat jako přílohu emailů nebo přenášet na USB
-nosičích. Přitom se běžně používá komprimovaný binární formát vytvořený příkazem
-`hg bundle`.
-V našem případě použije Bob příkaz `hg clone` s relativní cestou k Alenině repozitáři:
+V dalších příkladech bude Alena s Bobem sdílet společný lokální systém
+souborů. Může to docela dobře být systém v podnikové síti. Změny lze
+také přenášet prostřednictvím SSH a HTTP připojení - dokonce je lze
+posílat jako přílohu emailů nebo přenášet na USB nosičích. Přitom se
+běžně používá komprimovaný binární formát vytvořený příkazem `hg
+bundle`. V našem případě použije Bob příkaz `hg clone` s relativní
+cestou k Alenině repozitáři:
 
 .. shelltest::
    :name: bob
    updating to branch default
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
-Bob má nyní svou vlastní nezávislou kopii Alenina repozitáře. Takových kopií si může
-pořídit libovolné množství. Ve svém klonu si může vytvářet vlastní changesety bez vlivu
-na Aleniny soubory. Provede několik změn:
+Bob má nyní svou vlastní nezávislou kopii Alenina repozitáře. Takových
+kopií si může pořídit libovolné množství. Ve svém klonu si může
+vytvářet vlastní changesety bez vlivu na Aleniny soubory. Provede
+několik změn:
 
 .. shelltest::
    :name: bob
 Porovnávání klonů
 ------------------
 
-Klon ví odkud pochází a Bob se může ptát, zda nejsou v Alenině kopii changesety, které dosud nemá:
-The clone knows where it originates from and Bob can ask if there are
-any changesets in Alice's clone that he does not already have:
+Klon ví odkud pochází a Bob se může ptát, zda nejsou v Alenině kopii
+changesety, které dosud nemá:
 
 .. shelltest::
    :name: bob
 ---------------------
 
 Bob nemá právo zápisu do souborů v Alenině domovském adresáři, takže
-nemůže zapsat své changesety do jejího repozitáře. Může ji ale informovat,
-že provedl změny klonu a požádat ji, aby si changesety od něho stáhla.
-Alena to provede příkazem `hg pull`. Předtím si ale zapíše cestu k Bobově klonu
-do svého souboru ``.hg/hgrc``. To je konfigurační soubor lokálního repozitáře.
-Zapíše::
+nemůže zapsat své changesety do jejího repozitáře. Může ji ale
+informovat, že provedl změny klonu a požádat ji, aby si changesety od
+něho stáhla. Alena to provede příkazem `hg pull`. Předtím si ale
+zapíše cestu k Bobově klonu do svého souboru ``.hg/hgrc``. To je
+konfigurační soubor lokálního repozitáře. Zapíše::
 
   [paths]
   default = /home/bob/example
 
-čímž se stane Bobův klon implicitním cílem při provádění `hg pull` a jiných příkazů
-souvisejících se vzdáleným repozitářem. To, co bude staženo, uvidí příkazem
-`hg incoming`:
+čímž se stane Bobův klon implicitním cílem při provádění `hg pull` a
+jiných příkazů souvisejících se vzdáleným repozitářem. To, co bude
+staženo, uvidí příkazem `hg incoming`:
 
 .. shelltest::
    :name: alice
    date:        Thu Mar 11 10:03:00 2010 +0000
    summary:     Not my file.
 
-Všimněte si symetrie výstupu s výstupem po Bobově `hg outgoing`. Alena se rozhodne,
-že si Bobovy změny stáhne:
+Všimněte si symetrie výstupu s výstupem po Bobově `hg outgoing`. Alena
+se rozhodne, že si Bobovy změny stáhne:
 
 .. shelltest::
    :name: alice
    (run 'hg update' to get a working copy)
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/basic-alice-pull.png
 
-Poslední řádek (proveďte 'hg update' pro vytvoření pracovní kopie) napovídá Aleně, že
-se rodičovská revize její pracovní kopie dosud nezměnila:
+Poslední řádek (proveďte 'hg update' pro vytvoření pracovní kopie)
+napovídá Aleně, že se rodičovská revize její pracovní kopie dosud
+nezměnila:
 
 .. image:: basic-alice-pull.png
    :align: center
 
-Rodičovská revize je nezměněna, protože Alena může právě pracovat na vlastní změně
-a o okamžitou aktualizaci svého repozitáře nemusí mít zájem. V tomto případě ale zájem
-má:
+Rodičovská revize je nezměněna, protože Alena může právě pracovat na
+vlastní změně a o okamžitou aktualizaci svého repozitáře nemusí mít
+zájem. V tomto případě ale zájem má:
 
 
 .. shelltest::
    $ hg update
    2 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
-Je běžné, že téměř vždy po `hg pull` chceme provést `hg update` a pro tuto potřebu
-existuje zkrácení: příkaz `hg pull -u` zařídí automaticky aktualizaci po stažení nových
-změn.
+Je běžné, že téměř vždy po `hg pull` chceme provést `hg update` a pro
+tuto potřebu existuje zkrácení: příkaz `hg pull -u` zařídí automaticky
+aktualizaci po stažení nových změn.
 
 Odlišné linie vývoje
 ----------------------
    adding welcome.txt
    $ hg commit -m 'Welcome file.' ## -d "2010-03-11 11:04:00 UTC"
 
-Jak Alena tak Bob mají nyní changeset, který je dítětem ``51b2976b01e8``, ale nevědí
-o tom, protože žádný z nich změny nikam neposílal ani odnikud nestahoval. Alena se
-rozhodne, že si stáhne od Boba:
+Jak Alena tak Bob mají nyní changeset, který je dítětem
+``51b2976b01e8``, ale nevědí o tom, protože žádný z nich změny nikam
+neposílal ani odnikud nestahoval. Alena se rozhodne, že si stáhne od
+Boba:
 
 .. shelltest::
    :name: alice
    (run 'hg heads' to see heads, 'hg merge' to merge)
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/basic-alice-heads.png
 
-Co se stalo? Jak už bylo zmíněno, "čelní" changeset je changeset bez dětí. Protože
-Alena a Bob provedli *různé* změny, založené na ``51b2976b01e8``, jsou nyní v repozitáři
-dva changesety bez potomků. Tato čela tvoří odlišné linie vývoje, jak můžeme vidět
-v `hgtk log`:
+Co se stalo? Jak už bylo zmíněno, "čelní" changeset je changeset bez
+dětí. Protože Alena a Bob provedli *různé* změny, založené na
+``51b2976b01e8``, jsou nyní v repozitáři dva changesety bez potomků.
+Tato čela tvoří odlišné linie vývoje, jak můžeme vidět v `hgtk log`:
 
 .. image:: basic-alice-heads.png
    :align: center
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)
 
-Konflikty nebyly žádné, protože Alena a Bob editovali různé soubory. Po provedení
-`hg merge` má pracovní kopie *dva* rodiče. Sloučení zatím nebylo komitováno, takže
-ještě můžeme sloučený changeset případně měnit.
-Přesto, že nebyly provedeny konfliktní změny, mohou se vyskytnout sémantické konflikty,
-které Mercurial neumí poznat. Je tedy vhodné po sloučení provést ověření (suit test).
-V našem případě provede Alena komit:
+Konflikty nebyly žádné, protože Alena a Bob editovali různé soubory.
+Po provedení `hg merge` má pracovní kopie *dva* rodiče. Sloučení zatím
+nebylo komitováno, takže ještě můžeme sloučený changeset případně
+měnit. Přesto, že nebyly provedeny konfliktní změny, mohou se
+vyskytnout sémantické konflikty, které Mercurial neumí poznat. Je tedy
+vhodné po sloučení provést ověření (suit test). V našem případě
+provede Alena komit:
 
 .. shelltest::
    :name: alice
 .. image:: basic-alice-merged.png
    :align: center
 
-Slučovací changeset obsahuje změny z obou svých rodičovských revizí. Když si tento
-changeset Bob stáhne, přetáhne si vlastně changesety dva, které ale nemusí slučovat:
+Slučovací changeset obsahuje změny z obou svých rodičovských revizí.
+Když si tento changeset Bob stáhne, přetáhne si vlastně changesety
+dva, které ale nemusí slučovat:
 
 .. shelltest::
    :name: bob
 .. image:: basic-bob-pull.png
    :align: center
 
-Povšimněte si rozdílného umístění stejných changesetů v Alenině a Bobově
-repozitáři. Changesety si vždy uchovávají své ID - delší hexadecimální číslo - ale
-mohou změnit číslo revize, které závisí na pořadí, ve kterém byl changeset přidán
-do repozitáře. Stahují-li si dva lidé změny navzájem, může snadno dojít k tomu, že
-stejný changeset má různá čísla revizí. Při komunikaci mimo vlastní repozitář bychom
-měli vždy pro určení changesetů používat jejich ID, při "komunikaci" uvnitř repozitáře
-lze bezpečně používat čísla revizí.
+Povšimněte si rozdílného umístění stejných changesetů v Alenině a
+Bobově repozitáři. Changesety si vždy uchovávají své ID - delší
+hexadecimální číslo - ale mohou změnit číslo revize, které závisí na
+pořadí, ve kterém byl changeset přidán do repozitáře. Stahují-li si
+dva lidé změny navzájem, může snadno dojít k tomu, že stejný changeset
+má různá čísla revizí. Při komunikaci mimo vlastní repozitář bychom
+měli vždy pro určení changesetů používat jejich ID, při "komunikaci"
+uvnitř repozitáře lze bezpečně používat čísla revizí.
 
 
 Cvičení
 
 1. Vytvořte repozitář a proveďte v něm několik komitů.
 
-2. Vytvořte dva klony svého repozitáře. Všimněte si, jak soubor ``.hg/hgrc`` vyjadřuje
-   umístění původního repozitáře. Příkaz `hg paths` vám ukáže definované cesty.
+2. Vytvořte dva klony svého repozitáře. Všimněte si, jak soubor
+   ``.hg/hgrc`` vyjadřuje umístění původního repozitáře. Příkaz `hg
+   paths` vám ukáže definované cesty.
 
 2. Do ``.hg/hgrc`` přidejte další cestu, například::
 
      bob = /home/bob/test
 
    Nyní budete moci provádět `hg pull bob`, `hg outgoing bob`, apod.
-   Je vhodné si pro lidi, s nimiž často spolupracujeme, vytvořit zkratky.
+   Je vhodné si pro lidi, s nimiž často spolupracujeme, vytvořit
+   zkratky.
 
-3. Experimentujte se stahováním (pull) a posíláním (push) změn. Všimněte si, že se
-   pracovní adresář nezmění pouhým přidáním změn do repozitáře. Rodičovská revize
-   pracovní kopie se změní teprve po aktualizaci - `hg update`.
+3. Experimentujte se stahováním (pull) a posíláním (push) změn.
+   Všimněte si, že se pracovní adresář nezmění pouhým přidáním změn do
+   repozitáře. Rodičovská revize pracovní kopie se změní teprve po
+   aktualizaci - `hg update`.
 
-Mercurial podporuje spolupráci bez přímého propojení. Provádí se výměnou changesetů
-v tak zvaných *svazcích*. Svazek (bundle) je komprimovaná binární prezentace řady
-changesetů.
+Mercurial podporuje spolupráci bez přímého propojení. Provádí se
+výměnou changesetů v tak zvaných *svazcích*. Svazek (bundle) je
+komprimovaná binární prezentace řady changesetů.
 
 1. V jednom ze svých repozitářů vytvořte několik changesetů. Příkazem
-   `hg bundle --base X out.bundle` vytvořte svazek ``out.bundle``, který obsahuje
-   všechny changesety za zvoleným changesetem ``X``.
+   `hg bundle --base X out.bundle` vytvořte svazek ``out.bundle``,
+   který obsahuje všechny changesety za zvoleným changesetem ``X``.
 
-2. Přejděte do cílového repozitáře a příkazem `hg unbundle` importujte changesety
-   ze svazku. V tomto příkladě máte nejspíše oba repozitáře v jednom počítači ale
-   ve skutečnosti mohou oba repozitáře být v rozdílných počítačích, které nejsou
-   nikdy přímo propojeny. V takovém případě můžete poslat svazky třeba emailem.
+2. Přejděte do cílového repozitáře a příkazem `hg unbundle` importujte
+   changesety ze svazku. V tomto příkladě máte nejspíše oba repozitáře
+   v jednom počítači ale ve skutečnosti mohou oba repozitáře být v
+   rozdílných počítačích, které nejsou nikdy přímo propojeny. V
+   takovém případě můžete poslat svazky třeba emailem.
 
 Svůj repozitář můžete publikovat také prostřednictvím HTTP:
 
-1. Proveďte v repozitáři příkaz `hgtk serve`. Otevře se vám možnost přístupu
-   k repozitářům na lokální adrese ``http://localhost:8000``.
+1. Proveďte v repozitáři příkaz `hgtk serve`. Otevře se vám možnost
+   přístupu k repozitářům na lokální adrese ``http://localhost:8000``.
 
-2. Zkuste si stáhnout (pull) changeset z repozitáře, publikovaného pomocí `hg serve`.
+2. Zkuste si stáhnout (pull) changeset z repozitáře, publikovaného
+   pomocí `hg serve`.
 
-Nástroj `hg serve` je vhodný pro jednorázové publikování. Pro soustavné publikování je
-vhodnější např. Apache se skriptem ``hgweb.cgi``, dodávaným spolu s Mercurialem.
+Nástroj `hg serve` je vhodný pro jednorázové publikování. Pro
+soustavné publikování je vhodnější např. Apache se skriptem
+``hgweb.cgi``, dodávaným spolu s Mercurialem.
 
 
 
 Souhrn
 =======
 
-Poznali jsme většinu základních příkazů Mercurialu a viděli jsme, jak se changesety
-ukládají do historie repozitáře. Důležité příkazy jsou tyto:
+Poznali jsme většinu základních příkazů Mercurialu a viděli jsme, jak
+se changesety ukládají do historie repozitáře. Důležité příkazy jsou
+tyto:
 
 * `hg init`: vytvořit nový repozitář
 * `hg add`: přihlásit soubor k přidání
 Spolupráce se Subversion
 =========================
 
-Extenze `hgsuvbersion`__ mění Mercurial na klienta Subversion. To nám umožňuje používat
-offline commit a všechna ostatní pěkná hejblátka Mercurialu a posílat (push)
-changesety zpět do Subversion.
+Extenze `hgsuvbersion`__ mění Mercurial na klienta Subversion. To nám
+umožňuje používat offline commit a všechna ostatní pěkná hejblátka
+Mercurialu a posílat (push) changesety zpět do Subversion.
 
 .. contents::
 
    $ ##echo 'graphlog ='                                    >> $HGRCPATH
    $ ##echo "hgsubversion = $PWD/hgsubversion/hgsubversion" >> $HGRCPATH
 
-Extenze vyžaduje pojítka (bindins) Python-Subversion. Ve Windows jsou součástí aplikace
-TortoiseHg, v Linuxu musíte vyhledat paket ``python-subversion`` nebo podobný.
-Alena povolí extenzi hgsubversion zápisem::
+Extenze vyžaduje pojítka (bindins) Python-Subversion. Ve Windows jsou
+součástí aplikace TortoiseHg, v Linuxu musíte vyhledat paket
+``python-subversion`` nebo podobný. Alena povolí extenzi hgsubversion
+zápisem::
 
    [extensions]
    hgsubversion = path/to/hgsubversion
 
-do svého souboru ``.hgrc``. Zda bylo povolení provedeno si ověříme zadáním
-příkazu `hg help hgsubversion`.
+do svého souboru ``.hgrc``. Zda bylo povolení provedeno si ověříme
+zadáním příkazu `hg help hgsubversion`.
 
 Klonování Subversion
 =====================
 
-Připravili jsme repozitář Subversion s malým programem Hello World pro několik skupin.
-Pro každou skupinu je určen repozitář, označený jako ``hello1``,
-``hello2``, …, ``hello5``:
+Připravili jsme repozitář Subversion s malým programem Hello World pro
+několik skupin. Pro každou skupinu je určen repozitář, označený jako
+``hello1``, ``hello2``, …, ``hello5``:
 
 .. shelltest::
    :name: alice
    $ cd hello-hg
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/hgsubversion-clone.png
 
-Alena zkontroluje repozitář příkazem `hgtk log` aby viděla, že byly tagy řádně
-definovány:
+Alena zkontroluje repozitář příkazem `hgtk log` aby viděla, že byly
+tagy řádně definovány:
 
 .. image:: hgsubversion-clone.png
    :align: center
 
-Závěrečná revize Subversion přiřadí vlastnost ``svn:ignore`` k ``hello`` proto,
-aby byl kompilovaný binární soubor ignorován. V Mercurialu jsou vzory pro ignorování
-spravovány v nadřízeném souboru ``.hgignore``. Tento soubor lze generovat příkazem:
+Závěrečná revize Subversion přiřadí vlastnost ``svn:ignore`` k
+``hello`` proto, aby byl kompilovaný binární soubor ignorován. V
+Mercurialu jsou vzory pro ignorování spravovány v nadřízeném souboru
+``.hgignore``. Tento soubor lze generovat příkazem:
 
 .. shelltest::
    :name: alice
 
    $ hg svn genignore
 
-Normálně bychom soubor ``.hgignore`` komitovali, abychom zajistili jeho sdílení
-s každým, kdo použije repozitář. Protože je ale Subversion této sestavě nadřízena,
-není nutné tento soubor posílat zpátky. Z toho důvodu ignoruje generovaný soubor
-``.hgignore`` sám sebe. Občas jej lze regenerovat příkazem `hg svn genignore --force`.
+Normálně bychom soubor ``.hgignore`` komitovali, abychom zajistili
+jeho sdílení s každým, kdo použije repozitář. Protože je ale
+Subversion této sestavě nadřízena, není nutné tento soubor posílat
+zpátky. Z toho důvodu ignoruje generovaný soubor ``.hgignore`` sám
+sebe. Občas jej lze regenerovat příkazem `hg svn genignore --force`.
 
 Posílání do Subversion
 =======================
    $ hg commit -m 'Added footer.' ##-d "2010-03-12 21:20:15 UTC"
 
 Změna se dosud na server Subversion nedostala, musíme provést normální
-příkaz `push`. Posílání changesetu zahrnuje jeho přepsání. To proto, že
-server Subversion je nadřízený (master) a když v něm provádíme komit, sám
-rozhoduje o jménu uživatele a označení času přináležející k revizi.
-Na straně Mercurialu je changeset přepsán aby reflektoval aktualizovaná metadata:
+příkaz `push`. Posílání changesetu zahrnuje jeho přepsání. To proto,
+že server Subversion je nadřízený (master) a když v něm provádíme
+komit, sám rozhoduje o jménu uživatele a označení času přináležející k
+revizi. Na straně Mercurialu je changeset přepsán aby reflektoval
+aktualizovaná metadata:
 
 .. shelltest::
    :name: alice
    date:        Fri Mar 12 21:25:00 2010 +0000
    summary:     Added footer.
 
-Povšimněte si změny jména uživatele a časového záznamu poté, co Subversion
-tyto údaje aktualizoval. Protože jsou changesety přepisovány, neměly by se provádět
-další klony původního klonu. Pokud tak učiníte, musíte ručně odtrhnout starší verze
-changesetů od changesetů, posílaných do Subversion.
+Povšimněte si změny jména uživatele a časového záznamu poté, co
+Subversion tyto údaje aktualizoval. Protože jsou changesety
+přepisovány, neměly by se provádět další klony původního klonu. Pokud
+tak učiníte, musíte ručně odtrhnout starší verze changesetů od
+changesetů, posílaných do Subversion.
 
 
 Stahování ze Subversion
    :align: center
 
 Když Alena provede push, její oba changesety (``7d780c6154fb`` a
-``12445668eefc``) se automaticky přeskupí k revizi, kterou právě stáhla
-ze Subversion (``2099057558d2``):
+``12445668eefc``) se automaticky přeskupí k revizi, kterou právě
+stáhla ze Subversion (``2099057558d2``):
 
 .. shelltest::
    :name: alice
 ========
 
 Extenze hgsubversion nám umožňuje používat Mercurial jako klienta
-systému Subversion. To nám přináší následující výhody oproti normálnímu
-klientovi Subversion:
+systému Subversion. To nám přináší následující výhody oproti
+normálnímu klientovi Subversion:
 
 * Úplná historie pro klienta. To umožňuje použití technik Mercurialu
-  pro rychlé vyhledávání chyb - ať už to je prosté prohledávání historie
-  pro určitý zadaný řetězec s pomocí `hg grep` či `hg annotate`, nebo
-  náročnější binární prohledávání prováděné s příkazem `hg bisect`.
+  pro rychlé vyhledávání chyb - ať už to je prosté prohledávání
+  historie pro určitý zadaný řetězec s pomocí `hg grep` či `hg
+  annotate`, nebo náročnější binární prohledávání prováděné s příkazem
+  `hg bisect`.
 
 * Lokální (offline) komity. Správa verzí je o sledování vývoje kódu.
-  Měla by umožnit experimentovat s novými nápady a prvky. Tomu napomáhají
-  časté lokální komity - třeba každých pět minut.
+  Měla by umožnit experimentovat s novými nápady a prvky. Tomu
+  napomáhají časté lokální komity - třeba každých pět minut.
 
-  Subversion nutí lidi tyto revize neprodleně publikovat. Ti potom mají tendenci
-  šetřit s komity (zejména do kmene) ze strachu, že naruší stavbu kmene. Pokud
-  pracují na větvi, všechny tyto komity zamoří historii a zatíží přehledy.
+  Subversion nutí lidi tyto revize neprodleně publikovat. Ti potom
+  mají tendenci šetřit s komity (zejména do kmene) ze strachu, že
+  naruší stavbu kmene. Pokud pracují na větvi, všechny tyto komity
+  zamoří historii a zatíží přehledy.
 
   Mercurial umožňuje lidem komitovat tak často, jak často potřebují.
-  Změny je možné později přepracovat na menší počet výmluvnějších komitů
-  a ty lze potom poslat na server Subversion.
+  Změny je možné později přepracovat na menší počet výmluvnějších
+  komitů a ty lze potom poslat na server Subversion.
 
-* Decentralizovaný vývoj. Nahoře jsme viděli, jak se changesety přeskupily,
-  když byly poslány do Subversion. Je obtížné spolupracovat s ostatními, když
-  se nám changesety, na kterých pracujeme, soustavně mění pod rukami.
+* Decentralizovaný vývoj. Nahoře jsme viděli, jak se changesety
+  přeskupily, když byly poslány do Subversion. Je obtížné
+  spolupracovat s ostatními, když se nám changesety, na kterých
+  pracujeme, soustavně mění pod rukami.
 
-  Práci ve skupině je nutné zorganizovat podobně, jak spolupracovala Karla s Alenou
-  a Bobem. Nejprve si všechno vyříkají a povymění mezi sebou a potom hotové dílko
-  může vedoucí skupiny poslat na Subversion. Členové mohou své lokální klony odvrhnout
-  a stáhnout si závaznou verzi ze serveru Subversion.
+  Práci ve skupině je nutné zorganizovat podobně, jak spolupracovala
+  Karla s Alenou a Bobem. Nejprve si všechno vyříkají a povymění mezi
+  sebou a potom hotové dílko může vedoucí skupiny poslat na
+  Subversion. Členové mohou své lokální klony odvrhnout a stáhnout si
+  závaznou verzi ze serveru Subversion.
 
-Extenzi hgsubversion lze také použít ke konverzi k Mercurialu. Ten obsahuje speciální
-extenzi pro konverzi ale je známo, že hgsubversion konvertuje některé repozitáře lépe
-a přesněji.
+Extenzi hgsubversion lze také použít ke konverzi k Mercurialu. Ten
+obsahuje speciální extenzi pro konverzi ale je známo, že hgsubversion
+konvertuje některé repozitáře lépe a přesněji.
 
-Hlavním problémem při konverzi ze Subversion (nebo vlastně z každého staršího systému)
-k Mercurialu je nedostatek pružnosti starého systému. Subversion nemá tagy ani větve,
-pouze (velmi) přísnou konvenci, která říká že kopie z ``trunk/`` do ``branches/foo``
-naznačuje vytvoření větve s názvem "foo". Nic však nebrání kopírovat polovinu ``trunk``
-do ``branches/foo``, nebo provedení komitu, který mění soubory v ``trunk`` a v ``branches/foo`` současně.
+Hlavním problémem při konverzi ze Subversion (nebo vlastně z každého
+staršího systému) k Mercurialu je nedostatek pružnosti starého
+systému. Subversion nemá tagy ani větve, pouze (velmi) přísnou
+konvenci, která říká že kopie z ``trunk/`` do ``branches/foo``
+naznačuje vytvoření větve s názvem "foo". Nic však nebrání kopírovat
+polovinu ``trunk`` do ``branches/foo``, nebo provedení komitu, který
+mění soubory v ``trunk`` a v ``branches/foo`` současně.
 
-Tento druh "škváry" nelze vždy prezentovat rozumným způsobem v Mercurialu, nicméně
-extenze hgsubversion je při interpretaci dobrým pomocníkem.
+Tento druh "škváry" nelze vždy prezentovat rozumným způsobem v
+Mercurialu, nicméně extenze hgsubversion je při interpretaci dobrým
+pomocníkem.
 
 ..  LocalWords:  hgsubversion TortoiseHg hg hgtk svn hgignore
 Práce ve větvích
 =================
 
-V této části poznáme postup práce založený na používání pojmenovaných větví,
-které sledují současný rozvoj několika úloh. Na úlohách bude pracovat naše
-známá dvojice Alena a Bob a jejich práci bude koordinovat zkušenější Karla.
+V této části poznáme postup práce založený na používání pojmenovaných
+větví, které sledují současný rozvoj několika úloh. Na úlohách bude
+pracovat naše známá dvojice Alena a Bob a jejich práci bude
+koordinovat zkušenější Karla.
 
 .. contents::
 
 Přehled
 ========
 
-Pouze Karla bude mít oprávnění zapisovat do hlavního (main) repozitáře. Karla si stahuje
-změny od Aleny a Boba a po přezkoumání je posílá do hlavního repozitáře. Alena s
-Bobem si změny stahují z hlavního repozitáře:
+Pouze Karla bude mít oprávnění zapisovat do hlavního (main)
+repozitáře. Karla si stahuje změny od Aleny a Boba a po přezkoumání je
+posílá do hlavního repozitáře. Alena s Bobem si změny stahují z
+hlavního repozitáře:
 
 .. image:: tasks-flow.png
    :align: center
 
-V reálné situaci budou repozitáře nejspíše umístěny v různých počítačích; v našich
-příkladech si je ale umístíme jeden vedle druhého:
+V reálné situaci budou repozitáře nejspíše umístěny v různých
+počítačích; v našich příkladech si je ale umístíme jeden vedle
+druhého:
 
 .. shelltest::
 
    $ hg update
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
 
-Alena má nyní čerstvý klon hlavního repozitáře. Projekt obsahuje jediný soubor
-``hello.txt``:
+Alena má nyní čerstvý klon hlavního repozitáře. Projekt obsahuje
+jediný soubor ``hello.txt``:
 
 .. shelltest::
    :name: alice
    $ cat hello.txt
    Goodbye, World!
 
-V textu je zřejmá chyba a Karla ji už zanesla do projektového
-bestiáře (bug tracker) jako Issue 1. Požádala Alenu, aby chybu napravila
-změnou textu na ``Hello, World!``.
+V textu je zřejmá chyba a Karla ji už zanesla do projektového bestiáře
+(bug tracker) jako Issue 1. Požádala Alenu, aby chybu napravila změnou
+textu na ``Hello, World!``.
 
 Vytvoření větve
 ----------------
    marked working directory as branch issue-1
    $ hg commit -m 'Starting branch for Issue 1.' ## -d "2010-03-15 10:25:00 UTC"
 
-Příkaz `hg branch` sám o sobě historii pracovní kopie nemění, pouze zajišťuje, že
-následný komit je "orazítkován" poznámkou ``issue-1``. Prázdný komit normálně provést
-nelze, ale změna názvu větve se jako změna počítá; dosavadní název byl ``default``.
-Po provedení komitu má Alenin repozitář dva changesety:
+Příkaz `hg branch` sám o sobě historii pracovní kopie nemění, pouze
+zajišťuje, že následný komit je "orazítkován" poznámkou ``issue-1``.
+Prázdný komit normálně provést nelze, ale změna názvu větve se jako
+změna počítá; dosavadní název byl ``default``. Po provedení komitu má
+Alenin repozitář dva changesety:
 
 .. shelltest::
    :name: alice
 .. image:: tasks-alice-branched.png
    :align: center
 
-Všimněte si názvu větví ve sloupci Summary. Názvy větví se zobrazují jenom pro ty
-changesety, které tvoří *čela větví*. Tyto changesety jsou také ve sloupci pro graf
-označeny světle zeleným kruhem kolem malého kolečka, které je u větve `default`
-vyplněno černě, u větve `issue-1` růžově.
-V Průzkumníku repozitáře, vyvolaném příkazem `hgtk log`, jsme vybrali volbu
-*View > Color by Branch*.
+Všimněte si názvu větví ve sloupci Summary. Názvy větví se zobrazují
+jenom pro ty changesety, které tvoří *čela větví*. Tyto changesety
+jsou také ve sloupci pro graf označeny světle zeleným kruhem kolem
+malého kolečka, které je u větve `default` vyplněno černě, u větve
+`issue-1` růžově. V Průzkumníku repozitáře, vyvolaném příkazem `hgtk
+log`, jsme vybrali volbu *View > Color by Branch*.
 
 
 Následuje vlastní pinožení Aleny:
       summary:     Initial import.
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/tasks-alice-fixed-issue-1.png
 
-Dva nejnovější changesety jsou ve větvi ``issue-1``, kořenový changeset je
-v původní větvi s implicitním označením ``default``. Každý changeset je vždy součástí
-nějaké větve. Na čela větví se lze odkazovat jejich názvy: místo ``97205992f938``
-lze psát ``issue-1`` a místo ``e9eb044d45e0`` můžeme napsat ``default``.
-V jistém smyslu vytvářejí větve vlastní ``plovoucí tagy`` (foating tags),
-které vždy ukazují k nejnovějšímu changesetu větve a jsou v Průzkumníku repozitáře
-označeny světle zeleným kruhem na čáře grafu:
+Dva nejnovější changesety jsou ve větvi ``issue-1``, kořenový
+changeset je v původní větvi s implicitním označením ``default``.
+Každý changeset je vždy součástí nějaké větve. Na čela větví se lze
+odkazovat jejich názvy: místo ``97205992f938`` lze psát ``issue-1`` a
+místo ``e9eb044d45e0`` můžeme napsat ``default``. V jistém smyslu
+vytvářejí větve vlastní ``plovoucí tagy`` (foating tags), které vždy
+ukazují k nejnovějšímu changesetu větve a jsou v Průzkumníku
+repozitáře označeny světle zeleným kruhem na čáře grafu:
 
 .. image:: tasks-alice-fixed-issue-1.png
    :align: center
 
-Alena poznamená do bestiáře, že chybu opravila a že si Karla může změny stáhnout.
+Alena poznamená do bestiáře, že chybu opravila a že si Karla může
+změny stáhnout.
 
 Sloučení větví
 ----------------
 
-Zatímco Alena opravovala chybu, byla Karla také pilná a přidala soubor README:
+Zatímco Alena opravovala chybu, byla Karla také pilná a přidala soubor
+README:
 
 .. shelltest::
    :name: carla
    added 2 changesets with 1 changes to 1 files (+1 heads)
    (run 'hg heads' to see heads, 'hg merge' to merge)
 
-Mercurial jí říká, že má nové čelo v repozitáři. Ty lze zobrazit příkazem `hg heads`:
+Mercurial jí říká, že má nové čelo v repozitáři. Ty lze zobrazit
+příkazem `hg heads`:
 
 .. shelltest::
    :name: carla
    $ hg update issue-1
    1 files updated, 0 files merged, 1 files removed, 0 files unresolved
 
-Její pracovní adresář nyní vypadá jako Alenin a Karla může soubory zkontrolovat.
-Není zcela spokojená s "moderním" pozdravem, který Alena zvolila, dala by přednost
-starému, dobrému, klasickému pozdravu "Hello". Proberou to s Alenou v bestiáři a přesvědčí
-ji, aby pozdrav změnila.
+Její pracovní adresář nyní vypadá jako Alenin a Karla může soubory
+zkontrolovat. Není zcela spokojená s "moderním" pozdravem, který Alena
+zvolila, dala by přednost starému, dobrému, klasickému pozdravu
+"Hello". Proberou to s Alenou v bestiáři a přesvědčí ji, aby pozdrav
+změnila.
 
-Alena se nejprve přesvědčí, že se stále nachází ve větvi ``issue-1`` a potom chybu opraví:
+Alena se nejprve přesvědčí, že se stále nachází ve větvi ``issue-1`` a
+potom chybu opraví:
 
 .. shelltest::
    :name: alice
    added 1 changesets with 1 changes to 1 files
    (run 'hg update' to get a working copy)
 
-Pro přechod k vrchu (tip) své aktuální větve (``issue-1``) může použít buď `hg update` nebo explicitně `hg update issue-1`:
+Pro přechod k vrchu (tip) své aktuální větve (``issue-1``) může použít
+buď `hg update` nebo explicitně `hg update issue-1`:
 
 .. shelltest::
    :name: carla
    $ hg branches
    default                        1:550bad1893cf
 
-Kdyby Karla větev neuzavřela, stal by se seznam `hg-branches` zbytečně objemný. Dále
-provede aktualizaci k větvi ``default`` a sloučení s ``issue-1``:
+Kdyby Karla větev neuzavřela, stal by se seznam `hg-branches` zbytečně
+objemný. Dále provede aktualizaci k větvi ``default`` a sloučení s
+``issue-1``:
 
 .. shelltest::
    :name: carla
    (branch merge, don't forget to commit)
    $ hg commit -m 'Merged fix for Issue 1.' ## -d "2010-03-15 13:25:00 UTC"
 
-Tím, že nejprve provede aktualizaci k ``default`` Karla zajistí, že se slučovací
-changeset vytvoří v ``default`` nikoliv v ``issue-1``, kam nepatří. Povšimněte si,
-že se sloučení větví neliší od sloučení jakýchkoli dvou changesetů.
+Tím, že nejprve provede aktualizaci k ``default`` Karla zajistí, že se
+slučovací changeset vytvoří v ``default`` nikoliv v ``issue-1``, kam
+nepatří. Povšimněte si, že se sloučení větví neliší od sloučení
+jakýchkoli dvou changesetů.
 
 
 Strkání větve
 ----------------
 
-Nyní to Karla všechno vystrčí (push) do hlavního repozitáře. Musí použít praporek (flag)
-`--new-branch`, protože vystrkuje novou pojmenovanou  větev. To proto, aby nevystrčila
-pojmenovanou větev náhodou předčasně. Bez praporku se jí dostane přátelského upozornění:
+Nyní to Karla všechno vystrčí (push) do hlavního repozitáře. Musí
+použít praporek (flag) `--new-branch`, protože vystrkuje novou
+pojmenovanou větev. To proto, aby nevystrčila pojmenovanou větev
+náhodou předčasně. Bez praporku se jí dostane přátelského upozornění:
 
 .. shelltest::
    :name: carla
 
 .. note::
 
-   Praporek `--new-branch` byl zaveden v Mercurialu 1.6. Ve starších verzích
-   bylo požadováno použití `--force`. To je nebezpečné proto, že jsou zapovězeny
-   všechny kontroly, zatímmco `--new-branch` vystrkování dvou čel nedovolí.
+   Praporek `--new-branch` byl zaveden v Mercurialu 1.6. Ve starších
+   verzích bylo požadováno použití `--force`. To je nebezpečné proto,
+   že jsou zapovězeny všechny kontroly, zatímmco `--new-branch`
+   vystrkování dvou čel nedovolí.
 
 
 .. shelltest::
 Dlouhodobější větve
 ====================
 
-Zatímco Alena pracovala na ošetření Issue 1, Karla požádala Boba aby zajistil
-překlad souboru ``hello.txt`` do dánštiny, němčiny a francouzštiny. Pro toto téma
-vytvořili Issue 2. Stejně jako Alena, bude Bob pracovat ve své vlastní větvi a začne
-stažením změn z hlavního repozitáře:
+Zatímco Alena pracovala na ošetření Issue 1, Karla požádala Boba aby
+zajistil překlad souboru ``hello.txt`` do dánštiny, němčiny a
+francouzštiny. Pro toto téma vytvořili Issue 2. Stejně jako Alena,
+bude Bob pracovat ve své vlastní větvi a začne stažením změn z
+hlavního repozitáře:
 
 .. shelltest::
    :name: bob
       date:        Mon Mar 01 10:20:30 2010 +0000
       summary:     Initial import.
 
-V této chvíli nebyla ještě Alenina větev připojena do hlavního repozitáře,
-takže Bob vidí jenom první dva changesety, vytvořené Karlou. Bob vytvoří větev
-a přejmenuje ``hello.txt`` tak, aby reflektoval příslušný jazyk:
+V této chvíli nebyla ještě Alenina větev připojena do hlavního
+repozitáře, takže Bob vidí jenom první dva changesety, vytvořené
+Karlou. Bob vytvoří větev a přejmenuje ``hello.txt`` tak, aby
+reflektoval příslušný jazyk:
 
 .. shelltest::
    :name: bob
      ## -d "2010-03-09 11:45:00 UTC"
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/tasks-bob-first-commits.png
 
-Na překlad do francouzštiny potřebuje více času, proto tuto změnu odloží. Grafický
-průběh změn vidíme dole a všimněte si, že jeho větev ``issue-2`` je označená červeně:
+Na překlad do francouzštiny potřebuje více času, proto tuto změnu
+odloží. Grafický průběh změn vidíme dole a všimněte si, že jeho větev
+``issue-2`` je označená červeně:
 
 .. image:: tasks-bob-first-commits.png
    :align: center
 .. image:: tasks-carla-merge-issue-1.png
    :align: center
 
-Tato náprava je také potřebná pro Bobovu větev, proto si ji stáhne z hlavního repozitáře:
+Tato náprava je také potřebná pro Bobovu větev, proto si ji stáhne z
+hlavního repozitáře:
 
 .. shelltest::
    :name: bob
 .. image:: tasks-bob-pull-main.png
    :align: center
 
-Nyní včlení ``default`` do ``issue-2`` aby přenesl nápravu do své větve:
+Nyní včlení ``default`` do ``issue-2`` aby přenesl nápravu do své
+větve:
 
 .. shelltest::
    :name: bob
      ## -d "2010-03-09 12:35:00 UTC"
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/tasks-bob-merge-bugfix.png
 
-Všimněte si jak hladce byla Alenina změna ``hello.txt`` přenesena do přejmenovaného
-``hello.en.txt``. Stejně jako dobré ozvučení filmu se dobré sloučení vyznačuje tím, že
-si jej nevšimnete. Později provedeme `srovnání`__ s provedením operace v Subversion.
-Výsledné zobrazení změn vypadá takto:
+Všimněte si jak hladce byla Alenina změna ``hello.txt`` přenesena do
+přejmenovaného ``hello.en.txt``. Stejně jako dobré ozvučení filmu se
+dobré sloučení vyznačuje tím, že si jej nevšimnete. Později provedeme
+`srovnání`__ s provedením operace v Subversion. Výsledné zobrazení
+změn vypadá takto:
 
 .. image:: tasks-bob-merge-bugfix.png
    :align: center
 
-S použitím barevných větví hned vidíme, že se růžová větev ``issue-1`` sloučila
-s černou větví ``default`` a to celé s červenou větví ``issue-2``. Barvy nám velmi
-pomáhají při prohlížení složitých historií.
+S použitím barevných větví hned vidíme, že se růžová větev ``issue-1``
+sloučila s černou větví ``default`` a to celé s červenou větví
+``issue-2``. Barvy nám velmi pomáhají při prohlížení složitých
+historií.
 
-Bob konečně přišel na to, jak přeložit text do francouzštiny, takže provádí
-finální komit před tím než požádá Karlu o kontrolu větve.
+Bob konečně přišel na to, jak přeložit text do francouzštiny, takže
+provádí finální komit před tím než požádá Karlu o kontrolu větve.
 
 .. shelltest::
    :name: bob
 
 .. __: `Sloučení přejmenovaných souborů v Subversion`_
 
-Spokojen se svým dílem, předává aktivitu Karle, která si změnu stáhne do svého
-repozitáře:
+Spokojen se svým dílem, předává aktivitu Karle, která si změnu stáhne
+do svého repozitáře:
 
 .. shelltest::
    :name: carla
 .. image:: tasks-carla-pull-issue-2.png
    :align: center
 
-Po náležité kontrole Bobových souborů se Karla rozhodne, že jeho práci začlení.
-Provede aktualizaci k jeho větvi aby ji uzavřela a zpět k ``default`` aby
-provedla vlastní sloučení:
+Po náležité kontrole Bobových souborů se Karla rozhodne, že jeho práci
+začlení. Provede aktualizaci k jeho větvi aby ji uzavřela a zpět k
+``default`` aby provedla vlastní sloučení:
 
 .. shelltest::
    :name: carla
    $ hg commit -m 'Merged fix for Issue 2.' ## -d "2010-03-16 10:15:00 UTC"
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/tasks-carla-merge-issue-2.png
 
-Závěrečné zobrazení changesetů krásně ukazuje, jak byla větev ``default`` (černá)
-sloučena s větví ``issue-2`` (červená) předtím, než byla větev ``issue-2 opět sloučena
-s větví ``default``:
+Závěrečné zobrazení changesetů krásně ukazuje, jak byla větev
+``default`` (černá) sloučena s větví ``issue-2`` (červená) předtím,
+než byla větev ``issue-2 opět sloučena s větví ``default``:
 
 .. image:: tasks-carla-merge-issue-2.png
    :align: center
 
-Toto je velmi typická konfigurace grafu pro dlouhodobější větve: větev ``default`` se
-opakovaně slučuje s experimentálnější větví aby přebrala nejnovější nápravy a změny.
-Udržování větví v synchronizovaném stavu napomáhá snadnějšímu slučování. Při každém
-sloučení nalezne Mercurial nejbližšího společného předka a aplikuje mezilehlé změny.
-Při pravidelném slučování není tento předek příliš zasunut v minulosti a větve se od
-sebe příliš neliší.
+Toto je velmi typická konfigurace grafu pro dlouhodobější větve: větev
+``default`` se opakovaně slučuje s experimentálnější větví aby
+přebrala nejnovější nápravy a změny. Udržování větví v
+synchronizovaném stavu napomáhá snadnějšímu slučování. Při každém
+sloučení nalezne Mercurial nejbližšího společného předka a aplikuje
+mezilehlé změny. Při pravidelném slučování není tento předek příliš
+zasunut v minulosti a větve se od sebe příliš neliší.
 
 Sloučení přejmenovaných souborů v Subversion
 ----------------------------------------------
 
 Při slučování dvou větví je důležité najít jejich společného předka.
-Jsou to změny provedené *po* changesetu předka, které mají být sloučeny
-do cílové větve. Mercurial provádí toto sledování předků automaticky - je
-to integrální součást modelu naší historie, který si kdykoliv zobrazíme příkazem
-`hgtk log`.
+Jsou to změny provedené *po* changesetu předka, které mají být
+sloučeny do cílové větve. Mercurial provádí toto sledování předků
+automaticky - je to integrální součást modelu naší historie, který si
+kdykoliv zobrazíme příkazem `hgtk log`.
 
-Historie v Subversion není založena na grafu jako v Mercurialu a po dlouhou dobu
-neměl Subversion žádný nástroj pro sledování sloučení. To znamenalo, že jste musel
-ručně vypátrat rozsahy revizí, které jste chtěl sloučit zadáním `svn merge`.
-Subversion 1.5 a pozdější již umí sledovat sloučení ale tato podpora je neúplná.
-V publikaci Version Control with Subversion (the "SVN Book") je sledování sloučení
+Historie v Subversion není založena na grafu jako v Mercurialu a po
+dlouhou dobu neměl Subversion žádný nástroj pro sledování sloučení. To
+znamenalo, že jste musel ručně vypátrat rozsahy revizí, které jste
+chtěl sloučit zadáním `svn merge`. Subversion 1.5 a pozdější již umí
+sledovat sloučení ale tato podpora je neúplná. V publikaci Version
+Control with Subversion (the "SVN Book") je sledování sloučení
 označeno jako `mimořádně složité`__. Zejména nedostatečně je ošetřeno
 `slučování přejmenovaných souborů`__.
 
 .. __: http://svnbook.red-bean.com/en/1.5/svn-book.html
               #svn.branchmerge.advanced.moves
 
-Nahoře jsme sloučili větev ``issue-2`` s ``default``. Ve větvi ``default`` byl změněn soubor``hello.txt`` a ve větvi ``issue-2`` byl ``hello.txt`` přejmenován na
-``hello.en.txt``. Mercurial provedl správnou věc a při sloučení aplikoval změnu na
-``hello.en.txt``. Subversion se v takové situaci vykupuje zprávou o konfliktu:
+Nahoře jsme sloučili větev ``issue-2`` s ``default``. Ve větvi
+``default`` byl změněn soubor``hello.txt`` a ve větvi ``issue-2`` byl
+``hello.txt`` přejmenován na ``hello.en.txt``. Mercurial provedl
+správnou věc a při sloučení aplikoval změnu na ``hello.en.txt``.
+Subversion se v takové situaci vykupuje zprávou o konfliktu:
 
 .. shelltest::
 
    Summary of conflicts:
      Tree conflicts: 1
 
-Všimněte si také, že v Subversin je nutné použít speciální praporek (flag), když
-se větev slučuje zpátky do hlavního kmenu (trunk). Žádný takový flag v Mercurialu
-nepotřebujeme, protože na větvi ``default`` není nic vnitřně speciálního (komě toho,
-že to je větev implicitní = default).
+Všimněte si také, že v Subversin je nutné použít speciální praporek
+(flag), když se větev slučuje zpátky do hlavního kmenu (trunk). Žádný
+takový flag v Mercurialu nepotřebujeme, protože na větvi ``default``
+není nic vnitřně speciálního (komě toho, že to je větev implicitní =
+default).
 
 Přenášení změn
 ----------------
 
-Jsou-li pojmenované větve v používání delší dobu, stane se, že je potřeba
-provést changesety ve více než jedné větvi. Nahoře mohl Bob jednoduše stáhnout všechny
-změny z hlavního repozitáře ale to často není žádoucí, protože se smísí požadovaná
-změna s jinými změnami.
+Jsou-li pojmenované větve v používání delší dobu, stane se, že je
+potřeba provést changesety ve více než jedné větvi. Nahoře mohl Bob
+jednoduše stáhnout všechny změny z hlavního repozitáře ale to často
+není žádoucí, protože se smísí požadovaná změna s jinými změnami.
 
-Typickým příkladem je náprava komitovaná do větve ``default``, i když by měla být
-správně komitovaná do větve s posledním stabilním vydáním. Vezměme si repozitář s tímto
-grafem:
+Typickým příkladem je náprava komitovaná do větve ``default``, i když
+by měla být správně komitovaná do větve s posledním stabilním vydáním.
+Vezměme si repozitář s tímto grafem:
 
 .. shelltest::
    :name: carla
 .. image:: tasks-carla-transplant-before.png
    :align: center
 
-Zde jsou použity dvě větve: ``default`` (černá) s postupujícím vývojem a ``stable``
-(růžová) pro nápravy a vydání. Vidíme jak se ``stable`` slučuje po nápravě s ``default``
-aby se náprava přenesla do postupujícího vývoje. Když je připraveno vydání, provede
-se sloučení v jinéme směru - od ``default`` ke ``stable`` a je přidán tag. Výsledkem
-jsou dvě paralelní stopy vývoje, kde růžová větev ``stable`` vždy obsahuje podmnožinu
-změn v černé větvi ``default``.
+Zde jsou použity dvě větve: ``default`` (černá) s postupujícím vývojem
+a ``stable`` (růžová) pro nápravy a vydání. Vidíme jak se ``stable``
+slučuje po nápravě s ``default`` aby se náprava přenesla do
+postupujícího vývoje. Když je připraveno vydání, provede se sloučení v
+jinéme směru - od ``default`` ke ``stable`` a je přidán tag. Výsledkem
+jsou dvě paralelní stopy vývoje, kde růžová větev ``stable`` vždy
+obsahuje podmnožinu změn v černé větvi ``default``.
 
-Závěrečný komit napravuje starou chybu a o chvilku později si Karla uvědomuje,
-že tato chyba je také přítomná ve starším vydání 2.0. Changeset by tedy vlastně měl být
-proveden ve větvi ``stable``. Jednoduše připojit ``default`` k ``stable`` už nejde, protože by se sloučila také experimentální změna.
+Závěrečný komit napravuje starou chybu a o chvilku později si Karla
+uvědomuje, že tato chyba je také přítomná ve starším vydání 2.0.
+Changeset by tedy vlastně měl být proveden ve větvi ``stable``.
+Jednoduše připojit ``default`` k ``stable`` už nejde, protože by se
+sloučila také experimentální změna.
 
-Řešením je použití takzvané `transplant extenze`__, která je součástí Mercurialu. Karla
-ji povolí vložením::
+Řešením je použití takzvané `transplant extenze`__, která je součástí
+Mercurialu. Karla ji povolí vložením::
 
   [extensions]
   transplant =
 .. image:: tasks-carla-transplant-after.png
    :align: center
 
-Kopírování se provede exportem originálního changesetu coby oprávky (patch)
-a následným komitem. Protože má duplikátní changeset odlišnou cestu od originálu,
-dostane nové hešové (hash) číslo. Při přenosu se mohou vyskytnout konfliktní situace,
-které je nutné řešit ručně.
+Kopírování se provede exportem originálního changesetu coby oprávky
+(patch) a následným komitem. Protože má duplikátní changeset odlišnou
+cestu od originálu, dostane nové hešové (hash) číslo. Při přenosu se
+mohou vyskytnout konfliktní situace, které je nutné řešit ručně.
 
-Pokud měla Karla štěstí, může nyní opět sloučit větev ``stable`` s větví ``default``:
+Pokud měla Karla štěstí, může nyní opět sloučit větev ``stable`` s
+větví ``default``:
 
 .. shelltest::
    :name: carla
    $ hg commit -m 'Merge with stable.' ## -d "2010-03-18 11:25:00 UTC"
    $ ## $SRCDIR/snap-hgtk-log $SRCDIR/tasks-carla-transplant-merged.png
 
-Všimněte si, že se changesety při této technice ve skutečnosti nepřesunují.
-V decentralizovaném prostředí je téměř nemožné zničit historii. Implicitně nám
-Mercurial povoluje k historii pouze přidávat. To znamená, že náprava chyb zahrnuje
-vytváření nových changesetů, které chyby napravují. V našem připadě jsme chybu
-napravili zdvojením changesetu. Při sloučení se tyto duplikáty automaticky srovnají.
+Všimněte si, že se changesety při této technice ve skutečnosti
+nepřesunují. V decentralizovaném prostředí je téměř nemožné zničit
+historii. Implicitně nám Mercurial povoluje k historii pouze přidávat.
+To znamená, že náprava chyb zahrnuje vytváření nových changesetů,
+které chyby napravují. V našem připadě jsme chybu napravili zdvojením
+changesetu. Při sloučení se tyto duplikáty automaticky srovnají.
 
 
 .. image:: tasks-carla-transplant-merged.png
 Cvičení
 =========
 
-Následující cvičení je vymyšleno pro alespoň jednu skupinu pěti osob, z nichž jedna má roli Karly,
-to jest - koordinuje spolupráci ostatních čtyř. Role Karly bude označena písmenem K.
+Následující cvičení je vymyšleno pro alespoň jednu skupinu pěti osob,
+z nichž jedna má roli Karly, to jest - koordinuje spolupráci ostatních
+čtyř. Role Karly bude označena písmenem K.
 
 
 Proveďte tyto kroky:
 
      http://mercurial.aragost.com/repos/cantons/
 
-   Když je klon proveden, spustí K vestavěný webový server v Mercurialu pomocí
-   `hg serve`.
+   Když je klon proveden, spustí K vestavěný webový server v
+   Mercurialu pomocí `hg serve`.
 
-2. Ostatní členové skupiny si převezmou klony od K. V této chvíli si budete potřebovat
-   vyměnit IP adresy. Můžete také povolit `extenzi zeroconf`__ a po chvilce zadat
-   `hg paths`. Měl by se vám vrátit seznam účastnických repozitářů.
+2. Ostatní členové skupiny si převezmou klony od K. V této chvíli si
+   budete potřebovat vyměnit IP adresy. Můžete také povolit `extenzi
+   zeroconf`__ a po chvilce zadat `hg paths`. Měl by se vám vrátit
+   seznam účastnických repozitářů.
 
    .. __: http://mercurial.selenic.com/wiki/ZeroconfExtension
 
-   Ve Windows je nutné si uvědomit, že příkaz `hg serve` zpřístupní repozitář
-   implicitně na portu 8000, takže se Mercurial pokusí pojmenovat klon nějak jako
-   ``172.16.0.8000``, což je pro Windows neplatný název. Měli byste tedy
-   název adresáře zadat explicitně jako druhý argument k příkazu `hg clone`.
+   Ve Windows je nutné si uvědomit, že příkaz `hg serve` zpřístupní
+   repozitář implicitně na portu 8000, takže se Mercurial pokusí
+   pojmenovat klon nějak jako ``172.16.0.8000``, což je pro Windows
+   neplatný název. Měli byste tedy název adresáře zadat explicitně
+   jako druhý argument k příkazu `hg clone`.
 
 
-3. Ve vytvořeném klonu naleznete soubor ``cantons.txt``. Obsahuje seznam zkratek
-   švýcarských kantonů. Tyto zkratky se mají doplnit - například zkratka::
+3. Ve vytvořeném klonu naleznete soubor ``cantons.txt``. Obsahuje
+   seznam zkratek švýcarských kantonů. Tyto zkratky se mají doplnit -
+   například zkratka::
 
      * FR
 
 
    K přidělí každému členu skupiny rozsah písmen.
 
-4. Pro svůj rozsah si vytvořte větev, např. `hg branch` range-a-g. Potom postupně
-   doplňujte zkratky. Doplnění pro každé písmeno komitujte zvlášť.
+4. Pro svůj rozsah si vytvořte větev, např. `hg branch` range-a-g.
+   Potom postupně doplňujte zkratky. Doplnění pro každé písmeno
+   komitujte zvlášť.
 
-5. Zatímco se lidé baví doplňováním zkratek, doplní K další kapitolu do souboru; asi
-   takto::
+5. Zatímco se lidé baví doplňováním zkratek, doplní K další kapitolu
+   do souboru; asi takto::
 
      Podle jazyků
      =============
 
      Románsky se mluví v: GR.
 
-   Doplí chybějící kantony pro francouzštinu, němčinu, italštinu a komituje
-   změnu. Počká, až ostatní dokončí doplňování svých zkratek.
+   Doplí chybějící kantony pro francouzštinu, němčinu, italštinu a
+   komituje změnu. Počká, až ostatní dokončí doplňování svých zkratek.
 
-6. Když někdo svojí práci dokončí, měl by použít `hg serve` a dát K vědět,
-   že je hotov.
+6. Když někdo svojí práci dokončí, měl by použít `hg serve` a dát K
+   vědět, že je hotov.
 
-7. K si nyní postupně stáhne dílo od všech členů skupiny a sloučí jejich změny
-   do ``default``. Pokud všichni dávali pozor a editovali pouze své rozsahy, neměly
-   by vzniknout žádné konflikty.
+7. K si nyní postupně stáhne dílo od všech členů skupiny a sloučí
+   jejich změny do ``default``. Pokud všichni dávali pozor a editovali
+   pouze své rozsahy, neměly by vzniknout žádné konflikty.
 
-8. Když si s doplňováním nebudete vědět rady, vzpomeňte si, že tu je Wikipedia
-   `aby vám pomohla`__ ``:-)``
+8. Když si s doplňováním nebudete vědět rady, vzpomeňte si, že tu je
+   Wikipedia `aby vám pomohla`__ ``:-)``
 
    .. __: http://en.wikipedia.org/wiki/Cantons_of_Switzerland
 
 Dále budeme experimentovat s řešením konfliktů:
 
 1. Nechť dva členové skupiny editují tentýž řádek - jeden může přidat
-   řádek s názvem francouzského kantonu, druhý s názvem italského kantonu.
+   řádek s názvem francouzského kantonu, druhý s názvem italského
+   kantonu.
 
-2. Konflikt se zjistí, když K stáhne změny a zadá `hg merge`. V závislosti
-   na aktuální konfiguraci Mercurialu se spustí slučovací procedura. Implicitním
-   nástrojem v Linuxu a ve Windows je KDiff3. Po otevření vypadá asi takto:
+2. Konflikt se zjistí, když K stáhne změny a zadá `hg merge`. V
+   závislosti na aktuální konfiguraci Mercurialu se spustí slučovací
+   procedura. Implicitním nástrojem v Linuxu a ve Windows je KDiff3.
+   Po otevření vypadá asi takto:
 
    .. image:: cantons-merge-before.png
 
-   Spodní panel obsahuje výsledky slučování; na obrázku vidíme deklaraci tří konfliktů.
-   Pravým poklepem na <Merge Conflict> vyberete konflikt a řešíte jej přidáním řádků
-   ze složky B (vaše lokální verze) nebo C (jiná verze). My budeme chtít přidat obě
+   Spodní panel obsahuje výsledky slučování; na obrázku vidíme
+   deklaraci tří konfliktů. Pravým poklepem na <Merge Conflict>
+   vyberete konflikt a řešíte jej přidáním řádků ze složky B (vaše
+   lokální verze) nebo C (jiná verze). My budeme chtít přidat obě
    změny:
 
    .. image:: cantons-merge-after.png
 
-   Uložte výsledek a zavřete KDiff3. Mercurial zaznamená, že byl slučovací nástroj
-   ukončen úspěšně a označí soubory jako vyřešené. Ověříme si to příkazem
-   `hg resolve --list`.
+   Uložte výsledek a zavřete KDiff3. Mercurial zaznamená, že byl
+   slučovací nástroj ukončen úspěšně a označí soubory jako vyřešené.
+   Ověříme si to příkazem `hg resolve --list`.
 
-   Není-li Mercurial nakofigurován aby spustil slučovací proceduru, potom musíte
-   editovat soubor sami, aby se odstranily značky, vložené Mercurialem. Po provedení
-   úprav zadejte `hg resolve --mark cantons.txt` aby se soubor označil jako vyřešený.
+   Není-li Mercurial nakofigurován aby spustil slučovací proceduru,
+   potom musíte editovat soubor sami, aby se odstranily značky,
+   vložené Mercurialem. Po provedení úprav zadejte `hg resolve --mark
+   cantons.txt` aby se soubor označil jako vyřešený.
 
 3. Celé slučování ukončíte komitem.
 
 Shrnutí
 ========
 
-Ukázali jsme si jak lze použít pojmenovaných větví ke členění repozitáře Mercurialu.
-Větvení umožňuje pracovat samostatně ve více větvích současně.
+Ukázali jsme si jak lze použít pojmenovaných větví ke členění
+repozitáře Mercurialu. Větvení umožňuje pracovat samostatně ve více
+větvích současně.
 
 ..  LocalWords:  hg bugfix hgtk svn bugfixes zeroconf
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.