GUI vs. příkazová řádka na příkladu verzovacích nástrojů

6 Srp 2009

Všechno to začalo v pondělí, když David Majda (@dmajda) na Twitteru napsal:

„Zajímavé, jak vývojáři na Windows stále řeší GUI klienty k verzovacím systémům. Na Unixu přitom nikomu nechybí. Hezká ukázka rozdílu kultur.“ (link)

Patrně to bylo nepřímou reakcí na mé neustálé reptání, že distribuovaným verzovacím systémům chybí kvalitní Tortoise klient a že tedy radši zůstávám u Subversion. I pokud to reakcí na mě nebylo, nezabránilo mi to v uspořádání drobného experimentu, který by rozdíl GUI versus příkazová řádka nějak lépe demonstroval (k psychologovi kvůli vztahovačnosti zajdu později :)

Dal jsem dohromady dokument, ve kterém jsem popsal, co při práci s verzovacím systémem dělám nejčastěji a jak mi v tom pomáhá TortoiseSVN. Na zastáncích příkazové řádky potom bylo popsat, jak se daný use case řeší v jejich prostředí. Největší kus práce za git udělal jeho velký příznivec Karel Minařík (@karmiq, který bude mimochodem o gitu mluvit na letošním WebExpu) a za Mercurial David Majda (@dmajda). Velký dík oběma pánům za jejich čas! (Poznámkami nebo drobnějšími úpravami se podíleli i další autoři, kteří jsou na začátku dokumentu uvedeni – i jim patří mé díky!)

Výsledek můžete vidět zde.

V dokumentu samotném jsme se snažili vyhnout subjektivním hodnocením, ale celý experiment samozřejmě probíhal právě proto, abychom si nějaký názor mohli udělat, a v tomto zápisku si můžu luxus subjektivnosti dovolit. Zde je tedy seznam postřehů, které si odnáším já:

Celkem podle očekávání je mezi GUI a CLI propastný rozdíl v intuitivnosti. Zatímco na CLI musím znát příkaz nebo jejich sekvenci, které mi umožní daný úkol provést, v TortoiseSVN prostě „kouknu a vidím“. Asi největší problém mají CLI nástroje s úkolem typu „chci ve vizuálním porovnávacím programu vidět, co se v daném souboru změnilo“ (ať už v aktuálně upravované verze versus v commitnuté, nebo v historické verzi versus v ještě o něco starší). Bez skriptování se tady patrně CLI nástroje neobejdou (jinými slovy, tento scénář v základu vůbec nepodporují), zatímco v TortoiseSVN mi stačí jen dvojklik na vybraný soubor a tsvn už na pozadí všechnu „špinavou“ práci udělá samo.
Jsou některé úkoly, které bude PITA dělat na příkazové řádce. Jeden příklad za všechny: mám 50 souborů, ze kterých chci commitnout nějakých třicet. V TortoiseSVN hračka, na CLI „zábava“ na dlouhé zimní večery. Nedělá se to sice moc často, ale občas to potřebuji.
To, co v GUI považuji za samozřejmé (kontrola pravopisu, automatické doplňování jmen souborů apod.) CLI v základu buďto nepodporuje, nebo by opět bylo potřeba skriptování, nebo se k řešení úkolu musí tak jako tak uchýlit ke GUI (např. kontrolu pravopisu může zařídit externí editor, pokud je použit ke psaní commit message). Hezky to napsal @abtris: „Je videt jak jsi tim TSVN zhyckany ;-)“ (link). Co někdo považuje za zhýčkanost, já považuji za samozřejmost. Opět z mého pohledu typický rozdíl mezi GUI a CLI… Update: V komentářích @abtris doplnil, že myslel spíš TortoiseSVN vs. další GUI klienti, např. pro Eclipse nebo Netbeans. V porovnání s nimi by asi CLI vyšlo o trochu lépe (z mého pohledu).
Celkově mě překvapilo, u kolika pro mě naprosto základních scénářů je u git/hg CLI nutno zabývat se nějakými workaroundy nebo „skriptováním“. V dokumentu najdete úryvky jako „šlo by to snadno dopsat do vestavěného webserveru“, „podporu bych musel naskriptovat způsobem…“, „případně si napsat nějaký skript na parsování“ a podobně. Nic proti, hlavně že to vůbec nějak jde, ale opět rozdíl oproti TortoiseSVN je ten, že tam podobné věci absolutně nemusím řešit – ty věci prostě fungují.

Každý, ať si udělá názor svůj, ale pokud jsem k experimentu přicházel jako skeptik, co se CLI týče, odcházím s jasným názorem, že můj čas je příliš cenný na to, abych se v současnosti DVCS bez odpovídající Tortoise zabýval. Abych byl fér, pro git i Mercurial dnes už Tortoise nástroje existují (nejsou moc kvalitní, ale řekněme 70% mých potřeb pokrývají), nicméně tento experiment byl specificky „soubojem“ GUI a příkazové řádky. Na poznámky typu „k čemu potřebuješ GUI, když máš CLI?“ vždycky koukám trochu s otevřenou pusou, protože z mého pohledu jsou výhody GUI do očí bijící.

Dovětek

Aby náhodou nebylo v tomto článku kontroverze málo :), musím se ještě podělit o zkušenosti s Google Docs, které byly použity jaké médium tohoto experimentu. Jednou větou: GDocs jsou vtip. MS Word 1.0 jsem sice nezažil, ale tak nějak si ho představuji. Kromě typických problémů s naivní implementací formátování (nekonzistentní chování stylů na základě toho, co mám právě ve výběru, divně fungující odrážky apod.) obsahují GDocs i velké množství problémů s použitelností (například nemůžu nastavit velikost písma 11pt, change tracking je skoro nepoužitelný apod.) Jen jako kyselá třešnička na dortu pak působil fakt, že funkce Download as Word document nefungovala vůbec. No prostě představa, že dokumenty své firmy postavím na GDocs (jak to Google inzeruje v Google Apps pro firmy), mi připadá úsměvná. Svět potřebuje MS Office 2010 Web Apps a Microsoft to ví :)

blog uživatele Borek

karmi (Čt, 2009-08-06 11:09):

Díky za zábavný a zajímavý experiment.

Ale, jak už to bývá, nedá mi to:

1/ propastný rozdíl v intuitivnosti… „kouknu a vidím : Jasně, to je rozdíl mezi CLI a GUI obecně! Druhou stranou mince je: a) flexibilita a b) skriptovatelnost.

2/ mám 50 souborů, ze kterých chci commitnout nějakých třicet. V TortoiseSVN hračka, na CLI „zábava“ na dlouhé zimní večery : Ne a ne a ne :) Díky možnosti přidat najednou všechno (git add .) a pak selektivně odebírat (git reset HEAD app/models/photo_*.rb) za pomoci doplňování cest přes [TAB] a wildcards to může být i několikanásobně rychlejší.

3/ Z pohledu efektivity práce s nástrojem je ale GUI téměř vždy lepší, než CLI : Je tohle subjektivní názor nebo názor nárokující si obecnou platnost? Zejména s tím dovětkem o „vždy“? Pokud to druhé, pak je to absurdní, a zase to bohužel celou původně zajímavou debatu jen zamlžuje. To, že je někdo, příp. většina lidí efektivnější při práci s GUI, kde „kliknu a vidím“, neznamená přece, že někdo, kdo udělá gia app/controllers/photo ; gico [... editace commit message] ; gibr master && git merge hotfix34; gips není „efektivnější“… A jsme zase na začátku…

Borek (Čt, 2009-08-06 11:40):

S tou trojkou máš pravdu, celý odstavec byl hloupý a odstranil jsem ho (byl subjektivní, ačkoliv se tak netvářil). Nemůžu nijak objektivně dokázat, že jedno kliknutí na checkbox je rychlejší než napsat git reset HEAD app/model/photo_*.rb a tam asi všechny debaty o GUI vs. CLI končí :)

karmi (Čt, 2009-08-06 15:04):

jedno kliknutí na checkbox… git reset HEAD app/model/photo_.rb*

Je to ještě složitější :) On ten wildcard znamená více kliknutí na checkbox, pokud budu mít modely photo_folder a photo_metadata a photo_kdovíco. Místo wildcardu můžu využít i doplňování cest v shellu… Atd atd atd. Já myslím, že ta debata je zajímavá přesně jen do toho momentu, kdy nesrovnáváme navzájem to co neznáme, ale popisujeme, jak děláme to, co potřebujeme, v nástroji který naopak dobře známe.

Botanicus (Čt, 2009-08-06 15:39):

Bud v klidu, ja vim o co go.

karmi (Čt, 2009-08-06 17:09):

Tenhle komentář ovšem nemířil na tebe .)

Botanicus (Čt, 2009-08-06 17:09):

Sorry

Botanicus (Čt, 2009-08-06 11:37):

„Abych se vrátil k původnímu tweetu Davida Majdy, který celý experiment odstartoval, podle mého názoru nejde o „rozdíl kultur“, ale o rozdíl ve vnímání cennosti vlastního času.“

Prave naopak, tohle je ciste rozdil kultur, ver mi ze jsem s Gitem uplne stejne efektivni jako Ty s TSVN, plus ale kdyz pripoctu vyhody Gitu oproti, tak si myslim ze na tom budu lip ja se svym „spinavym CLI“ :) A hlavne, moznosti CLI jsou neomezene, kdezto GUI zakonite omezeni mit bude. Viz treba gitove hooky, pisu je pro kazdy projekt, protoze jsou fakt uzitecne, hlidam tim spoustu veci, ktere jsou ale v kazdem projektu rozdilne.

Nehlede na to, ze ja muzu napriklad vybirat podle zcela libovolneho patternu. (To bych bral urcite jako vetsi vyhodu nez postupne odebirani pres git reset HEAD whatever jak pise karmi, to bych teda fakt nechtel delat.) Chci pridat rekurzivne vsechny spustitelne soubory koncici na rb? git add **/.rb() Moznosti jsou temer neomezene. To zase v GUI mit nebudes. (IMHO, TSVN jsem v zivote nevidel, ale myslim si to).

(Dulezite taky je, ze dost veci muzes resit pluginem do oblibeneho textoveho editoru, to spoustu veci zjednodusuje. Je to sice uz GUI, ale je to na pomezi obou kultur.)

Ad Google Docs, opet nesouhlasim, miluju je a jsou hrozne uzitecne treba v situaci kdy mi naky blbec posle doc, xls nebo neco podobneho. Nemam zadne office a rozhodne nemam v umyslu si je instalovat, a diky gdocs si to muzu na jediny klik prohlidnout z mailu, pripadne i upravit. To je rozhodne genialni. Mozna to neni prilis sofistikovany nastroj, ale to od nej vetsina uzivatelu ani neocekava.

Borek (Čt, 2009-08-06 11:47):

Promiň, ten odstavec jsem teď akorát z článku smazal. Jak jsem psal karmimu, i mně se po druhém přečtení zdál hloupý.

Ad patterny pro výběr souborů ke commitu: to TortoiseSVN nemá a ještě nikdy mi to nechybělo – 95% případů obstará checkbox „select all“ (navíc jsou všechny změněné soubory defaultně označené), zbylých 5% případů jsou situace, kdy se mi nastřádalo víc změn dohromady a chci je commitnout po logických celcích – tady většinou musím manuálně rozhodnout soubor po souboru, co zahrnout a co ne, regulární výraz by mi většinou vůbec nepomohl.

Ad hooky: to s GUI vs. CLI nesouvisí, i svn samozřejmě hooky podporuje a není problém je používat v kombinaci s TortoiseSVN (nebo se SVN CLI).

Ad GDocs: jsem rád, že aspoň někomu na světě se ten software líbí :) Opět bych zde poznamenal, že můj čas je pro používání GDocs příliš cenný.

Botanicus (Čt, 2009-08-06 12:28):

S temi hooky mas pravdu, ale pro me je tahle debata hodne o win GUI vs. unix CLI-based cultures, a ty hooky proste patri k te unixove kulture. Samozrejme muzes je pouzivat i kdyz mas GUI, proc by ne :) Vim ze je ma i SVN.

Google Docs: Tvuj cas je prilis ceny na psani dokumentu v Google Docs, to chapu, ale na otvirani priloh je to bozi i kdyz mas office, nemusis nic stahovat etc, to prave ten cas setri :)

karmi (Čt, 2009-08-06 15:06):

95% případů obstará checkbox „select all“ == 95% případů obstará git add . Takže jsme na tom asi podobně .)

karmi (Čt, 2009-08-06 15:09):

postupne odebirani pres git reset HEAD whatever jak pise karmi, to bych teda fakt nechtel delat. – a proč? co tě odrazuje? pro mně to odpovídá mentálnímu modelu „přidej ABC a vyhoď XYZ“ než hrátky s filtrama…

Botanicus (Čt, 2009-08-06 15:51):

Kdyz tam ten pattern je (velmi casto byva), tak neni duvod nepouzit globy, kdyz je umim samozrejme :) Samozrejme kdyz tam pattern neni, tak neni duvod s tim sasit, ale IMHO je blbost je vubec nepouzivat.

Aleš Roubíček (Čt, 2009-08-06 11:41):

No já už skoro dva měsíce denně používám TortoiseGit (aktuálně 0.9.1) a nemůžu si stěžovat, tedy krom zatím chybějící integrace do VS. Podporuje nejen to, co má TSVN, ale i některé věci, typické pro git, navíc. Jak je na tom TortoiseHg netuším. Rozhodně bych však Tortoise pro DVCS takto nezatracoval nezatracoval. :)

Borek (Čt, 2009-08-06 11:51):

TortoiseHg je na tom poměrně bledě (i když základní věci to umí), ale je asi fakt, že TortoiseGit se vyvíjí rychleji a je celkově lepší (a taky má hezčí UI, protože ho založili na tsvn). Nicméně, jak píšu v článku, šlo mi hlavně o poukázání na to, že GUI je hodně důležité, a že nechápu, co na tom CLIčkaři nechápou :)

Botanicus (Čt, 2009-08-06 12:30):

" Nicméně, jak píšu v článku, šlo mi hlavně o poukázání na to, že GUI je hodně důležité, a že nechápu, co na tom CLIčkaři nechápou :)"

Tohle se da uplne obratit „CLI je hodne dulezite…“ a bude to stejne tak pravda.

Martin Michálek (Čt, 2009-08-06 11:49):

Dneska jsem shodou okolností šťastně poprvé použil TortoiseGit a ten magnet uživatelské zvyklosti z TortoiseSVN velmi funguje.

Jenže logika práce SVN a Git mně připadá natolik rozdílná, že to rozhraní bych si asi představoval trochu jinak. Myslím, že ani TortoiseGit nebude moc spásný, pokud se bude vyvíjet stylem „co nejvíce něco jako TortoiseSVN“.

Mimochodem, nevím jak dlouho už, ale další Windows klient – Git-GUI – má teď funkci Tools, kde je možné si do rozhraní nadefinovat vlastní Git příkazy, což by mohlo geekům vyhovovat. Práce s ním je ale samozřejmě obecně těžkopádnější, i když trošku blíže logice Gitu.

David Majda (Čt, 2009-08-06 12:11):

Taky se přidávám s poděkováním a snad to srovnání bude užitečné i pro někoho jiného než pro tebe. Pár poznámek:

1. Můj tweet byla reakce na to, že se v krátkém časovém úseku o VCS a klientech bavili hned 3 programátoři používající Windows: ty, David Grudl a Jakub Vrána. Čí poznámka byla „poslední kapkou“, která mě přiměla zareagovat, už nevím. Každopádně ty jsi to celkově řešil nejvíc :-)

2. „na CLI musím znát příkaz nebo jejich sekvenci, které mi umožní daný úkol provést“ – to není úplně pravda, já třeba často používám „hg help“ a inteligentní doplňování shellu – pamatuju si jen to, co často používám (stejně jako ty si nejspíš pamatuješ, kolikátá položka v menu je „Commit“ a najíždíš na ni po paměti). Je ale fakt, že v GUI mám obvykle v každé situaci k dispozici seznam aplikovatelných příkazů, což se hodí.

3. „Asi největší problém mají CLI nástroje s úkolem typu „chci ve vizuálním porovnávacím programu vidět, co se v daném souboru změnilo““ – to je proto, že vizuální nástroje jsou mimo doménu CLI. Na Unixu je obvyklá filozofie „one tool – one job“, tj. VCS umí vyprodukovat diff, jiný program ho pak třeba hezky zobrazit. Od propojování těchto nástrojů je shell.

4. Píšeš, že je časo potřeba skriptování. Já to vidím opačně: jsem, rád, že mám možnost skriptování. Cením is toho, že pokud budu například opakovaně dělat nějakou sekvenci kroků, není pro mě problém si ji zautomatizovat, případně si můžu poskládat „high level tasks“ ze základních příkazů. To s GUI typicky nejde a z mého pohledu je tak GUI sice možná efektivnější v některých konkrétních činnostech, ale tato efektivita má pevně daný strop. U CLI to tak není.

5. Stále si myslím, že jde o rozdíl kultur. V principu není totiž žádný problém používat CLI na Windows (pokud přežiješ cmd.exe nebo nainstaluješ Cygwin) ani napsat GUI klienta ekvivalentního TortoiseNěco na Macu nebo Linuxu, ale lidi to nedělají. Uživatelé různých platforem prostě uvažují a pracují jinak a mají jiné priority. Zajímavě na tohle téma psal před časem Joel Spolsky: http://www.joelonsoftware.com/…uralism.html.

Borek (Čt, 2009-08-06 13:25):

Díky za komentář, který asi dobře reprezentuje pohled „z druhé strany“ (pokud můžu posoudit). Zaujalo mě toto:

to je proto, že vizuální nástroje jsou mimo doménu CLI. Na Unixu je obvyklá filozofie „one tool – one job“, tj. VCS umí vyprodukovat diff, jiný program ho pak třeba hezky zobrazit. Od propojování těchto nástrojů je shell

Zaujal mě pojem „doména CLI“. Já takto neuvažuji. Pro mě je doména „verzování“ (nebo správa zdrojového kódu nebo jak tomu kdo říká). Neuvažuji v intencích nástroj 1 versus nástroj 2, potřebuji kompletní workflow pro dělání daných úkolů. TortoiseSVN bez visual diffu by například byl poměrně k ničemu, což je asi důvod, proč bych si jako UI k VCS nevybral příkazovou řádku, když ji stejně musím k udělání některých velmi častých úkonů opustit.

David Majda (Čt, 2009-08-06 18:26):

A tvoje odpověď zas dobře reprezentuje onen rozdíl kultur, o kterém jsem mluvil – to, že neuvažuješ o komponentách a nástrojích, ale integrovaném řešení. Já jako Unixář jsem naopak zvyklý na mnoho malých jednoduchých nástrojů, kde síla vzniká jejich efektivní kombinací.

Mohl bych možná ještě dodat, že dobře znám i pohled z druhé strany – ostatně Linux používám fulltime jen cca 2,5 roku a mj. jsem předtím ve Widnows strávil dva roky programováním v Javě v Eclipse. Dobře tedy vím, co je to silné IDE a v něm integrovaná podpora verzovacího systému :-) Zjistil jsem ale, že unixový styl práce mi vyhovuje víc a byl to pro mě hlavní důvod změny operačního systému.

Ladislav Prskavec (Čt, 2009-08-06 12:16):

ad @abtris) k tomu memu prispevku o zhyckanosti

Nemyslel jsem tolik CLI vs TSVN, ale spis ze ti nestaci GUI klient (Eclipse, Netbeans, THG,…) s kterymi celkem myslim lidi vystaci.

TSVN je pekny, ale kdyz jsem presel s Win na Linux tak mi nedelalo problem misto nej pouzivat Subversive v Zend Studiu.

Borek (Čt, 2009-08-06 13:03):

Díky za doplnění, aktualizoval jsem článek.

Petr (Čt, 2009-08-06 15:30):

Myslím, že je to hodně o tom, za jak dlouho se nástroj naučím.

Pokud nainstaluji GUI, bývá to hodně intuitivní. V CLI si o tom musím většinou něco přečíst, chvilku si s tím „hrát“. Pokud CLI používám dlouho začnu být podobně efektivní jako s GUI a někdy asi i rychlejší, většinou to však nevynahradí čas strávený pokusy/učením se syntaxe. Navíc pokud začnu s gui často pak mám větší představu co můžu pomocí GUI udělat.

Borek (Čt, 2009-08-06 17:23):

Dobrý pohled, poslední větě sice úplně nerozumím, ale jinak souhlasím.

Aleš Roubíček (Čt, 2009-08-06 17:26):

Stejně bysis měl něco otom nejdřív přečíst, než začnes používat GUI ;)

Petr (Pá, 2009-08-07 07:27):

Navíc pokud začnu s gui často pak mám větší představu co můžu pomocí CLI udělat (jak si nějakou častou úlohu třeba naskriptovat.

Jindra (Pá, 2009-08-07 15:28):

GUI = kouknu a vidim – tak na tohle vetsinou narazim. Autor GUI ma za ukol zkratit popis nejake „option“ tak aby se vesel do GUI a bohuzel se vetsinou trefi do neceho cemu pak ostatni nerozumi. Pro me je proto jednodussi pouzit „hg help“ apod. kde si prectu celou vetu nebo odstavec o tom co ten ktery option dela. Kazdemu vyhovuje neco jineho. Je to o zvyku, cele srovnani je naprosto subjektivni, podobne jako kdyz RH srovnava telefony/OS/cokoli…

Franta (St, 2009-09-30 00:44):

Taky jsem si kdysi myslel, že se bez GUI neobejdu, tehdy (to už je dávno), jsem byl ještě na Windows a používal Subversion, TortoiseSVN a později SmartSVN (BTW: to je pěkný klient a používám ho občas i dodnes), o nějakých distribuovaných systémech jsem ani moc netušil.

No a pak jsem začal s Mercurialem, to už bylo po přechodu na Linux, a zjistil jsem, že mi to GUI ani nechybí (a to jsem jinak dost „klikací“). „Diff“ mi dělají Netbeansy (tedy GUI), jelikož rozdíly v textovém režimu ani moc přehledně vyjádřit nejde. Ale commity a takové rychlé kouknutí, co se změnilo, dělám téměř výhradně v konsoli (i když ta linuxová je o několik řádů výše než ta ve widlích, tak je to trochu nerovná soutěž :-)).

Celá tahle diskuse mi přijde trochu žabomyší válka. Základem by mělo být, položit si otázku: „Potřebuji distribuovaný verzovací systém?“. U většiny komerčních projektů a projektíků potřeba opravdu není a vítězí zde Subversion se svojí jednoduchostí (není potřeba lidem vysvětlovat že mají dělat commit a pak ještě push, nebudou zmatení z toho, že u sebe mají commitnutou verzi a ostatní mezi tím nic netuší a přepisují ještě tu starou) a se svými GUI nástroji (TortoiseSVN, SmartSVN), nezanedbatelná je taky podpora v IDE (Např. Netbeansy mají svn, hg, cvs, clearcase). Zatímco distribuované systémy najdou uplatnění hlavně velkých projektů a u opensourcu (můžeš si snadno udržovat vlastní „fork“ a průběžně ho slučovat se změnami z hlavní větve), nebo tam, kde oceníš offline práci (možnost commitování, prohlížení historie, vracení se, i bez připojení na hlavní server), výhoda je taky v tom, že se data jen tak neztratí (všechno i s historií verzí je zálohované u všech vývojářů, takže o data prakticky nejde přijít). Měl jsem tu čest pracovat se svn, hg, p4 a gitem – P4 je sice placený, ale dělalo se mi s ním nejhůř, nejlepší práce mi přišla s hg a pak se svn (když není potřeba dvcs), git je téměř totožný s mercurialem, ale moc mi nesednul.

P.S. na subversionu mi taky leze krkem, že vytváří ve všech adresářích „.svn“, což je někdy dost problém, už jen kvůli tomu někdy používám mercurial, protože ten si udělá „.hg“ jen v kořenovém adresáři a zbytek jsou čistá data.

P.P.S. (po náhledu) fuj to je ale dlouhý příspěvek :-)

Komentáře jsou uzavřeny (blog je v read-only módu). Pokud mě chcete kontaktovat, můžete mailem.