Mercurial, jak nastavit P4Merge jako nástroj pro vizuální merge a diff

Mercurial je výborný distribuovaný verzovací systém (DVCS). Je free a má spoustu zajímavých vlastností. Perforce (P4) je centralizovaný verzovací systém. Má převážně komerční licenci a výborné nástroje na mergování a branchování. Co můžou mít tyto dva systémy společného?

P4Merge

P4Merge je grafický nástroj pro merge a diff. Je jednou ze silných zbraní P4. Já jsem ho vždycky rád používal. Jeho výhodou je, že akceptuje parametry z příkazové řádky, takže jej lze použít i mimo rámec P4 a to buď úplně samostatně, nebo jako externí nástroj z jiné aplikace. Třeba Mercurialu :-)

Diff pomocí P4Merge

Podle toho, kolik parametrů se zadá na příkazové řádce, se spustí buď diff (2 parametry), nebo merge (3-4 parametry). Každý parametr je cesta k porovnávanému souboru.

Parametry příkazové řádky P4Merge

P4Merge sice není open source, ale je free, takže nic nebrání jeho zakomponování do jiného nástroje.

Konfigurace Mercurialu

Mercurial neobsahuje nástroj na vizuální merge. Pokud je potřeba zmergovat konfliktní změny a žádný nástroj není nakonfigurovaný, tak Mercurial vloží do sloučeného souboru mergovací značky (takový to <<<<<<<<<<< something). To asi nechceme :-)

Mergovacích nástrojů existuje spousta, každý si určitě vybere. Já jsem si oblíbil P4Merge - přece jenom, když něco s oblibou používáte dva roky, tak vám to trochu přiroste k srdci. Jak teda Mercurialu podstrčíme P4Merge?

Konfigurace merge nástroje je v souboru ~/.hgrc v sekci [merge-tools]:

[merge-tools]
p4.priority = 60
p4.premerge = True
p4.executable = p4merge
p4.gui = True
p4.args = $base $other $local $output
p4.binary = False

[extensions]
hgext.extdiff =

[extdiff]
cmd.p4diff = p4merge
cmd.meld = meld

Jak je vidět, nastavil jsem si kromě merge nástroje i externí diff. Takže když pustím příkaz hg p4diff file1 file2, spustí se mi také P4Merge, tentokrát jako diff nástroj.

Merge pomocí P4Merge

Je to opravdu taková idyla?

Není. Abych byl maximálně spokojený, chybí mi (zatím) dvě věci. Jednak bych rád, abych mohl provést hromadný merge - Mercurial totiž dělá to, že pro každý mergovaný soubor sekvenčně spustí P4Merge. A já bych chtěl např. hromadně přijmout příchozí, nebo své změny. Což je věc, kterou P4 normálně umí. Ale asi je to zajištěno přes P4V klienta.

Druhá vada na kráse je, že P4Merge neumí diff více souborů (např. příkaz hg p4diff -r 12:tip). Takže ho nemůžu použít pro vizuální diff mezi revizemi. To je důvod, proč mám v souboru .hgrc jako další externí diff nástroj Meld, který diff adresářů umí.

Meld, vizuální diff mezi revizemi

Máte nějaké tipy na používání P4Merge, nebo jiného vizuálního nástroje na merge v Mercurialu? Budu rád, když se podělíte o své zkušenosti v komentářích.

Související články

• Perforce best practices

Gradle, moderní nástroj na automatizaci

Gradle je nástroj na automatizaci. Potřebujete udělat build, mít Continuous Integration, zprovoznit deployment, generovat dokumentaci, připravit release, dojít nakoupit a vyvenčit psa? Gradle je to pravé pro vás! Gradle je něco jako Ferrari, Land Rover a Mini Cooper v jednom. A funguje to.

Gradle? Co to je?

Gradle je nástroj na automatizaci. Čehokoliv. Zmáčknete tlačítko a vypadne banán :-)  Nejčastější využití asi bude na build nějakého projektu. Ale není potřeba se svazovat jen touto představou - jakmile potřebuju něco zautomatizovat, můžu na to použít Gradle (třeba na generování a odesílání měsíčních výkazů).

Gradle ve skutečnosti není automatizační nástroj - je to jazyk pro automatizaci. Je to Domain Specific Language (DSL), který nám umožňuje popsat to, co chceme zautomatizovat. Nepřekvapí, že Gradle je založený na Groovy (jestliže byl Groovy v něčem úspěšný (oproti svým konkurentům z oblasti dynamických JVM jazyků), tak je to právě jeho využití ve sféře DSL).

Výchozí těžiště Gradlu leží v buildování. V tomto směru na něj lze nahlížet jako na nástroj další generace v linii Ant -> Maven -> Gradle, přičemž ze svých předchůdců si bere (a kombinuje) to nejlepší: z Antu jeho sílu a flexibilitu, z Mavenu konvence, dependency management a pluginy.

Jádro Gradlu samo o sobě toho moc neumí - zkuste si po instalaci pustit příkaz gradle tasks. Distribuce Gradlu ale obsahuje sadu standardních pluginů, takže out-of-the-box je k dispozici podpora pro Javu, Groovy, Scalu, Web, OSGi aj. Další funkčnosti jsou k mání přes komunitní pluginy.

Tak jako spousta skvělých věcí v životě i Gradle je zadarmo - je k dispozici s licencí Apache License, Version 2.0.

Je opravdu tak dobrý?

Pokud jste se s Gradlem ještě nestkali, možná jste na pochybách, jestli má smysl se jím vůbec zabývat. Vždyť přece buildujeme Mavenem/Antem, tak na co další další nástroj? Třeba vás přesvědčí, že mezi uživatele Gradlu patří např. Spring, Hibernate, Grails, Software AG, nebo LinkedIn.

Dalším důvodem, proč u Gradle zpozornět je, že byl již podruhé uveden v prestižním(?) přehledu ThoughtWorks Technology Radar. V tom aktuálním z října 2012 je Gradle umístěn v sekci Trial, což znamená "Worth pursuing. It is important to understand how to build up this capability. Enterprises should try this technology on a project that can handle the risk."

Konkrétně o Gradlu a buildovacích nástrojích je zde napsáno: "Two things have caused fatigue with XML-based build tools like Ant and Maven: too many angry pointy braces and the coarseness of plug-in architectures. While syntax issues can be dealt with through generation, plug-in architectures severely limit the ability for build tools to grow gracefully as projects become more complex. We have come to feel that plug-ins are the wrong level of abstraction, and prefer language-based tools like Gradle and Rake instead, because they offer finer-grained abstractions and more flexibility long term."

[update 7. 6. 2013] Aktuálně vyšel nový ThoughtWorks Technology Radar (květen 2013), kde se Gradle posunul do sekce Adopt, čili: "We feel strongly that the industry should be adopting these items. We use them when appropriate on our projects." [/update]

My Way

O Gradlu jsem se dozvěděl v roce 2009, kdy jsem byl na přednášce CZJUGu v tehdejším Sunu (R.I.P.). Měl jsem to štěstí, že přednášejícím byl Hans Dockter - zakladatel a leader Gradlu (Hansova původní prezentace je v archivu CZJUGu).

Gradle se mi tehdy zalíbil. Vyzkoušel jsem ho a použil na pár vlastních drobných Java a Groovy projektech. Gradle byl tehdy ve verzi 0.8 a když se podíváte na historii verzí, je vidět, že to byla velmi čerstvá záležitost.

Mezitím urazil Gradle dlouhou cestu: 7. května vyšla verze 1.6 a osobně si myslím, že Gradle je dostatečně zralá technologie pro nasazení do enterprise prostředí. Nejsou to plané řeči - na posledním projektu jsem zvažoval, na čem postavit release management a po zralé úvaze, kdy ve hře byl kromě Gradlu také Maven, Ant, čisté Groovy a shell skripty, jsem zvolil právě Gradle jako řešení, které nejvíce vyhovovalo dané situaci a bylo dostatečně robustní, srozumitelné a rozšiřitelné, aby fungovalo i po mém odchodu z projektu.

Právě při přípravě release managementu tohoto projektu jsem se musel do Gradlu důkladně ponořit, protože jsem musel vyřešit některé ne úplně triviální záležitosti. Abych nabyté vědomosti nějak zúročil, uspořádal jsem rozlučkovou přednášku o Gradlu ve svém bývalém zaměstnání. Přednáška je k dispozici na SlideShare:

Tutorial

No a abych nabyté vědomosti ještě více zúročil :-)  rozhodl jsem se napsat o Gradlu tutorial, který budu na svém blogu postupně publikovat. Jednak bych si formát tutorialu rád vyzkoušel, ale hlavně bych se chtěl o své zkušenosti podělit. Právě sdílení informací je jedna z věcí, které mne (jako seniorního vývojáře) baví.

Pokud se již nemůžete dočkat první lekce, můžete si čekání ukrátit instalací Gradlu. V tutorialu budu používat nejaktuálnější verzi 1.7, která je dostupná v nočních buildech, ale můžete použít i stabilní verzi.

Pokud máte nějaké téma, které byste rádi v tutorialu viděli, napište mi a já se ho pokusím někam zařadit. No a samozřejmě budu rád za každý komentář.

[update 7. 6. 2013] Domluvil jsem se se serverem Zdroják, že budu (přednostně) tutorial publikovat i tam (seriál Gradle - moderní nástroj na automatizaci). Vzhledem k "publikační mašinerii" tak budou jednotlivé díly vycházet s většími prodlevami, než jsem původně počítal. Ale co to je z pohledu věčnosti? :-) [/update]

Související články

• ThoughtWorks Radar, zajímavé technologie

Cesta samuraje, rok druhý

Tak je to tady, SoftWare Samuraj má druhé narozeniny. A protože je hezké mít nějakou tradici, tak si teď jednu založím. Takže, roční rekapitulace. (Mimochodem, přiznanou inspirací mi v tomto byl N-tý rok Myšlenek Otce Fura.)

Takový souhrn lidé většinou píší k novému roku. Přiznám se, já nemám rád novoroční předsevzetí. Ale rekapitulace je trochu něco  jako lesson learned, takže věc jistě užitečná. Navíc, kolikrát si člověk (pro samou práci) ani neuvědomí, jakou cestu už urazil.

Jak to bylo

Když jsem se ohlížel zpět před rokem, neměl jsem ještě moc jasno, o čem bych chtěl psát, jak blog zaměřit. Taky jsem psal jen příležitostně. Mezitím jsem začal psát pravidelně. Poslední dobou jsem se ustálil na rytmu tři články za měsíc. Což mi časově vychází a doufám, že to vyhovuje i vám, mým čtenářům. Pozitivní je, že témat je stále dost, vyskakujou jako houby po dešti - mám jich běžně v zásobě kolem deseti a pořád neubejvaj. Dokonce musím čas od času některé i zahodit.

Celkové skóre za minulý rok je 31 publikovaných článků. Silnými tématy byly jednak technické věci, zastoupené nejčastěji prolínající se trojicí SOA, integrace, messaging a jednak věci personální - téma pohovorů. Technická témata byla daná hlavně projektově, kde jsem vytěžil několik článků o Oracle SOA Suite, WLST a Kanbanu. Personální témata byla v mém pracovním (nejenom projektovém) životě také často přítomna - dělal jsem desítky pohovorů na několika různých úrovních, plus inspirativní zkušenosti z team leadingu. No a tradičně živné téma pro mne byly samozřejmě (odborné) knihy.

Co cítím jako resty, zbylo mi několik témat z oblasti SOA governance, SOA designu a Perforce (P4). Možná se ještě k něčemu z toho vrátím (no, P4 asi ne).

Wind of Change

Jak to tak v životě chodí, jednou za čas přichází změna. Poslední projekt pro mne byl velmi intenzivním zážitkem. V tom pozitivním smyslu to byly technologie a částečně lidský faktor. V tom negativním to bylo projektové řízení. Ten negativní aspekt byl tak působivý, že se tento projekt pro mne stal katalyzátorem odchodu  - a to nejen z projektu, ale také z firmy, kde jsem pracoval 4,5 roku.

O tom projektu určitě něco napíšu, dost možná, že to bude i série článků (tak vydatný zdroj inspirace to byl ;-)  Ale nechám tomu nějaký čas - když člověk píše o negativních věcech, měl by od toho mít odstup. A taky si k tomu chci načíst nějakou literaturu.

Vizionářské okénko

[intermezzo] Víte, kdo byl (podle mne) nejlepší "počítačový" vizionář? Steve Jobs. Jsem linuxák a Steva jsem nikdy nežral. Ale to co dokázal je úctyhodné (hezky to sepsal třeba Petr Staníček).

A víte, kdo je (pro mne) nejhorší "počítačový" vizionář? Bill Gates. (OK, jsem linuxák... ale třeba Win 7, nebo MS SQL Server používám rád.) Chudák, tomu chlápkovi snad nikdy žádná předpověď nevyšla. A za ten jeho špílec "640K ought to be enough for anybody." by mu měli postavit pomník. (No, prej to možná neřek. Ale stejně je to dobrá hláška. A někdo ji říct musel.) [/intermezzo]

Já se samozřejmě s uvedenými pány nebudu srovnávat. Jen si trochu zavěštím, o čem byste si mohli přečíst v příštím roce. Některé věci budou přímo spjaté s mojí novou prací, takže bych čekal něco o security (zatím nemůžu být víc specifický konkrétnější), něco o verzovacím systému Mercurial a možná i nějaký JBoss 7. A opět team leading.

Mezi témata spjatá s prací volněji (anebo vůbec) patří nástroj na automatizaci Gradle, o kterém bych chtěl napsat tutorial a také bych se chtěl vrátit k Hadoopu (což se mi pořád ne a ne podařit). Tak uvidíme. O čem byste si rádi přečetli vy?

Související články

• Změna domény a malá rekapitulace
• Druhý rok s Kindlem