Distribuované verzovací systémy – úvod (2)

27. 1. 2011 | František Kučera | Programování | 7005×

Pokračujeme v úvodu do distribuovaných verzovacích systémů. Ve zkratce si představíme hlavní zástupce DVCS.

Obsah

• Více scénářů práce
• Dnes používané DVCS
  • Mercurial
  • Git
  • Bazaar
• Jak si vybrat verzovací systém
• Závěr

Více scénářů práce

U distribuovaných systémů se nemusíme omezovat na klasické uspořádání server-klienti, ale pravděpodobně s ním stejně začneme:

Vzdálené úložiště bude společný server a každý vývojář bude mít na svém počítači místní úložiště (kompletní historie změn bude uložena v adresáři .hg, .git nebo .bzr případně jiném podle použitého systému). Pracovní kopii pak tvoří soubory větve, nad kterou aktuálně vyvíjíme.

Po postoupení změn (commit) vzniká verze – sada změn (changeset) a vše se zatím odehrává na našem počítači v příslušném adresáři začínajícím tečkou. Teprve po odeslání změn (push) se naše práce objeví na serveru. Pokud jsme tedy zvyklí na Subversion a vyhovuje nám, uděláme vždy commit a hned po něm push a nic moc se pro nás nemění.

Jak jsme si ale řekli, máme i jiné možnosti. Z počítače na obrázku označeného jako „vzdálené úložiště“ můžeme třeba odesílat změny (push) na zálohovací server, nebo naopak ze zálohovacího serveru provádět pull – je jen na nás, odkud tu akci budeme chtít provádět. Kromě zálohovacího serveru můžeme mít také úložiště pro veřejnost – uživatelé tak svým stahováním nebudou zatěžovat server, na kterém pracují naši vývojáři.

Když některý vývojář zpřístupní ostatním svoje úložiště (přes SSH, HTTP, sdílený disk…), můžou si ostatní stahovat změny (pull) nebo mu naopak přispívat (push), aniž by změny musely projít přes centrální úložiště. To nakonec nemusíme mít vůbec – každý pracuje na svém a občas se synchronizují.

Scénář práce resp. uspořádání úložišť a tok změn mezi nimi si teď můžete vymyslet podle svého vkusu a fantazie. Inspirací vám budiž scénáře popisované v příručkách k jednotlivým systémům. Přičemž platí, že scénář nebo postup popisovaný u jednoho z distribuovaných systémů půjde většinou uplatnit i u jiného – takže se rozhodně nebojte podívat se ke „konkurenci“:

• Git: Any Workflow
• Git: Distributed Workflows
• Bazaar Workflows
• Mercurial: Learning Mercurial in Workflows
• Monotone: Network Service Revisited
• Darcs: Distributed development with one primary developer
• GNU Arch: Collaborating With Other People

Jedním z možných scénářů je např. „správce integrace“ – v tomto případě správce (pověřený člen týmu, zkušený vývojář) stahuje změny od jednotlivých členů, kontroluje kód a schválené změny postoupí opět do jakéhosi „centrálního“ úložiště – a z něj si členové stáhnou změny ostatních (ale sami tam zapisovat nemohou).

Dnes používané DVCS

Mercurial, Git a Bazaar tvoří asi nejznámější a nejpoužívanější trojici. Další systémy z této kategorie jsou: Monotone, Darcs, Fossil a GNU arch. Následující programy vznikly přibližně před pěti lety a mají k sobě velmi blízko – jak svojí koncepcí, tak svými kvalitami.

Mercurial

Mercurial (hg) je dílem vývojáře Matta Mackalla a společnosti Selenic. Je snadné se tento systém naučit a používat ho. Je napsaný v Pythonu (binární diff je implementovaný v jazyce C). Není problém ho provozovat na různých platformách. A k dispozici je i řada zajímavých rozšíření. Mercurial je svobodný software vydaný pod licencí GNU GPLv2.

Kdo např. používá Mercurial: Netbeans, Mozilla, GNU Octave, OpenOffice.org, Xen, Dovecot.

Git

Původním vývojářem Gitu není nikdo menší než Linus Torvalds, autor Linuxu. Dnes ho v počtu commitů do Gitu předběhli Junio C Hamano a Shawn O. Pearce. Git byl vytvořen jako náhrada proprietárního BitKeeperu, který se do té doby používal pro verzování linuxového jádra. Je napsaný v jazyce C, Bashi a Perlu. Nabízí prakticky neomezené možnosti, byť někdy za cenu trochu složitějšího ovládání. Stejně jako Mercurial je i Git licencovaný pod GNU GPLv2.

Kdo např. používá Git: Linux (jádro), Amarok, GIMP, PostgreSQL, GNOME, VLC.

Bazaar

Autorem Bazaaru (bzr) je Martin Pool a vývoj sponzoruje firma Canonical (Ubuntu). Je napsaný převážně v jazyce Python. Klade velký důraz na uživatelskou přívětivost a disponuje pěkným GUI. Stejně jako předchozí dva systémy i Bazaar je vydaný pod GNU GPLv2.

Kdo např. používá Bazaar: Ubuntu, GNU GRUB, Inkscape, Squid, Stellarium, GNU Wget.

Jak si vybrat verzovací systém

Ještě než začnete přemýšlet, který verzovací systém je ten nejlepší, je třeba si přiznat, že většinou si nebudeme moci vybírat. Když se budeme chtít zapojit do vývoje nějakého svobodného softwaru nebo se nechat někde zaměstnat, budeme se muset přizpůsobit tomu, co se v daném týmu používá. Hodí se proto umět základy každého systému (alespoň těch tří nejpoužívanějších). Základní principy jsou naštěstí dost podobné – a ten zbytek se naučíte za chodu.

Pokud jsme v roli šéfa týmu nebo samostatného vývojáře, tak si můžete vybírat prakticky libovolně. Ani zde ale nejde určit nějaký „jeden nejlepší verzovací systém“. Situace je poměrně vyrovnaná. Pravděpodobně tak pro nás nebudou až tak důležité vlastnosti systému samotného, jako spíš jeho podpora v používaném IDE, editorech, možnost integrace s dalším softwarem (správa chyb a požadavků, testování, průběžná integrace atd.), nebo znalosti a preference ostatních členů týmu.

Následující obrázek se snaží zachytit velikost pozitivních změn, přínosů plynoucích z přechodu na „vyšší“ technologii. Za nejhorší možnou formu spolupráce můžeme považovat posílání si souborů e-mailem – zde je téměř nemožné zachovat si v souborech pořádek a zároveň duševní zdraví, neustále budeme trpět např. problémy s tím, že analýza-1.2.3.xmi která přišla mailem, je „trochu novější“ soubor než analýza-1.2.3.xmi, kterou máme zrovna na disku… nebo není, ale to nikdo neví. Trochu si pomůžeme, když si přestaneme posílat e-maily a pořídíme si nějaký sdílený disk – konečně všichni vidíme ty stejné soubory a není v tom takový guláš. Ale zase se nám stane, že „Pepa něco upravoval, ale Honza tam mezitím uložil svoji verzi a Pepova práce je teď v čudu“ a podobné nepříjemnosti.

Největší pokrok uděláme, když zavedeme verzovací systém – a to jakýkoli. Odpustíme protentokrát posměšné komentáře, jak je ten Subversion hloupý, nebo ten CVS nemožně zastaralý – i tyto systémy nám výrazně pomůžou a ušetří práci. V některých týmech se CVS používá dodnes a jsou za něj rádi.

Dalšího poměrně velkého pokroku dosáhneme přechodem od centralizovaných verzovacích systémů k těm distribuovaným. Změnou v rámci této skupiny si už pomůžeme minimálně nebo vůbec – takže hádat se, zda je lepší to či ono je celkem zbytečné. Ať už si vyberete Mercurial, Git nebo třeba Bazaar, neuděláte chybu. Nesmíme zapomínat na to, že tyto systémy jsou v první řadě nástrojem, nikoli cílem našeho snažení – tím je vývoj softwaru případně jiná činnost.

Navíc výběr verzovacího systému není nic jako „manželství na celý život“ – máme poměrně dobré možnosti konverze mezi jednotlivými systémy. Např. pomocí příkazu:

$ hg convert pokus123

vytvoříme z gitovského projektu pokus123 projekt v Mercurialu (vznikne nám nová složka pokus123-hg), a to včetně všech větví (branches) a štítků (tags). Připravit se o historii naší práce je tedy zcela zbytečné (totéž platí i pro přechod z centralizovaných VCS). Vždy je dobré konvertovat staré úložiště a ne jen zkopírovat poslední verzi do toho nového.

Závěr

Dnes jsme se seznámili s obecnými vlasnostmi distribuovaných verzovacích systémů a uvedli si pár důvodů, proč je používat místo těch centralizovaných. Po tomto teoretickém úvodu se v následujících dílech seriálu podíváme podrobněji na jednotlivé systémy (příště Mercurial a v dalších dílech přijde řada na Git a Bazaar), povíme si o jejich odlišnostech a ukážeme si praktické používání.

       

Komentáře

[Max]

Pěkný článek, maximální souhlas.
Zdar Max

[Marián Kyral]

K těm Git projektům bych přihodil KDE. Migrace právě probíhá.

[alblaho]

Mě fascinoval subversionový repozitář KDE - vše v jednom. Mám pocit, že to dotáhli snad na miliardu revizí.

Přínos distribuovaných verzovacích systémů je pochopitelně největší pro distribuované projekty. Hlavně jde o to, že není potřeba vymýšlet, kdo dostane právo zápisu a kdo ne. Linus přetahuje stromy od deseti lidí, kterým absolutně věří. A každý s těch deseti má zase svoji skupinu dodavatelů.

[Ladicek]

V ASF jsou na tom podobně. Teda nejsou u miliardy, jenom u miliónu

[Sten]

Kdepak, jenom na něco přes milion. Těžko říct, jestli by SVN miliardu revizí zvládlo. Jinak na git se sice migruje, ale naprostá většina práce se stále děje v SVN.

[Jakub Suchy]

+ Drupal.

Kompletni drupal.org s jadrem a ostatnimi 7500 projekty prechazi na Git.

[pet]

Díky a netrpělivě čekám na pokračování. Budeme přecházet z CVS a CrossVC na něco distribuovaného, předpokládal jsem Git, ale po dnešku je možné, že vyberu ze "svaté trojice" něco jiného s lepším gui

Ještě jednou díky

[Sten]

Přesně tak, mám repozitář v gitu, ale v tomto článku mě více zaujal Bazaar, tak třeba zmigruju.

[pavlix]

Bazaar chce hodně rychlý stroj i na středně velké projekty.

[vencas]

Nevím kdy jste to naposled zkoušel, ale mě funguje bez problémů na starších počítačích (je-li středně velký projekt 100k řádek a 3k revizí). Ve výkonu udělal bazaar hodně velký skok asi před rokem a teď mi přijde skvělý.

[pavlix]

Nevím kdy jste to naposled zkoušel, ale mě funguje bez problémů na starších počítačích (je-li středně velký projekt 100k řádek a 3k revizí). Ve výkonu udělal bazaar hodně velký skok asi před rokem a teď mi přijde skvělý.

Nezkoušel jsem ho několik let, protože už byl Git, takže asi tak. Každopádně díky za informaci.

[mimi.vx]

good clanek , ale jeste mi chybi info o DARCS

[polymorf]

Aky verzovaci system by ste doporucili na usb flash disk? Z dovodu ze nemam/nechcem tieto subory prenasat cez siet. Co som pozeral tak vacsina VCS robi strasne velke mnozstvo suborov, uz sa mi napr. stalo ze sa na usb flash disk nedalo do jedneho adresara dat viac ako 512 suborov. S tym ze by to malo byt multiplatformne (linux, windows).

[Josef Kufner]

Git si dává jen .git do kořene repositáře.

[Gilhad]

ale pod tím .git má spoustu podadresářů a souborů...

Nicméně pokud bych já dával verzování na USB disk, tak bych ho taky naformátoval na nějaký rozumný FS, třeba ext2, rozhodně ne na FAT.

[mirec]

Ak nevadí zahodenie nepoužívaných objektov tak celkom služne počet súborov zredukuje dvojica:

git prune --expire all
git gc --aggressive --prune

[mimi.vx]

git i mercurial jedou bez problemu i na widlich .... m ale na usb flash bych nedaval nic duleziteho ..., a pozor co to ma za verzi fat ... omezeni na 512 souboru odpovida tak fat16:)

[Foo Bar]

Stačilo ten USB přeformátovat alespoň na FAT32 a pak si vyberte takový verzovací systém, který bude lehký na IO operace, aby Vám ten disk vydržel.

[jos]

pokud de jen o přenášení rapository a ne o vývoj nad pracovní kopií na tý flašce, tak v mercurialu bych to řešil takhle:

hg bundle --all /mnt/flash

vyrobí to jeden soubor

věřim, že i git a bazar budou mít něco podobnýho

[pavlix]

Minimálně git bundle k dispozici je.

[polymorf]

USB kluc sluzi len na prenasanie, nakoniec to asi spravim tak ze budem working copy balit. Bud pomocou toho bundle alebo obycajny tar.gz + este to ccryptom zakodujem.

[jos]

při takovýmhle použití:

hg bundle --base <changeset> /cesta/k/usb

se nabundlujou jen revize od <changeset> a AFAIK sou informace v bundlu k ničemu bez repository obsahujícího <changeset>, takže možná kryptování ani není nutný

[Petr Tomášek]

Subversion

[pavlix]

Jasně, jako na všechno :).

[Sten]

Na flash disk bych nedával verzovací systém, který by jej zvládl poměrně rychle oddělat, ale spíše verzovaný souborový systém, třeba LogFS nebo UDF s media-type WORM.

[Foo Bar]

Doporučuji na tom "svém" projektu vyzkoušet rychlost běžných operací. Má zkušenost z Debianího balíčkování je taková, že git je pekelně rychlý a hg ukrutně pomalé (konkrétně na google-go repozitářem).

Mercurial má problémy s většími soubory (a plusem je, že to oficiálně přiznává): http://mercurial.selenic.com/wiki/HandlingLargeFiles

[mimi.vx]

jak v cem ... gentoo jeste nepreslo z cvs na git protoze checkout portage pro 1 developera proste server nezvladl ... 16giga ram na 1 kompletni ceckout bylo proste malo ..

[alblaho]

To je docela zajímavé.

Git dle mých zkušeností je pekelně rychlý, aspoň oproti Bazaaru. Ale když jsem si checkoutnul Linux kernel, tak na mém noťasu s 1G RAM bylo třeba zobrazení kompletního logu dost pomalé. Zajímalo by mě, jak by to fungovalo s CVS, ale asi dobře, protože tam se verzuje každý soubor zvlášť + tagy.

[pavlix]

Zajímalo by mě, jak by to fungovalo s CVS, ale asi dobře, protože tam se verzuje každý soubor zvlášť + tagy.

Hádal bych, že log pak musí být zákonitě daleko pomalejší než v gitu, právě proto, že jsou commit objekty dost minimalistické. Z jiných důvodů možná, ale z tohoto bych řekl, že by měl vyjít opačný výsledek.

[Foo Bar]

Čistý checkout linusova stromu... $ time git log > /dev/null

real 0m5.937s user 0m5.670s sys 0m0.250s

Ale je pravda, že ten stroj má 8GB paměti a čtyři jádra.

[pavlix]

jak v cem ... gentoo jeste nepreslo z cvs na git protoze checkout portage pro 1 developera proste server nezvladl ... 16giga ram na 1 kompletni ceckout bylo proste malo ..

Otázka je, proč to ten vývojář checkoval do RAM :).

[Marián Kyral]

Těch 16GB nestačilo na serveru. To nemá s vývojářem nic společného.

[pavlix]

Těch 16GB nestačilo na serveru. To nemá s vývojářem nic společného.

Můj osobní odhad je, že 16GB RAM na serveru k tomu checkoutu zdaleka nebylo potřeba. A chyba bude někde jinde, ať už v dezinformaci nebo že těch 16GB RAM nestačilo úplně něčemu jinému.

Ono si to stačí představit, checkout od serverou vyžaduje pouze vydání všech packů, jednoho po druhém. Tzn pokud ten server zvládne ty packy nabídnout přes SCP/FTP/whatever, celkem logicky zvládnout i přes Git. Je to jen odesílání souborů přes buffer.

[Gilhad]

Mam ted git-server na uzasnem stroji - wifi-router od linksysu pod OpenWrt, 4MB disk, 16 MB RAM a s pridanou 4GB kartou jako diskem ovladana diodama - takze kazda vetsi aktivita je fakt videt. Kdyz si stahuju cokoli, tak se rozzari jak vanocni stromecek a vsechny ty veci nejdriv spocita, pak komprimuje a posila, nicmene zvlada. Ale u nejakeho mega projektu, kdyby si to chtel vsechno nejdriv nasyslit do pameti ... ale zase tak hloupy snad neni ...

[pavlix]

Zkus si to stáhnout v zápětí z jiného místa znovu :). Porovnávání a repacking nějakou tu ramku určitě zabere, detaily neznám.

[jos]

pomalost mercurialu je daň za to, že je to v Pythonu, třeba by se při použití Psyco nebo Cython poměr změnil

[pavlix]

Změnil ve smyslu zmírnil, víc bych od toho nečekal.

[jos]

takhle sem to myslel, dík za upřesnění

[Heron]

SVN repositář o velikosti 30GB už taký není zrovna rychlík. Tohle je dobrá informace (Mercurialu se musí soubor vejít do RAM+overhead). Díky.

[polymorf]

Dve otazky na grafickych klientov.

Bazar

- tam dole je biely zapisnicek s ceruzkou, proste edit polozky na ktorej stojim. Existuje na to nejaka klavesova skratka? Enter robi to ze to spusti, co napr. pri html otvori v prehliadaci. Ja to potrebujem editovat.

TortoiseHG

- jakym sposobom sa daju zobrazit adresare stromovou strukturou, teraz je vsetko v jednom, proste obrovsky list s asi 5000 subormi, absolutne sa v tom neda orientovat.

Vdaka.

[vulgární Nick]

... V některých týmech se CVS používá dodnes a jsou za něj rádi. ...

Vyznívá mi to, jako by CVS mělo být něco raritního. Přitom nemálo organizací CVS normálně používá a neberou to jako výrazný handicap (resp. to považují za nejlepší řešení). Ono to má několik důvodů.

Zaprvé to je konzervatismus (klidně můžeme říct zkostnatělost) - zejména u větších organizací spravujících mnoho projektů je strach z negativních dopadů změn velký. A oprávněný.

Zadruhé jsou to časové kapacity uživatelů. Projektů je hodně, často se nestíhá a zkrátka nebývá čas, aby se uživatelé učili něco nového (relativně nepotřebného), i kdyby to v konečném důsledku bylo zlepšení.

Zatřetí jsou zde pragmatické důvody - starší VCS jako CVS mají širokou podporu jiných nástrojů (IDE atd.), kterou poměrně mladé projekty typu Git prostě nemají (nebo mají, ale méně kvalitní).

Čtvrtým důvodem jsou problémy při spolupráci několika organizací. Obě organizace používají třeba CVS, protože ho používá i ta druhá. Aby jedna přešla na něco jiného, musela by se akceptovat rizika popsaná výše a navíc by to samé musela udělat i ta druhá, takže by se to celé muselo organizačně zastřešit, což opět vyžaduje finance... Do výpočtu pravděpodobnosti takové změny tedy vstupuje ochota jedné organizace, ochota druhé a ochota obou (nebo více) to koordinovat.

Vyjmenoval jsem několik důvodů, co mě hned napadly, ale ve skutečnosti je jich daleko víc. Na CVS mě s*re několik věcí (a to jsem jen uživatel, nikoli admin), ale rozumím důvodům, proč u něj zůstat.

Zavádět jiné VCS je snažší (nikoli snadné!) u vznikajících projektů než provádět změnu u starých - to bývá často cesta do p*dele.

[vulgární Nick]

On třeba ten Git vznikl v půlce roku 2005. Tak rok hrozilo nebezpečí závažných chyb v důsledku chabého testování v reálném provozu. Další rok se začal používat na menší (domácí, amatérské) projekty. To už máme 2007. Řekněme dva roky trvalo, než měl jakous-takous podporu integrace s jinými nástroji. To je rok 2009. Někdy v roce 2010 ho začaly občas nasazovat i větší organizace.

Tzn. od půlky roku 2010 se může začít uvažovat o nasazení v průměrné větší komerční organizaci; samotné uvažování může trvat půl roku, rok. Další půl roku nebo rok se to může v rámci organizace zkoušet. Až pak se mohou řešit body zmíněné v komentáři výše...

Samozřejmě mluvím o průměrné organizaci (nebo minimálně o takové, o níž si myslím, že je průměrná). Některá společnost může přejít rychle třeba proto, že má prachy, jiná proto, že výhody Gitu nutně potřebuje atd.

[Gilhad]

Mezi gitem a cvs je jeste mezikrok subversion. Ale jinak mi prijde, ze jsi tutez vetu opsal podstatne vice slovy.

cvs je zastarale, neohrabane a zavedene. Funguje porad stejne, kdyz je na nej naveseno milion veci a neni cas, tak prechod na neco novejsiho a ohrabanejsiho muze byt tak bolestivy, ze se u stavajicich projektu nevyplati. Takze jsou radi za to co maji i se vsema nevyhodama, protoze nemaji cas a prostredky prejit na neco jineho, co by jim mozna pomohlo vic, ale musel by to nekdo zaplatit a musel by se na to vyhradit cas ktery neni.

Coz stejne nemeni nic na tom, ze cvs je zastarale a neohrabane a stejne tak to nemeni nic na tom, ze pro nekoho se prechod na lepsi nevyplati a tak je rad za to co ma.

[vulgární Nick]

Mezi gitem a cvs je jeste mezikrok subversion.

Jenže mezi CVS a třeba Gitem je prakticky stejný rozdíl jako mezi SVN a Gitem. Jinými slovy: rozdíl mezi CVS a SVN je velmi malý - z pohledu problémů popsaných výše, ale i obecně.

Co do běžného užívání je SVN skoro stejné jako CVS. SVN beru jako CVS, které pár věcí řeší lépe, ale pořád velmi, velmi podobně jako CVS. Nástroje DVCS by ideálně (chce-li člověk čerpat jejich výhody) měly být používány diametrálně odlišně. Jasně, i DVCS lze většinou používat úplně stejně jako CVS nebo SVN, ale pak je zde otázka, proč na ně vůbec přecházet...

Z důvodu podobnosti s CVS se SVN (vzniklé kolem r. 2000) uchytilo poměrně rychle. Ale i tak to nebyla otázka krátké doby, pořád se bavíme o jednotkách let.

Nechci jmenovat, ale např. jedna poměrně slušná česko-slovenská organizace (vývojářská firma, asi 300 lidí) používá v největší míře CVS a pomalinku teď začíná používat SVN - pro některé nové projekty... A jsou docela spokojeni.

Ale jinak mi prijde, ze jsi tutez vetu opsal podstatne vice slovy.

Vždyť i vy jste můj komentář jen přepsal do jiné formy. ;)

[jos]

jenže od dob CVS/SVN už má každej moula notebook, takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

[vulgární Nick]

jenže od dob CVS/SVN už má každej moula notebook

Nevím, s mouly se příliš nestýkám... Ale ani obecně bych netvrdil, že všichni uživatelé VCS (nebo i jen jejich většina) je v tomto smyslu mobilní.

takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

No jasně! Vždyť já taky preferuju DVCS... Nahoře jsem jen zmínil důvody, které brání jeho rychlému nasazení u určitého typu organizací. U projektů, které vyvíjím sám (a jsou nekomerční), můžu střídat VCS třeba každý měsíc.

[pavlix]

Nevím, s mouly se příliš nestýkám... Ale ani obecně bych netvrdil, že všichni uživatelé VCS (nebo i jen jejich většina) je v tomto smyslu mobilní.

Oni nemusí být mobilní, bohatě stačí, když si admin hraje se sítí :). Jinak homeworking je už dneska taky docela rozšířený. Takže výpadky domácí sítě, či jakýkoli problém s VPN, nebo třeba jen expirované heslo... těch případů, kdy se DVCS hodí i na centralizovanou práci je spousta.

[vulgární Nick]

Prosím vás, nic mi nevysvětlujte. Mě se týká homeworking, notebook a občas (velmi zřídka, ale přece) i ty problémy se sítí. Já moc dobře vím, proč volím DVCS.

[pavlix]

To bych si nedovolil, pouze doplňuju, že ta mobilita není potřeba :), aby se výhody projevily. Když ne pro vás, tak pro ostatní.

[vulgární Nick]

OK.

[jos]

tak vypada to ze si vsichni rozumime, tak prihodim jednu historku k dobru:

kolegove meli delat upravy na projektu do te doby nijak neverzovanem (rozumej verzovanem na filesystemu ... ehm); sve zmeny zacali verzovat v mercurialu, nacez prisel jeden jouda (vazeny dlouholety zamestnanec, pravdepodobne odkojeny na CVS/SVN), kteremu se myslenka DVCS nelibila, a nakonec historie kterou vytvorili skoncila konverzi na SVN (!!!)

co si pamatuju, tak jedine jeho argumenty byly "vetsi narcnost pro adminy kvuli zalohovani" - AFAIK zalohujeme cele filesystemy inkrementalne - a "kdo s tim bude chtit delat se to musi naucit, coz je strasny problem" - jednak kazdy druhy clovek ktereho do firmy bereme nevi o VCS ani prd (i ja mezi ne patril), druhak programator ktery nejde/nechce jit dopredu je bezcenny

a to ten clovek jeste pry tvrdil, ze kdyby dopredu vedel o konverzi repository projektu na kterym makam, tak by to prej zarazil, pricemz sme outsourceovany jinam, firemni adminy to nema sanci zatezovat a s prechodem na hg v teamu nikdo nemel problem

prechodu na lepsi technologie obvykle brani:

zkorumpovani lide (to asi neni pripad verzovacich systemu)

IT aware zpatecnicti idioti (jako ten z me historky)

IT nevzdelani manageri

ostatni idioti

[vulgární Nick]

prechodu na lepsi technologie obvykle brani: ... idioti

Nasazení tzv. lepších technologií je investice jako každá jiná. Může z ní plynout zisk, ale taky nese rizika, která mohou způsobit ztrátu. Někdy rizika hrozí víc, jindy míň a někdy se riskuje pořádný balík a jindy zase pakatel.

Je na každém manažerovi, jak se k investici postaví. Někdo je opatrný investor, jiný riskuje.

Pokud se někdo v určitou chvíli brání těm tzv. lepším technologiím, nutně to neznamená, že je dotyčný debil.

Ano, byly doby, kdy jsem to viděl tak, že teď se prostě všichni sebereme a, hurá, nasadíme něco lepšího než to starobylé CVS. Když jsem byl odmítnut ("Bude se o tom jednat - někdy."), bral jsem to jako velkou hloupost "těch nahoře". Jenže jak jsem začal řešit i jiné problémy než čistě technické (např. organizační apod.), zjistil jsem, že opatrný postoj těch, co mě tehdy odmítli, je rozumný a daný zkušenostmi.

[jos]

de hlavně o to jak to prodat, což bez zkušeností odjinud je dost tězký

ty idioti co sem o nich psal ale neslyší na sebelepší poměr +/- a vymejšlejí co nejvíc lživých výmluv (evergreen na kterej tu a tam narazim je, že s DVCS nic nenutí vývojáře pushovat změny často, což a) je nesmysl b) s DVCS to nijak nesouvisí)

v našem teamu sme nemuseli jít proti větru, prostě se jeden člen zaúkoloval že nám předvede mercurial; všem se to líbilo a dokonce to některý lidi (třeba mě) naučilo používat commandlajnu místo nějakejch pomalejch TortoiseWhatever GUI

[pavlix]

jenže od dob CVS/SVN už má každej moula notebook, takže s DVCS můžu čerpat výhody i když budu vyvíjet projekt sám a dostanu se s notebookem kamsi do offlajnu

My, co jezdíme hodně vlakem na pracovní cesty, to oceníme nejvíc :).

[jos]

jeden muj dojizdejici kolega za casu kdy sme jeste pouzivali svn resil cesty vlakem tim, ze mel <ksakru-ted-si-nevzpomenu::proste-nejakou-VCSnaprd(nedistribuovaneVCS).to.SVN-uchylarnu> a taky si chvili povystacil

pak se zacal rozhlizet jak to udelat bez uchylaren, GIT na widlich tou dobou nejel, o bazaru prohlasil, ze to ma vic prikazu na restore rozbityho repository nez na opravdovou praci, takze s mercurialem stastne zijem doted

[jos]

tak sem se ho zeptal a bylo to SVK

[Bilbo]

Tak např. s gitem lze tohle provádět i nad SVN:

git-svn clone vytvoří v gitu kopii SVN repozitáře (včetně logu a historie)

git-svn fetch dotahá z SVN nové revize (asi jako GIT pull)

Nad tím můžu pak pracovat offline jako s gitem (rebase, vytvářet branche, atd ...)

git-svn dcommit pak docpe moje commity jeden po druhém do SVN

Něco podobného má git i pro CVS.

[----]

no, co se týče různých neduhů, tak jsou si CVS a SVN podobné, nicméně SVN má o dost jednodušší a komfortnější interface; na menší projekty se hodí perfektně; tam, kde je ale potřeba pokročilejší branching apod, tak je Git daleko lepší volba.

[pavlix]

A může být v době Gitu vůbec nějaký důvod použít SVN v novém projektu, kde není použití SVN dané historicky?

[Emalf]

WebDAV (automatické verzování bez další práce a bastlení), zamykání souborů, řízení práv (a ověření autorů commitů), podpora v IDE a dalších programech…

(což tedy neznamená, že by Subversion byl obecně lepší než dnešní DVCS, ale fakt, že v některých případech může mít smysl si ho vybrat – i dnes)

[pavlix]

WebDAV (automatické verzování bez další práce a bastlení), zamykání souborů, řízení práv (a ověření autorů commitů), podpora v IDE a dalších programech…

(což tedy neznamená, že by Subversion byl obecně lepší než dnešní DVCS, ale fakt, že v některých případech může mít smysl si ho vybrat – i dnes)

Jestli ty důvody byly před dvěma lety významné před rokem aktuální a dnes ještě jakž takž... tak pokud budu pro nový projet vybírat něco, co se má používat příštích 10 let... SVN to nebude.

Spojení WebDAV a VCS mi obecně nezní jako dobrý nápad.

Ale za uvedení důvodů každopádně děkuju, zajímá mě to.

[YYY]

Osobne si vystacim se svym centralizovanym verzovacim systemem, ktery je tak jednoduchy, jak jen verzovaci system muze byt - bash only.

[pavlix]

A co je na něm tak centralizovaného (pokud máš nainstalováno SCP či rsync)? :)

[YYY]

Libi se mi na nem to, ze verzuje tak, jak si to predstavuji ja. Samozrejme kdybych pouzil treba svn, tak by to take slo, ale nebyla by to pro mne takova zabava. :)

[pavlix]

Libi se mi na nem to, ze verzuje tak, jak si to predstavuji ja.

Zeptám se tedy ještě jednou :).

A co je na něm tak centralizovaného (pokud máš nainstalováno SCP či rsync)?

Nebo jinak... z čeho usuzuješ, že tvé řešení je centralizované?

[Josef Kufner]

Problém je, že (minimální) složitosti se nezbavíš, jen ji můžeš přesunout. Takže oč je tvůj verzovací systém jednodužší, o to víc se nadřeš.

[YYY]

To mate pravdu. Ale je to na celkem unosne mire.

[pavlix]

Já si pamatuju, že verzovací systém v bashi byl jednou z běžných zkouškových úloh na nějaké 3-4 hodiny :). Měl mít nějaké základný tři příkazy, tuším.

[----]

osobně používám Git na Githubu pro správu vlastního kódu; je to dobrý, kromě těch případů, kdy se chce zapojit nějaký developer a je na Windows. Potom nastavování klíčů a propojení s githubem je pro většinu těžší, klasický linuxový kommandlajnový klient funguje perfektně.

[pavlix]

Potom nastavování klíčů a propojení s githubem je pro většinu těžší, klasický linuxový kommandlajnový klient funguje perfektně.

Nastavování klíčů kvůli mě už zvládl i nějaký ten neprogramátor (než aby poslouchal vysvětlování, proč nechci FTP ani SFTP s hesly).

Programátor by s tím neměl mít (s návodem) jediný problém.

Jinak s klíči mívají lidé problém i na Linuxu, ale z toho bych spíše vinil chybějící UI a to nejlépe alespoň CLI a GUI, zatím jsem neviděl ve slušné kvalitě ani jedno.

[----]

no, co jsem to pomáhal nastavit některým lidem, tak s tím měli problém. Osobně nevím, protože nejsem vůbec na Windows, ale ..

[xkucf03]

Na použití SSH klíčů pod Windows jsem kdysi psal návod, ale stejně to nikdy nebude tak pohodlné jako v Linuxu/Unixu.

[pavlix]

Já doufám, že to jednou bude pohodlné aspoň na Linuxu/Unixu. Ale popravdě není žádný technický důvod, aby to bylo ve Windows méně pohodlné.

[pavlix]

Já zjišťuju, hlavně na linuxových školeních, že SSH má na Linuxu tak blbé (nebo spíše skoro žádné) uživatelské nástroje, že na školení práce s klíči pro SSH zabírá neúměrně mnoho času... a velkou část toho času trávím vysvětlováním, proč to nefunguje tak, jak by lidi očekávali.

Nicméně, abych jenom nenadával, už dlouho uvažuju, že zkusím napsat pár nástrojů, které to budou řešit. Ale těžko říct kdy, a pokud mě někdo předběhne (či odkáže na někoho, kdo už mě dávno předběhl), budu jenom rád.

[Jendа]

Co je na tom z uživatelského hlediska tak nepříjemného? Většinou stačí ssh-keygen (haló, BSA, používám keygen!!!), dvakrát entr a pak zkopírovat výsledek z ~/.ssh/id_*.pub.

Jinak nějakou správu (i) SSH klíčů umí Seahorse.

[xkucf03]

+1 taky mi přijde, že na tom není nic těžkého. A se Seahorsem zvládne generování klíčů i opravdová lama (a je to přímočařejší než s tím Putty ve Windows).

Ad patička: gratuluji

[pavlix]

aky mi přijde, že na tom není nic těžkého. A se Seahorsem zvládne generování klíčů i opravdová lama (a je to přímočařejší než s tím Putty ve Windows).

Z čeho tedy usuzuješ, že Seahorse nebo ekvivalent nepůjde nikdy používat na Windows?

[Jakub Lucký]

gratuluješ k zveřejnění studijních výsledků jiných studentů? :-P

[xkucf03]

Počítám, že to visí někde na nástěnce, takže je to celkem jedno. Např. u nás ve škole jsme dávali nějaký souhlas, že chceme být případně uvedeni na žebříčku nejlepších studentů (když někdo nechtěl, tak tam pak u výsledku chybělo jméno). Ale jinak ta gratulace byla k 1.

[Jakub Lucký]

Já to pochopil... Jen mě ty další výsledky zarazili...

[Jendа]

Zarazily. Visí to na veřejně přístupné nástěnce, tak co. Spíš mě zarazilo, že v TOP 30 (ze 118, z toho 30 sportovců (A) a 30 polosportovců (B)) bylo i 2,25. Jde to doprčic.

[Jendа]

Zamazáno. Už po mně jde ÚOOÚ?

[pavlix]

Co je na tom z uživatelského hlediska tak nepříjemného? Většinou stačí ssh-keygen (haló, BSA, používám keygen!!!), dvakrát entr a pak zkopírovat výsledek z ~/.ssh/id_*.pub.

Vidíš, že se umíš nejen hezky zeptat, ale i si sám odpovědět. A aby toho nebylo málo, tak to ještě často nestačí (např. oprávnění).

Ani to kopírování není pro začátečníka (ani začínajícího admina) zrovna jednoduchý.

[Jendа]

např. oprávnění

To mají snad všechny distribuce defaultně dobře a člověk to musí ručně rozbít, aby to nefungovalo.

A jak by sis to představoval ty?

[pavlix]

1) Aby uživatel použij jednoduchý nástroj k exportování klíče.

2) Aby administrátor použil jednoduchý nástroj k importování klíče.

3) Aby administrátor použil jednoduchý nástroj k přiřazení klíčů uživatelům.

4) Aby uživatel mohl své klíče nadále spravovat nástrojem, který ho od přihlášení neodřízne.

To vše ideálně v provedení CLI a GUI, za dodržení dalších běžných podmínek, dobré úrovně bezpečnosti a decentralizace.

Vím, že je to hodně požadavků, ale splnitelné jsou všechny.

[pavlix]

Pozor, ještě ještě jedna důležitá věc, aby to vše fungovalo za všech okolností, které dávají smysl. Tedy mimo jiné nezávisle na tom, jestli byl nebo nebyl spuštěn SSH agent, jestli se používá nebo nepoužívá passphrase, atd.

[pavlix]

A ještě jedna drobnost, mělo by tam jít spravovat veškeré klientské nastavení SSH, tedy minimálně authorized_keys včetně omezení pro jednotlivé klíče, known_hosts a config.

[xkucf03]

Ani to kopírování není pro začátečníka (ani začínajícího admina) zrovna jednoduchý.

Na to je příkaz ssh-copy-id.

[pavlix]

Na to je příkaz ssh-copy-id.

Který nefunguje (až na některé speciální případy).

[xkucf03]

Můžeš být konkrétnější? Mně zatím vždycky fungoval.

[pavlix]

Protože jsi ho používal jen na to, co umí :) podívej se o vlákno výš a budeš mít jasno.

[pavlix]

Nehledě na to, že učit to začátečníky přes soubory je snad ještě míň bezpečný, než jim privátní klíče generovat centrálně :D.