Commits

Martin Geisler committed bc76adf

Deleted trailing whitespace

  • Participants
  • Parent commits eb5d92a

Comments (0)

Files changed (3)

 
 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.
 Windows:
   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``.
- 
+
   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_.
-  
+
 .. _TortoiseHg: http://tortoisehg.org/
 .. _Mercurial: http://mercurial.selenic.com/
 .. __: http://bitbucket.org/tortoisehg/stable/wiki/hgtk
    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:
- 
+
 .. shelltest::
    :name: alice
 
    $ hg init example
    $ ls
    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`. 
+také mohli vytvořit předem a v ní přikázat pouze `hg init`.
 
 Složku ``example`` podrobíme inspekci:
 
    :name: alice
 
    $ hg annotate hello.txt
-   0: Hello World 
-   1:             
-   1: by Alice.   
+   0: Hello World
+   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`.
 
 
 
 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 ``@``. 
+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 ``@``.
 
 
 
 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 
+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::
 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 
+   `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í. 
+   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. 
+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`.
 
-   Všimněte si, že rodičovská revize pracovní kopie se stává rodičovskou revizí 
+   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.
 
-   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` 
+   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
 =======================
 
 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 
+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`. 
+`hg bundle`.
 V našem případě použije Bob příkaz `hg clone` s relativní cestou k Alenině repozitáři:
 
 .. shelltest::
 Přenášení changesetů
 ---------------------
 
-Bob nemá právo zápisu do souborů v Alenině domovském adresáři, takže 
+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:: 
+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 
+souvisejících se vzdáleným repozitářem. To, co bude staženo, uvidí příkazem
 `hg incoming`:
 
 .. shelltest::
    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, 
+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::
 
 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á: 
+má:
 
 
 .. shelltest::
    adding manifests
    adding file changes
    added 1 changesets with 1 changes to 1 files (+1 heads)
-   (run 'hg heads' to see heads, 'hg merge' to merge) 
+   (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
 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: 
+V našem případě provede Alena komit:
 
 .. shelltest::
    :name: alice
 
 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 
+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í.
 
    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.
-   
+
 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 
+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 
+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``. 
+   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 
+   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``.
 
-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.
    hgsubversion = path/to/hgsubversion
 
 do svého souboru ``.hgrc``. Zda bylo povolení provedeno si ověříme zadáním
-příkazu `hg help hgsubversion`. 
+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``: 
+``hello2``, …, ``hello5``:
 
 .. shelltest::
    :name: alice
    +/* The End. */
    $ 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í 
+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. 
+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::
   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.
   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.
 
 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, 
+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
 ========
 
 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 
+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
    $ 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 
+Alena má nyní čerstvý klon hlavního repozitáře. Projekt obsahuje jediný soubor
 ``hello.txt``:
 
 .. shelltest::
    :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 
+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
       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 
+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`` 
+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), 
+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:
 
 
 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í: 
+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 
+   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::
    :name: carla
    $ ## $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 
+``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:
 
 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. 
+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ší.
 
 ----------------------------------------------
 
 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 
+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`. 
+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 
+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
 .. __: 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 
+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:
 
 
 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ě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 
+správně komitovaná do větve s posledním stabilním vydáním. Vezměme si repozitář s tímto
 grafem:
 
 .. shelltest::
 .. 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`` 
+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 
+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``.
 .. 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, 
+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ě. 
+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``:
 
 
 Proveďte tyto kroky:
 
-1. K začíná klonováním repozitáře z:: 
+1. K začíná klonováním repozitáře z::
 
      http://mercurial.aragost.com/repos/cantons/
 
    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ářů.
 
    .. __: http://mercurial.selenic.com/wiki/ZeroconfExtension
 
-   Ve Windows je nutné si uvědomit, že příkaz `hg serve` zpřístupní repozitář 
+   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::
 
      * FR: Fribourg
 
    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ášť.
 
      =============
 
      Oficiálními jazyky Švýcarska jsou francouzština, němčina, italština a románština:
-     
+
 
      Francouzština
      ---------------
 
    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.
 
 
 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 
+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.
 
 2. Konflikt se zjistí, když K stáhne změny a zadá `hg merge`. V závislosti
    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 
+   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í 
+   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.
 
 
 ========
 
 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ě. 
+Větvení umožňuje pracovat samostatně ve více větvích současně.
 
 ..  LocalWords:  hg bugfix hgtk svn bugfixes zeroconf