Vytvoření větve

Alenka si pro svou práci vytváří novou větev:

alice$ hg branch issue-1
marked working directory as branch issue-1
(branches are permanent and global, did you want a bookmark?)
alice$ hg commit -m "Starting branch for Issue 1." 

Příkaz hg branch sám o sobě nemění historii nebo pracovní kopii, pouze zajišťuje, že následný komit je “orazítkován” poznámkou issue-1.

Předchozí sdělení chtělo varovat, že název větve nelze později smazat (uvidíme ale, že lze nepotřebnou větev skrýt). Jak bylo uvedeno v úvodu, pojmenované větve jsou persistentní a jejich používání se doporučuje jen v případech, kdy chceme trvale sledovat, kde byl který changeset vytvořen. V našem projektu používá skupina podnikový bug tracker a větve pojmenovává podle tematu, na kterém pracují — tím způsobem je snadné vyhledat později všechny komity, které se k dané chybě vztahují.

Prázdný komit normálně provést nelze, ale změna názvu větve se jako změna počítá, takže Alenka mohla komit provést. Repozitář má jenom dva changesety:

Všimněte si názvu větví ve sloupci /”Popis/” ve Verpánku. Tyto názvy se zobrazují jenom u těch changesetů, které tvoří čela větví. Changeset ve větvi default je zobrazen se světle modrým kolečkem a changeset ve větvi issue-1 je zobrazden se zeleným kolečkem.

Počne pinožit (hacking):

alice$ echo "Hey, World!" > hello.txt
alice$ hg diff
diff -r eb6db6528ec2 hello.txt
--- a/hello.txt Mon Mar 15 10:25:00 2010 +0000
+++ b/hello.txt Mon Mar 15 10:28:00 2010 +0000
@@ -1,1 +1,1 @@
-Goodbye, World!
+Hey, World!
alice$ hg commit -m "Fixed Issue 1." 

Svět nyní vypadá takto:

alice$ hg glog
@  changeset:   2:2cdcbb0a5bfd
|  branch:      issue-1
|  tag:         tip
|  user:        Alice <alice@example.net>
|  date:        Mon Mar 15 10:30:00 2010 +0000
|  summary:     Fixed Issue 1.
|
o  changeset:   1:eb6db6528ec2
|  branch:      issue-1
|  user:        Alice <alice@example.net>
|  date:        Mon Mar 15 10:25:00 2010 +0000
|  summary:     Starting branch for Issue 1.
|
o  changeset:   0:e9eb044d45e0
   user:        Carla <carla@example.net>
   date:        Mon Mar 01 10:20:30 2010 +0000
   summary:     Initial import.

Dva nejnovější changesety jsou ve větvi issue-1, kořenový changeset je ve větvi default, kterýžto název není z úsporných důvodů zobrazován. Všechny changesety v Mercurialu jsou v nějaké větvi, jejich název se však nezobrazí, pokud jím je default. 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 tomto smyslu působí větve jako “plovoucí tagy”, které vždy ukazují k nejnovějšímu changesetu větve. Tyto čelní changesety jsou v thg-log zvýrazněny světlezeleným kolečkem:

Alenka poznamená do bestiáře, že chybu opravila a že si Karla může změny stáhnout.

Připojení větve

Zatímco Alena opravovala chybu, byla Karla také pilná a přidala soubor README:

carla$ hg glog
@  changeset:   1:550bad1893cf
|  tag:         tip
|  user:        Carla <carla@example.net>
|  date:        Tue Mar 02 14:30:00 2010 +0000
|  summary:     Added README.
|
o  changeset:   0:e9eb044d45e0
   user:        Carla <carla@example.net>
   date:        Mon Mar 01 10:20:30 2010 +0000
   summary:     Initial import.

Stáhne si změny od Aleny:

carla$ hg pull ../alice
pulling from ../alice
searching for changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads)

Mercurial jí říká, že má nové čelo v repozitáři. To lze zobrazit příkazem hg heads:

carla$ hg heads
changeset:   3:2cdcbb0a5bfd
branch:      issue-1
tag:         tip
user:        Alice <alice@example.net>
date:        Mon Mar 15 10:30:00 2010 +0000
summary:     Fixed Issue 1.

changeset:   1:550bad1893cf
user:        Carla <carla@example.net>
date:        Tue Mar 02 14:30:00 2010 +0000
summary:     Added README.

V repozitáři jsou nyní dvě větve:

carla$ hg branches
issue-1                        3:2cdcbb0a5bfd
default                        1:550bad1893cf

Připojení nové větve k větvi default si Karla prohlédne v thg log:

Obě větve jsou přehledně zobrazeny a Karla provede aktualizaci k větvi issue-1:

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 soubor zkontrolovat. Není zcela spokojená s “moderním” pozdravem, který Alenka zvolila, dala by přednost starému, dobrému, klasickému pozdravu “Hello”. Probere to s Alenou v bestiáři a přesvědčí ji, aby pozdrav změnila. Alenka si nejprv zkontroluje, že je stále ve větvi issue-1 a sporný tvar opraví:

alice$ hg branch
issue-1
alice$ echo "Hello, World!" > hello.txt
alice$ hg commit -m "Really fix Issue 1." 

Karla si novou změmu stáhne:

carla$ hg pull ../alice
pulling from ../alice
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)

Pro přechod k vrcholu (tip) své aktuální větve (issue-1) může použít buď hg update nebo explicitně hg update issue-1:

carla$ hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

S úpravou chyby je spokojená.

Zavření větve

Větve již déle není zapotřebí, proto ji Karla označí jako uzavřenou:

carla$ hg commit --close-branch -m "Close branch, Issue 1 is fixed." 

Tím se stane, že větev issue-1 zmizí ze seznamu hg branches:

carla$ hg branches
default                        1:550bad1893cf

Kdyby Karla větev neuzavřela, stal by se seznam hg-branches zbytečně objemný. Dále provede Karla aktualizaci k větvi default a sloučení s issue-1:

carla$ hg update default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
carla$ hg merge issue-1
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
carla$ hg commit -m "Merged fix for Issue 1." 

Tím, že nejprve provede aktualizaci k default Karla zajistí, že se sloučený 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ů.

Posílání větve

Nyní to všechno pošle (push) do hlavního repozitáře. Musí použít opci --new-branch, protože posílá novou pojmenovanou větev. Bez praporku se jí dostane přátelského upozornění:

carla$ hg push ../main
pushing to ../main
searching for changes
abort: push creates new remote branches: issue-1!
(use 'hg push --new-branch' to create new remote branches)

Zajisté, připojení praporku učiní “push” průchodným:

carla$ hg push --new-branch ../main
pushing to ../main
searching for changes
adding changesets
adding manifests
adding file changes
added 6 changesets with 3 changes to 2 files

Hlavní repozitář je nyní v tomto stavu:

Včlenění default do větve

Mezitím včlenila Karla Aleninu nápravu (bugfix) do větve default:

Tato náprava je také potřebná pro Bobovu větev, proto si ji stáhne z hlavního repozitáře:

bob$ hg pull ../main
pulling from ../main
searching for changes
adding changesets
adding manifests
adding file changes
added 5 changesets with 2 changes to 1 files (+1 heads)
(run 'hg heads' to see heads)

Nyní včlení default do issue-2 aby přenesl nápravu do své větve:

bob$ hg merge default
merging hello.en.txt and hello.txt to hello.en.txt
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
bob$ hg commit -m "Merge in bugfix from default." 

Všimněte si jak hladce se Alenina změna hello.txt včlenila do přejmenovaného souboru hello.en.txt. Stejně jako dobré ozvučení filmu se dobré sloučení vyznačuje tím, že si ho nevšimnete. Porovnáme to s řešením v Subversion – viz dále. Výsledný přehled changestů vypadá takto:

S použitím barevných větví hned vidíme, že se zelená větev issue-1 přičlenila k modroé větvi default a to celé se sloučilo 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$ echo "Bonjour tout le monde !" > hello.fr.txt
bob$ hg add hello.fr.txt
bob$ hg commit -m "French translation." 

Spokojen se svým dílem, postupuje je Karle, která si změnu stáhne do svého repozitáře:

carla$ hg pull ../bob
pulling from ../bob
searching for changes
adding changesets
adding manifests
adding file changes
added 5 changesets with 5 changes to 4 files
(run 'hg update' to get a working copy)

Její repozitář nyní vypadá takto:

Po náležité kontrole Bobových souborů se Karla rozhodne, že jeho práci začlení. Aktualizuje se k jeho větvi aby ji uzavřela a vrátí se k default aby provedla vlastní sloučení:

carla$ hg update issue-2
4 files updated, 0 files merged, 1 files removed, 0 files unresolved
carla$ hg commit --close-branch -m "Close branch, Issue 2 is fixed." 
carla$ hg update default
1 files updated, 0 files merged, 4 files removed, 0 files unresolved
carla$ hg merge issue-2
4 files updated, 0 files merged, 1 files removed, 0 files unresolved
(branch merge, don't forget to commit)
carla$ hg commit -m "Merged fix for Issue 2." 

Závěrečné zobrazení changesetů krásně ukazuje, jak byla větev default (modrá) 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:

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 vytvoření tohoto předka, které mají být sloučeny do cílové větve. Mercurial provádí sledování předků automaticky; je to integrální součást modelu historie, který si kdykoliv můžeme prohlédnout ve Verpánku ( thg 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í označeno jako mimořádně složité. Zejména nedostatečně je ošetřeno slučování přejmenovaných souborů.

Nahoře jsme sloučili větev issue-2 s větví 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:

$ svn merge --reintegrate file://$HOME/hello/branches/issue-2
--- Merging differences between repository URLs into '.':
A    hello.en.txt
   C hello.txt
Summary of conflicts:
  Tree conflicts: 1

Pamatujte si, že v Subversion 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).

Roubování změn

Někdy se stane se, některé changesety potřebujeme 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 opravenka (bugfix) komitovaná do větve default, i když by měla být vlastně komitovaná do větve s posledním stabilním vydáním (release). Vezměme si repozitář s tímto grafem:

Zde jsou použity dvě větve: default (modrá) pro probíhající vývoj a stable (zelená) pro opravenky (bugfixes) a vydání (releases). Vidíme jak je stable sloučena s default aby se opravenka přenesla do aktuálního vývoje. Když je připraveno vydání (release), provede se sloučenív jiném směru — od default ke stable a je přidán tag. Výsledkem jsou dvě paralelní stopy vývoje, kde zelená větev stable vždy obsahuje podmnožinu změn v modré 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.

Řešením je použití příkazu hg graft pro kopírování changesetu. Setrvávaje ve větvi stable, Alenka provede:

carla$ hg graft tip
grafting revision 12

[extensions]
transplant =

To překopíruje changeset do její větve:

Protože duplikát má odlišnou minulost od originálu, dostane nový hash changesetu. Kopírování se uskuteční provedením interního trojného sloučení, které Karla provede svým oblíbeným slučovacím programem. Většinu malých opravenek (bugfixes) lze ovšem roubovat čistě. Karla nyní může sloučit větev stable zpět do default:

carla$ hg update default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
carla$ hg merge stable
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
carla$ hg commit -m "Merge with stable." 

Všimněte si, že se changesety při této technice ve skutečnosti nepřesunují. V necentralizované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í.