Differences between revisions 16 and 19 (spanning 3 versions)
Revision 16 as of 2010-04-27 19:29:45
Size: 24618
Editor: Tovim
Comment:
Revision 19 as of 2010-04-28 15:21:32
Size: 23112
Editor: Tovim
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Průběhová schemata v Mercurialu =

V Mercurialu lze realizovat mnoho různých průběhových schemat. V tomto textu se s některými seznámíme, přičemž budeme postupovat od jednodušších ke složitějším. Účelem této pomůcky je usnadnit začátečníkům práci se sledováním verzí (verzování). Použité pojmy nejsou vysvětlovány, neboť existuje řada jiných výtečných textů ([[Základy Mercurialu]] a [[http://hgbook.red-bean.com/read/behind-the-scenes.html|Za kulisami]]), které tak činí.
= Průběhy práce v Mercurialu =

V Mercurialu lze realizovat mnoho různých vývojových schemat. V tomto textu se s některými seznámíme, přičemž budeme postupovat od jednodušších ke složitějším. Účelem této pomůcky je usnadnit začátečníkům práci se sledováním verzí (verzování). Použité pojmy nejsou vždy vysvětlovány, neboť existuje řada jiných výtečných textů ([[Základy Mercurialu]] a [[http://hgbook.red-bean.com/read/behind-the-scenes.html|Za kulisami]]), které tak činí.
Line 9: Line 9:
= Základní průběhová schemata = = Základní průběhy =
Line 25: Line 25:
Nyní vytvoříme adresář, ve kterém budeme pracovat (včetně složky .hg): Nyní vytvoříme adresář, ve kterém budeme pracovat (včetně složky `.hg`):
Line 37: Line 37:
<!> Můžeme také vstoupit do existujícího adresáře se soubory a tam vytvořit složku (repozitář) .hg: <!> Můžeme také vstoupit do existujícího adresáře se soubory a tam vytvořit složku (repozitář) `.hg`:
Line 48: Line 48:
Přidané soubory se staly "kandidáty pro registraci". Vlastní zápis změn do repozitáře provádíme jejich předáním příkazem 'commit': Přidané soubory se staly "kandidáty pro registraci". Vlastní zápis změn do repozitáře provádíme jejich předáním příkazem ''commit'':
Line 69: Line 69:
Při přemístění a kopírování souborů pomocí příkazů Mercurialu nemusíme změny "uvádět na kandidátskou listinu" příkazy `hg add`, `hg remove` nebo `hg addremove`.
Nezapomeneme však předat změny repozitáři, to jest provést příkaz '''commit''':
Při přemístění a kopírování souborů pomocí příkazů Mercurialu (cp, mv) nemusíme tyto změny "uvádět na kandidátskou listinu" pomocí příkazů `hg add`, `hg remove` nebo `hg addremove`.
Nezapomeneme však předat změny repozitáři, to jest provést příkaz ''commit'':
Line 86: Line 86:
Pokud nás zajímá jenom určitá revize, použijeme přepínač ''-r'' (--revision). Aby se nám také zobrazil diff určené revize, přidáme přepínač ''-p'' (--patch): Pokud nás zajímá jenom určitá revize, použijeme přepínač ''-r (--revision)''. Aby se nám také zobrazil diff určené revize, přidáme přepínač ''-p (--patch)'':
Line 117: Line 117:
Tím, že jsme v našem adresáři vytvořili systémový adresář (repozitář) `.hg`, učinili jsme z našeho pracovního adresáře 'vnímavý útvar', jehož skladba a obsah souborů se mění v závislosti na nastavené aktuální revizi.

Implicitně je touto revizí revize poslední, nazývaná 'tip'. K libovolné jiné revizi se dostaneme příkazem 'hg update REV', přičemž 'REV' je pořadové číslo revize.
Poslední revizi zas můžeme aktualizovat (zkráceně) příkazem 'hg up tip'

Která revize je právě aktuální, se dozvíme příkazem 'hg identify -n', kde si přepínačem 'n' říkáme o pořadové číslo revize.
Tím, že jsme v našem adresáři vytvořili systémový adresář (repozitář) `.hg`, učinili jsme z našeho pracovního adresáře "vnímavý útvar", jehož skladba a obsah jeho souborů se mění v závislosti na nastavené aktuální revizi.

Implicitně je touto revizí revize poslední, nazývaná ''tip''. K libovolné jiné revizi se dostaneme příkazem ''hg update REV'', přičemž ''REV'' je pořadové číslo revize.
Poslední revizi zas můžeme aktualizovat (zkráceně) příkazem ''hg up tip''

Která revize je právě aktuální, se dozvíme příkazem ''hg identify -n'', kde si přepínačem ''n'' říkáme o pořadové číslo revize.
Line 140: Line 140:
Oprava chyby je 'zaknihována', ještě sloučíme čela: Oprava chyby je "zaknihována", ještě sloučíme čela:
Line 162: Line 162:
Jakmile vyřešíme všechny konflikty, provedeme 'commit'! Ten ostatně provedeme i když se žádné konflikty nevyskytly. Jakmile vyřešíme všechny konflikty, provedeme ''commit''! Ten ostatně provedeme i když se žádné konflikty nevyskytly.
Line 169: Line 169:
<!> Když opravíme chybu souboru ve starší revizi a v nějaké pozdější revizi byl tento soubor kopírován nebo přemístěn, bude sloučením tato oprava rozšířena do cílových souborů. To je hlavní důvod, proč bychom kopírování a přemísťování souborů uvnitř pracovního adresáře měli provádět pomocí příkazů Mercurialu ''hg cp'' a ''hg mv''. <!> Když opravíme chybu souboru ve starší revizi a v nějaké pozdější revizi byl tento soubor kopírován nebo přemístěn, bude tato oprava sloučením rozšířena do cílových souborů. To je hlavní důvod, proč bychom kopírování a přemísťování souborů uvnitř pracovního adresáře měli provádět pomocí příkazů Mercurialu ''hg cp'' a ''hg mv''.
Line 181: Line 181:
__ Práce s klony__ __ Práce s klonem__
Line 228: Line 228:
<!> Podobně pracuje pro nekomitovanou změnu příkaz ''hg revert''
Line 236: Line 238:
=== Průběh ===

__
Použití lokálního serveru__


=== Použití lokálního serveru ===
Line 255: Line 257:
Z bezpečnostních důvodů je možné přes tento server provádět pouze 'pull', nikoliv 'push'.

__Posílání změn e-mailem__
Z bezpečnostních důvodů je možné přes tento server provádět pouze ''pull'', nikoliv ''push''.

=== Posílání změn e-mailem ===
Line 290: Line 292:
<!> Velmi efektní způsob přenosu změn v souboru je pomocí tak zvaného 'svazku (bundle)' viz:
{{{
$ hg help bundle          # poněkud složitější
}}}



__Použití společného repozitáře__
<!> Velmi efektní způsob přenosu změn v souboru je pomocí tak zvaného ''svazku (bundle)'' - viz ''hg help bundle''.


=== Použití společného repozitáře ===
Line 303: Line 302:
Znamená to, že chceme-li poslat své změny do centrálního repozitáře, provedeme nejprve akci 'pull' a ve svém repozitáři vyřešíme případné konflikty a provedeme sloučení.
Takto synchronizovanou změnu potom příkazem 'push' můžeme vyslat do centrálního repozitáře.
Znamená to, že chceme-li poslat své změny do centrálního repozitáře, provedeme nejprve akci ''pull'' a ve svém repozitáři vyřešíme případné konflikty a provedeme sloučení.
Takto synchronizovanou změnu potom příkazem ''push'' můžeme vyslat do centrálního repozitáře.
Line 320: Line 319:
jsme žádání o zadání uživatelského jména a hesla pro BitBucket. jsme žádání o zadání uživatelského jména a hesla pro ''bitbucket''.
Line 324: Line 323:
 $ hg clone https://bitbucket.org/ArneBab/hello/ hello  $ hg clone https://bitbucket.org/ozon/foo/ hello
Line 329: Line 328:
<!> Variantně lze dohodnout, že každý člen kolektivu má na BitBucket otevřený svůj repozitář, do kterého posílá své změny. Určený administrátor potom tyto změny podle svého uvážení stahuje do ''centrálního'' repozitáře, z něhož si ostatní aktuální změny stahují.


<!> You can also use this workflow with a shared server instead of BitBucket, either via SSH or via a shared directory. An example for an SSH URL with Mercurial is be ssh://user@example.com/path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive. </div>
<!> Variantně lze dohodnout, že každý člen kolektivu má na ''bitbucket'' otevřený svůj repozitář, do kterého posílá své změny. Určený administrátor potom tyto změny podle svého uvážení stahuje do ''centrálního'' repozitáře, z něhož si ostatní aktuální změny stahují.


<!> You can also use this workflow with a shared server instead of bitbucket, either via SSH or via a shared directory. An example for an SSH URL with Mercurial is be ssh://user@example.com/path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive.
Line 336: Line 335:
Jak bylo již řečeno na začátku, tento text nevysvětluje podrobnosti, což je někdy právě to, čeho je nám třeba. Můžeme-li trochu anglicky, je dobré zkusit nápovědu k jednotlivým příkazům Jak bylo již řečeno na začátku, tento text nevysvětluje podrobnosti, což je někdy právě to, co potřebujeme. Můžeme-li trochu anglicky, je dobré zkusit nápovědu k jednotlivým příkazům
Line 408: Line 407:
=== stáhnout změny z repozitáře s aktivním serverem (hg serve) === === stáhnout změny přes integrovaný server ===
Line 415: Line 414:
=== použití společného repo na BitBucket === === použití společného repozitáře na BitBucket ===
Line 433: Line 432:
Pro řešení tohoto problému nabízí Mercurial příkaz ''backout''. Tento příkaz vytváří nový changeset, který je dítětem anulovaného changesetu a který ruší špatný changeset. Záznam špatného changesetu v historii nezrušíme, ale můžeme jej odebrat z nových revizí.

<!> Základní příkazy historii nepřepisují. Máme-li takovou potřebu, musíme aktivovat některou extenzi, která je součástí instalace Mercurialu. K tomuto tématu se dostaneme později.
Pro řešení tohoto problému nabízí Mercurial příkaz ''backout''. Tento příkaz vytváří nový changeset, který je dítětem anulovaného changesetu. Záznam špatného changesetu v historii nezrušíme, ale můžeme jej odebrat z nových revizí.

<!> Základní příkazy Mercurialu historii nepřepisují. Máme-li takovou potřebu, musíme aktivovat některou extenzi, která je součástí instalace. K tomuto tématu se vrátíme později.
Line 455: Line 454:
The first part is an easy way to develop features together, without requiring every developer to keep track of several feature clones.

=== Popis případu ===

Chceme-li rozdělit náš projekt do několika variant, potřebujeme vědět, kdo na čem pracuje a kde se jeho práce ukládá.

Mercurial to umožňuje svými "pojmenovanými větvemi". Ty jsou součástí hlavního repozitáře, takže jsou přístupné každému účastníkovi. Zároveň se změny komitované v jisté větvi nemísí se změnami v hlavní (default) větvi, takže jsou variace ukládány odděleně, dokud nejsou s hlavní větví sloučeny.
=== Popis případu ===

Chceme-li rozdělit náš projekt do několika variant, potřebujeme vědět, na čem kdo pracuje a kde se jeho práce ukládá.

Mercurial to umožňuje svými "pojmenovanými větvemi". Ty jsou součástí hlavního repozitáře, takže jsou přístupné každému účastníkovi. Zároveň se změny komitované v pojmenované větvi nemísí se změnami v hlavní (default) větvi.
Line 484: Line 481:
 $ hg update ferari # nás vrátí k poslední revizi úseku 'ferari'  $ hg update ferari # nás vrátí k poslední revizi větve 'ferari'
Line 498: Line 495:
<!> Ukončená pojmenovaná větev je natrvalo zapsaná do historie. Pokud ji tam mít nechcete, lze to řešit způsobem, popsaným v [http://www.selenic.com/mercurial/wiki/Workflows workflows]. <!> Ukončená pojmenovaná větev je natrvalo zapsaná do historie. Pokud ji tam mít nechcete, lze to řešit způsobem, popsaným ve [[http://www.selenic.com/mercurial/wiki/Workflows|Workflows]].
Line 512: Line 509:
Řekněme, že cheme revizi 3 dát jméno otto Řekněme, že cheme revizi 3 dát jméno ''otto''
Line 516: Line 513:
 $ hg tag -r 3 v0.1  $ hg tag -r otto
Line 534: Line 531:
Někdy máme v repozitáři takové změny, které vůbec nepotřebujeme a

There are many advanced options for removing these, and most of them use great extensions ([http://www.selenic.com/mercurial/wiki/MqExtension Mercurial Queues] is the most often used one), but in this basic guide, we'll solve the problem with just the commands we already learned. But we'll use an option to clone which we didn't yet use.

This workflow becomes inconvenient when you need to remove changes, which are buried below many new changes. If you spot the bad changes early enough, you can get rid of them without too much effort, though.

=== Workflow ===

Let's assume you want to get rid of revision 2 and the highest revision is 3.

The first step is to use the "--rev" option to ''clone''<nowiki>: Create a clone which only contains the changes up to the specified revision. Since you want to keep revision 1, you only clone up to that</nowiki>

 $ hg clone -r 1 project stripped
Někdy máme v repozitáři změny, které nepotřebujeme a chtěli bychom je odstranit.

Tento problém lze řešit více způsoby s použitím extenze ([[http://www.selenic.com/mercurial/wiki/MqExtension| Mercurial Queues]]). My si ukážeme řešení prostřednictvím příkazů, které jsme spolu poznali.
 But we'll use an option to clone which we didn't yet use.

Tento pracovní postup není ale vhodný, pokud potřebujeme odstranit velmi zasuté změny.

=== Průběh ===

Řekněme, že se chceme zbavit předposlední revize 2.

Vytvoříme klonovaný repozitář s revizemi 0 až 1. Revizi 3 exportujeme jako oprávku do klonovaného repozitáře, kterou tam posléze importujeme:
{{{
 $ hg clone -r 1 baba bubu
Line 548: Line 546:

Now you can ''export'' the change 3 from the original repository (project) and ''import'' it into the stripped one

 $ cd project
 $ hg export 3 &gt; ../changes.diff
 $ cd ../stripped
 $ hg import ../changes.diff
 $ cd baba
 $ hg export 3 > ../bubu/rev3.diff
Line 556: Line 549:

If a part of the changes couldn't be applied, you'll see that part in *.rej files. If you have *.rej files, you'll have to include or discard changes by hand

 $ cat *.rej
 (apply changes by hand)
 $ hg commit
 (write commit message)
 

That's it. ''hg export'' also includes the commit message, date, committer and similar metadata, so you are already done.

<div class="note">

Note:

 removing history will change the revision IDs of revisions after the removed one, and if you pull from someone else who still has the revision you removed, you will pull the removed parts again. That's why rewriting history should most times only be done for changes which you didn't yet publicise. </div>

== Summary ==

So now you can work with Mercurial in private, and also share your changes in a multitude of ways.

Additionally you can remove bad changes, either by creating a change in the repository which reverses the original change, or by really rewriting history, so it looks like the change never occurred.

And you can separate the work on features in a single repository by using named branches and add tags to revisions which are visible markers for others and can be used to update to the tagged revisions.

With this we can conclude our practical guide.

= More Complex Workflows =

If you now want to check some more complex workflows, please have a look at the general [http://selenic.com/mercurial/wiki/Workflows workflows wikipage].

To deepen your understanding, you should also check the [http://mercurial.selenic.com/wiki/UnderstandingMercurial basic concept overview].

Have fun with Mercurial!

*PS: This guide is licensed under the [http://gnu.org/licenses/gpl-2.0.html GPLv2]*

*PPS: Written by Arne Babenhauserheide, edited by David Soria Parra, Nicolas Dumazet and Steve Losh. Conversion from HTML http://labs.seapine.com/htmltowiki.cgi*
 $ cd ../bubu
 $ hg import rev3.diff
 $ hg add # adding rev3.diff
 $ hg ci -m "Adieu"
}}}

V repozitáři ''bubu'' došlo k přečíslování; máme revize 0 až 4. Původní revize 2 je pryč, komentář poslední revize je "Adieu". Repozitář ''baba'' zůstává beze změny.

Pokud část změn nejde použít, uloží se do souboru `*.rej`. Tyto změny musíme sami připojit nebo je odvrhnout.
{{{
 $ cat *.rej # vypíše obsah souboru
 (rozhodneme o změnách)
 $ hg commit
 (napiš komentář komitu)
}}}

<!> Pokud jsme revizi 2 před odstraněním někomu poslali, může se stát, že si ji opět stáhneme.


== Závěrečné poznámky ==

Popisy dalších průběhů lze nalézt na již zmiňované stránce
[[http://selenic.com/mercurial/wiki/Workflows| Workflows]].

Autorem originálního textu "Learning Mercurial in Workflows" je Arne Babenhauserheide.
Text je chráněn licencí [[http://gnu.org/licenses/gpl-2.0.html| GPLv2]]

Průběhy práce v Mercurialu

V Mercurialu lze realizovat mnoho různých vývojových schemat. V tomto textu se s některými seznámíme, přičemž budeme postupovat od jednodušších ke složitějším. Účelem této pomůcky je usnadnit začátečníkům práci se sledováním verzí (verzování). Použité pojmy nejsou vždy vysvětlovány, neboť existuje řada jiných výtečných textů (Základy Mercurialu a Za kulisami), které tak činí.

Podrobnější popis se základními pojmy naleznete v tutorialu o používání Mercurialu - CzechTutorial. Opravdu podrobný a velmi čtivý popis Mercurialu obsahuje kniha B. O´Raillyho Mercurial:The Definitive Guide.

<!> Tento průvodce nevyžaduje žádnou předchozí znalost VCS (i když uživatelé Subversion se budou patrně brzo cítit doma). Zkušenosti s konzolou příkazového řádku budou prospěšné, protože CLI budeme používat.

Základní průběhy

Osamělý vývojář s jednoduchou historií

Popis případu

První průběhové schema je nejsnadnější. Chceme zaznamenávat změny a mít možnost se kdykoliv ke kterékoliv vrátit a prohlédnout si ji.

Průběh

Jako první krok bychom měli zadat své jméno. V textovém editoru otevřeme soubor ~/.hgrc, přidáme sekci ui (user interaction) a zapíšeme jméno, případně s e-mailovou adresou:

 [ui]
 username = Mr. Johnson <hali@beli.cz>

Nyní vytvoříme adresář, ve kterém budeme pracovat (včetně složky .hg):

 $ hg init baboon        

Přejdeme do adresáře, vytvoříme nějaké soubory a přidáme je ke sledování:

 $ cd baboon
 $ (vytvoření souborů)
 $ hg add

<!> Můžeme také vstoupit do existujícího adresáře se soubory a tam vytvořit složku (repozitář) .hg:

 $ cd project
 $ hg init

Případně můžeme přidat ke sledování jenom určité soubory místo všech souborů v adresáři. Následujícím příkazem například přikážeme sledování souborů file10, file11 a file12:

 $ hg add file0* 

Přidané soubory se staly "kandidáty pro registraci". Vlastní zápis změn do repozitáře provádíme jejich předáním příkazem commit:

$ hg commit

Vyskočí textový editor a žádá si zápis komentáře komitu. Po uložení a zavření editoru máme změny předané.

<!> Komentář komitu lze zadat zároveň s jeho příkazem (zde zkráceným):

 $ hg ci -m "Komentář"

Přítomnost nekomitovaných změn v pracovním adresáři zjistíme příkazem:

 $ hg status

případně rozdíl mezi dvěmi verzemi souboru:

 $ hg diff

Při přemístění a kopírování souborů pomocí příkazů Mercurialu (cp, mv) nemusíme tyto změny "uvádět na kandidátskou listinu" pomocí příkazů hg add, hg remove nebo hg addremove. Nezapomeneme však předat změny repozitáři, to jest provést příkaz commit:

 $ hg cp orig kopie
 $ hg ci -m "stručný komentář"
 
 $ hg mv orig sloha/rupie  # přemístit lze jen uvnitř kořenového adresáře
 $ hg ci -m "sloha je název adresáře"

Máme nyní dva nové soubory 'kopie' a 'rupie' a Mercurial o nich ví.

Výpis seznamu všech zaznamenaných změn vyvoláme příkazem:

 $ hg log

Informace o changesetu (revizi) obsahuje ID, jméno komitenta, datum a čas komitu a komentář.

Pokud nás zajímá jenom určitá revize, použijeme přepínač -r (--revision). Aby se nám také zobrazil diff určené revize, přidáme přepínač -p (--patch):

 $ hg log -p -r 3

Osamělý vývojář s větvenou historií

Popis případu

Druhé průběhové schema je stále velmi jednoduché: jste sám a chcete aby Mercurial zaznamenával vaše změny, přičemž je možné, že se budete chtít někdy vrátit ke starší revizi a dodatečně ji upravit.

Průběh

Otevření nového projektu, případně založení nového repozitáře, případně další práci v pracovním adresáři provádíme známým způsobem:

 $ hg init projekt
 $ cd projekt
 $ (přidáme soubory)
 $ hg add                    # zařadíme je ke sledování
 $ (provedeme nějaké změny)
 $ hg diff                   # prohlédneme si je
 $ hg ci -m "zápecí"         # předáme je repozitáři
 $ hg cp copak kampak        # kopírujeme soubory či složky
 $ hg mv copak kampak        # přemístíme soubory či složky
 $ hg ci -m "párátko"
 $ hg log                    # prohlédneme si historii

Návrat ke starší revizi

Tím, že jsme v našem adresáři vytvořili systémový adresář (repozitář) .hg, učinili jsme z našeho pracovního adresáře "vnímavý útvar", jehož skladba a obsah jeho souborů se mění v závislosti na nastavené aktuální revizi.

Implicitně je touto revizí revize poslední, nazývaná tip. K libovolné jiné revizi se dostaneme příkazem hg update REV, přičemž REV je pořadové číslo revize. Poslední revizi zas můžeme aktualizovat (zkráceně) příkazem hg up tip

Která revize je právě aktuální, se dozvíme příkazem hg identify -n, kde si přepínačem n říkáme o pořadové číslo revize.

Příkaz identify bez přepínače nám vrátí zkrácený tvar ID. Na rozdíl od pořadového čísla revize, které pro tentýž changeset může být v každém repozitáři jiné, se toto číslo nemění. Pořadové číslování revizí začíná nulou.

Je-li aktuální poslední revize, hg identify -n vrátí -1.

Oprava starších chyb

Opravou chyby ve starší revizi vytvoříme v repozitáři další čelo (head), které musíme sloučit s čelem stávajícím:

 $ hg update 3              # tam máme čertovo kopýtko
 $ (opravíme chybu)
 $ hg commit

Oprava chyby je "zaknihována", ještě sloučíme čela:

 $ hg merge

Pokud by se při sloučení vyskytl problém, použijeme příkaz hg resolve - tak, jak jsme případně programem vybízeni.

Nejprve dáme vypsat seznam konfliktních souborů:

 $ hg resolve --list

Potom je jeden po druhém řešíme. Příkaz resolve se opět pokusí o sloučení:

 $ hg resolve konfliktní_soubor
 (případně upravíme konflikt ručně)

Upravený soubor označíme jako řešený

 $ hg resolve --mark conflicting_file

Jakmile vyřešíme všechny konflikty, provedeme commit! Ten ostatně provedeme i když se žádné konflikty nevyskytly.

 $ hg commit

V této chvíli máme opravu sloučenou s ostatní naší prací, ve které můžeme pokračovat. Zaznamenaná historie nám jasně ukazuje, kde chyba vznikla a kdy byla opravena.

<!> Když opravíme chybu souboru ve starší revizi a v nějaké pozdější revizi byl tento soubor kopírován nebo přemístěn, bude tato oprava sloučením rozšířena do cílových souborů. To je hlavní důvod, proč bychom kopírování a přemísťování souborů uvnitř pracovního adresáře měli provádět pomocí příkazů Mercurialu hg cp a hg mv.

Oddělený vývoj

Popis případu

Někdy pracujeme současně na několika variantách jednoho programu. Chceme-li se vyhnout náhodnému pomíchání nehotových verzí kódu, můžeme vytvořit klon lokálního repozitáře a pracovat na variantách v jejich vlastních pracovních adresářích.

Po dokončení stáhneme (pull) variantu do hlavního adresáře a sloučíme (merge) ji s lokálními změnami.

Průběh

Práce s klonem

Nejprve vytvoříme klon a v něm nějaké změny:

 $ hg clone baboon makak
 $ cd makak
 $ (provedeme změny a komity)

Nyní si ověříme, co obdržíme, když provedeme pull z adresáře makak (podobně jako používáme příkaz diff před komitem). Příslušný příkaz pro to je incoming (příchozí):

 $ cd ../baboon
 $ hg incoming ../makak

<!> Kdybychom chtěli vidět i diffy, použijeme přepínač hg incoming --patch stejně jako použijeme tento přepínač (hg log --patch) při zjišťování změn v repozitáři.

Pokud se nám změny zamlouvají, stáhneme je do hlavního adresáře projektu:

 $ hg pull ../makak

Změny jsme si z adresáře makak stáhli, ale v adresáři baboon je zatím nevidíme. Jsou uloženy v repozitáři .hg (viz Za kulisami).

Pokud jsme v adresáři baboon žádné změny neprovedli, stačí nám po stažení změn z adresáře makak provést pouze hg update tip, to jest aktualizovat pracovní adresář k novému tipu. Je však více než pravděpodobné, že jsme si v baboon změny provedli; v tom případě je nutné sloučit stažené změny se změnami lokálními:

 $ hg merge

Pokud jsou konflikty, provedeme hg resolve. Po sloučení musíme provést commit, aby se naše úpravy zapsaly do repozitáře:

 $ hg ci -m "připojený makak"

<!> Lze provést libovolný počet klonů a nosit je po kapsách na tyčinkách USB.

<!> Příkaz commit musíme zadat i po nekonfliktním sloučení, protože tím tuto změnu zapisujeme do historie.

Odvolání chyb

Někdy se nám podaří provést špatný komit. Pokud to zjistíme dřív, než provedeme další komit nebo pull, můžeme tuto zmýlenou snadno napravit příkazem rollback (odvolat):

 hg rollback

Podle přísloví dobrého pomálu nelze provést rollback dvakrát bezprostředně za sebou. Příkaz rollback lze použít také pro odvolání příkazu pull, pokud jsme poté neprovedli komit.

<!> Podobně pracuje pro nekomitovanou změnu příkaz hg revert

Sdílení změn

Popis případu

Nyní postoupíme o krok dále: Již nejsme sami a chceme své změny sdílet s ostatními.

V Mercurialu můžeme tuto spolupráci realizovat prostřednictvím lokálního serveru, posíláním změn e-mailem nebo s využitím veřejně přístupného webového serveru.

Použití lokálního serveru

Aktivací vestavěného lokálního serveru na portu 800 umožníme ostatním na síti přístup do našeho počítače:

 $ hg serve

Zkusme nyní ve vlastním webovém serveru zadat adresu http://localhost:8000/. Otevře se nám stránka s pěkným přístupem k tomu repozitáři, u kterého byl server aktivován.

Všichni ostatní se k našemu serveru dostanou, pokud znají naši IP adresu (např 192.168.178.100)

 $ firefox http://192.168.178.100:8000

Mohou si z našeho repozitáře stáhnout poslední změny:

 $ hg pull http://192.168.178.100:8000

Z bezpečnostních důvodů je možné přes tento server provádět pouze pull, nikoliv push.

Posílání změn e-mailem

Může se stát, že nemáte přístup k cizímu repozitáři; ten je buď odstíněn bezpečnostním firewallem nebo se nachází v jiném časovém pásmu. Důvodů pro tento způsob přenosu změn může být celá řada.

Změny pošleme jako specielní oprávkové soubory s příponou .diff.

Nejprve se podíváme, co vlastně chceme poslat:

 $ cd project
 $ hg log

Řekněme, že chceme poslat revize 3 a 4. Oprávkové soubory .diff vytvoříme pomocí příkazu 'hg export':

 $ hg export 3 > change3.diff
 $ hg export 4 > change4.diff

Soubory pošleme e-mailem. Příjemce si změny může importovat do svého repozitáře. Když bude opatrný, vytvoří si za účelem příjmu cizích změn klonovaný repozitář, do něhož změny načte:

 $ hg clone project integration
 $ cd integration
 $ hg import change3.diff
 $ hg import change4.diff

Po patřičné kontrole si importované změny stáhne do svého hlavního repozitáře:

 $ cd ../project
 $ hg pull ../integration

<!> Velmi efektní způsob přenosu změn v souboru je pomocí tak zvaného svazku (bundle) - viz hg help bundle.

Použití společného repozitáře

Společný repozitář si vytvoříme na kolektivně přístupném privátním nebo veřejném serveru. Veřejných serverů je celá řada. Vyjmenujeme-li alespoň dva, zmíníme BitBucket a Launchpad. Posledně jmenovaný je podporován konkurenčním VCS, zvaným 'Bazaar'.

Základním pravidlem dobrého chování je to, že u takového repozitáře nevytváříme dvě čela.

Znamená to, že chceme-li poslat své změny do centrálního repozitáře, provedeme nejprve akci pull a ve svém repozitáři vyřešíme případné konflikty a provedeme sloučení. Takto synchronizovanou změnu potom příkazem push můžeme vyslat do centrálního repozitáře.

U centrálních repozitářů lze nastavit různou přístupovou politiku.

Popíšeme si podrobněji postup na serveru BitBucket, kde se zapíšeme jako uživatel.

Po přihlášení si vytvoříme nový repozitář tak, že přejedeme kurzorem přes nápis Repositories a vybereme Create new. Zadáme nazev repozitáře a popis jeho účelu. Chceme-li uzavřít přístup široké veřejnosti, označíme jej jako private.

Poté v repozitáři poklepneme na záložku Admin, kde můžeme v části Permissions:Readers a Permissions:Writers zapsat uživatelská jména svých kolegů, čímž jim umožníme provádět push do našeho repozitáře.

Řekněme, že naše uživatelské jméno je "ozon" a název repozitáře je "foo". Potom adresa našeho repozitáře bude https://bitbucket.org/ozon/foo.

Při volání našeho repozitáře (například)

$ hg incoming https://bitbucket.org/ozon/foo

jsme žádání o zadání uživatelského jména a hesla pro bitbucket.

S tímto repozitářem zacházíme stejně jako s lokálním repozítářem. Můžeme si z něho pořídit také lokální kopii (hello):

 $ hg clone https://bitbucket.org/ozon/foo/ hello

Do konfiguračního souboru naklonovaného repozitáře se automaticky načte adresa on-line repozitáře, takže ji při jeho volání nemusíme zadávat.

<!> Variantně lze dohodnout, že každý člen kolektivu má na bitbucket otevřený svůj repozitář, do kterého posílá své změny. Určený administrátor potom tyto změny podle svého uvážení stahuje do centrálního repozitáře, z něhož si ostatní aktuální změny stahují.

<!> You can also use this workflow with a shared server instead of bitbucket, either via SSH or via a shared directory. An example for an SSH URL with Mercurial is be ssh://user@example.com/path/to/repo. When using a shared directory you just push as if the repository in the shared directory were on your local drive.

Shrnutí

Jak bylo již řečeno na začátku, tento text nevysvětluje podrobnosti, což je někdy právě to, co potřebujeme. Můžeme-li trochu anglicky, je dobré zkusit nápovědu k jednotlivým příkazům

$ hg help <příkaz>

Popsané postupy si ještě stručně připomeneme.

založit projekt

 $ hg init project
 $ cd project
 $ (přidat nějaké soubory)
 $ hg add
 $ hg commit
 (napsat komentář komitu)

větvený průběh

 $ (proveď nějaké změny)
 $ hg commit
 (napiš komentář komitu)
 $ hg update 0
 $ (proveď nějaké změny)
 $ hg commit
 (napiš komentář komitu)
 $ hg merge
 $ (případně s použitím hg resolve)
 $ hg commit
 (napiš komentář komitu)

rozdělení do klonů

 $ cd ..
 $ hg clone project feature1
 $ cd feature1
 $ (proveď nějaké změny)
 $ hg commit
 (napiš komentář komitu)
 $ cd ../project
 $ hg pull ../feature1

využití integrovaného serveru

 $ hg serve 
 $ cd ..
 $ hg clone http://127.0.0.1:8000 project-clone

export změn do souboru

 $ cd project-clone
 $ (proveď nějaké změny)
 $ hg commit
 (napiš komentář komitu)
 $ hg export tip &gt; ../changes.diff

import změn ze souboru

 $ cd ../project
 $ hg import ../changes.diff

stáhnout změny přes integrovaný server

 $ cd ../feature1
 $ hg pull http://127.0.0.1:8000

použití společného repozitáře na BitBucket

 $ (setup bitbucket repo)
 $ hg push https://bitbucket.org/USER/REPO
 (zadat jméno a heslo)
 $ hg pull https://bitbucket.org/USER/REPO

Pokročilé průběhy

Anulování špatných revizí

Popis případu

Při stahování kódu z jiných repozitářů se může stát, že přehlédneme chybný changeset. Poté, co si jej jiní od nás stáhli, máme malou šanci, že se jej někdy úplně zbavíme.

Pro řešení tohoto problému nabízí Mercurial příkaz backout. Tento příkaz vytváří nový changeset, který je dítětem anulovaného changesetu. Záznam špatného changesetu v historii nezrušíme, ale můžeme jej odebrat z nových revizí.

<!> Základní příkazy Mercurialu historii nepřepisují. Máme-li takovou potřebu, musíme aktivovat některou extenzi, která je součástí instalace. K tomuto tématu se vrátíme později.

Průběh

Řekněme, že špatnou změnou byla revize 3. Špatný kód se pokusíme odstranit příkazem backout. Tím vytvoříme novou změnu, která vytěsní tu starou. Protože provádíme změnu starší revize, vytvoříme další čelo, které musíme sloučit se stávajícím.

 $ hg backout 3
 $ hg merge
 (případně vyřešíme konflikty)
 $ hg commit
 (komentář komitu, např: "merged backout")

A je to. Odvolali jsme špatnou změnu. Je stále zaznamenáno, že existovala (podle zásady "nepřepisovat historii, pokud to není nezbytné"), ale již neovlivňuje budoucí kód.

Kolektivní vývoj variant

Nyní, když si umíme předávat změny a v případě potřeby je anulovat, můžeme postoupit dále: pomocí Mercurialu koordinovat vývoj kódu.

Popis případu

Chceme-li rozdělit náš projekt do několika variant, potřebujeme vědět, na čem kdo pracuje a kde se jeho práce ukládá.

Mercurial to umožňuje svými "pojmenovanými větvemi". Ty jsou součástí hlavního repozitáře, takže jsou přístupné každému účastníkovi. Zároveň se změny komitované v pojmenované větvi nemísí se změnami v hlavní (default) větvi.

Průběh

Když někdo v naší skupině chce začít pracovat na variantě tak, aby nerušil ostatní, může vytvořit pojmenovanou větev a své změny ukládat zde. Když se někdo chce připojit, nic mu nebrání; připojuje své změny na konec větve. Po ukončení vývoje varianty lze pojmenovanou větev sloučit s hlavní větví.

Práce v pojmenované větvi

Vytvoření pojmenované větve:

 $ hg branch ferari     
 (proveď nějaké změny)
 $ hg commit            # větev se nadál jmenuje ferari
 (napiš komentář komitu)

Můžeme používat příkazy commit, pull, push, merge, ... jako kdybychom pracovali v samostatném repozitáři.

 $ hg update default    # nás přenese k poslední revizi před 'ferari'
  ...
 $ hg update ferari     # nás vrátí k poslední revizi větve 'ferari'

Sloučení pojmenované větve

Po ukončení alternativního vývoje pojmenovanou větev ukončíme sloučením.

 $ hg update default
 $ hg merge ferari
 $ hg commit
 (napiš komentář komitu)

<!> Ukončená pojmenovaná větev je natrvalo zapsaná do historie. Pokud ji tam mít nechcete, lze to řešit způsobem, popsaným ve Workflows.

Označování revizí

Popis případu

Pro označení revizí uživatelem se v Mercurialu používají tagy. Připojení tagu k revizi lze provést i dodatečně. Zadání tagu vytváří samostatný changeset generovaný automatickým komitem se standardním koomentářem.

<!> Tag nesmí obsahovat znak ":", protože tento znak se používá pro vymezení rozsahu revizí - viz "hg help revisions".

<!> K bezpečnému označení revizí lze použít gpg extenzi.

Průběh

Řekněme, že cheme revizi 3 dát jméno otto

Přidáme tag:

 $ hg tag -r otto

Prohlédneme si všechny tagy:

 $ hg tags

Když se podíváme na záznam (log), uvidíme v revizi 3 další řádek s názvem tagu. Chceme-li aktualizovat pracovní adresář k označené revizi, použijeme její tag:

 $ hg update otto

Odstranění historie

Popis případu

Někdy máme v repozitáři změny, které nepotřebujeme a chtěli bychom je odstranit.

Tento problém lze řešit více způsoby s použitím extenze (Mercurial Queues). My si ukážeme řešení prostřednictvím příkazů, které jsme spolu poznali.

  • But we'll use an option to clone which we didn't yet use.

Tento pracovní postup není ale vhodný, pokud potřebujeme odstranit velmi zasuté změny.

Průběh

Řekněme, že se chceme zbavit předposlední revize 2.

Vytvoříme klonovaný repozitář s revizemi 0 až 1. Revizi 3 exportujeme jako oprávku do klonovaného repozitáře, kterou tam posléze importujeme:

 $ hg clone -r 1 baba bubu
 
 $ cd baba
 $ hg export 3 > ../bubu/rev3.diff
 
 $ cd ../bubu
 $ hg import rev3.diff
 $ hg add                # adding rev3.diff
 $ hg ci -m "Adieu"

V repozitáři bubu došlo k přečíslování; máme revize 0 až 4. Původní revize 2 je pryč, komentář poslední revize je "Adieu". Repozitář baba zůstává beze změny.

Pokud část změn nejde použít, uloží se do souboru *.rej. Tyto změny musíme sami připojit nebo je odvrhnout.

 $ cat *.rej                # vypíše obsah souboru  
 (rozhodneme o změnách)
 $ hg commit
 (napiš komentář komitu)

<!> Pokud jsme revizi 2 před odstraněním někomu poslali, může se stát, že si ji opět stáhneme.

Závěrečné poznámky

Popisy dalších průběhů lze nalézt na již zmiňované stránce Workflows.

Autorem originálního textu "Learning Mercurial in Workflows" je Arne Babenhauserheide. Text je chráněn licencí GPLv2

CzechWorkflows (last edited 2013-12-28 09:13:03 by Tovim)