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

25. 1. 2011 | František Kučera | Programování | 14493×

Verzovací systémy jsou jedním z nejdůležitějších vývojářských nástrojů a užitečné mohou být i jinde. V současné době jsou v módě distribuované verzovací systémy – nejprve se na ně tedy podíváme teoreticky a v dalších dílech se budeme věnovat prakticky jednotlivým implementacím.

Obsah

• Trocha historie
• Co jsou verzovací systémy a k čemu jsou dobré
• Proč distribuované verzovací systémy

Trocha historie

Systémy pro správu verzí (VCS) nejsou v oboru softwarového inženýrství žádnou novinkou. Už na přelomu 70. a 80. let se používalo SCCS pocházející z Bellových laboratoří, na které navázalo GNU RCS, jehož autorem je Walter F. Tichy z Purdue University. Později si vývojáři oblíbili CVS, jehož historie sahá do června 1986, kdy Dick Grune poslal do diskusní skupiny comp.sources.unix sadu shellových skriptů. Ačkoliv CVS v aktuální verzi tyto zdrojové kódy neobsahuje, používá z nich některé algoritmy. V roce 1989 Brian Berliner navrhl a napsal systém CVS a později se k němu připojil Jeff Polk.

Začátkem 21. století se rozšířil zejména systém Subversion (SVN). Počátky jeho historie sahají do roku 2000, kdy firma CollabNet začala shánět vývojáře pro komponentu svého produktu CEE týkající se správy verzí. CollabNet Enterprise Edition (CEE) dříve využíval systém CVS. Ten se firma rozhodla nahradit a vyvinula tak zcela nový program – Subversion. Kontaktovali CVS konsultanta a autora knihy Open Source Development with CVS Karla Fogela a jeho kamaráda Jim Blandyho, kteří souhlasili se spoluprací na projektu. Dále se zapojili Ben Collins-Sussman, Brian Behlendorf, Jason Robbins a Greg Stein. V květnu roku 2000 začala detailní analýza a po čtrnácti měsících implementace (31. srpna 2001) se stal Subversion použitelným a vývojáři mu svěřili správu zdrojových kódů samotného Subversionu místo CVS. Což můžeme považovat za důkaz dospělosti systému, podobně jako u kompilátorů, které jsou kompilovány samy sebou.

Zatímco se Subversion šíří do praxe a nahrazuje v té době už mírně zastaralé CVS, začíná se pracovat na nových verzovacích systémech s jinou architekturou. Jsou to decentralizované verzovací systémy jako GNU arch (2001), Darcs (2002) a Monotone (2003). V roce 2005 se objevují Git, Mercurial a Bazaar. A o rok později pak Fossil – ten sice nepatří k nejpoužívanějším, ale možná nás zaujme integrovanou wiki a systémem na správu požadavků/chyb.

Někteří autoři jako Joel Spolsky dokonce považují distribuované verzovací systémy za největší pokrok v technologiích pro vývoj softwaru. Ať už jim dáme za pravdu, nebo ne, jedno je jisté – každá další generace verzovacích systémů přináší zajímavé myšlenky, posouvá hranice výkonu, kapacit a úspornosti, nebo přichází s novou koncepcí. Je poučné sledovat historii a zábavné těšit se na budoucnost. Co nás asi čeká během příštích pár let? Můj osobní tip je jednak čím dál tím větší integrace s dalšími vývojářskými nástroji (správa chyb, testování, projektové řízení…) a jednak větší uplatnění verzovacích systémů i mimo oblast softwarového inženýrství.

Co jsou verzovací systémy a k čemu jsou dobré

Verzovací systém je v dnešní době nepostradatelným pomocníkem snad pro každého vývojáře. Slouží jako úložiště zdrojových kódů a dalších důležitých souborů, uchovává jejich historii (verze) a umožňuje spolupráci s ostatními vývojáři. Uveďme si alespoň pro pořádek, jaké jsou hlavní výhody používání takového systému:

• Uchování historie verzí – Ještě včera váš program fungoval a dneska pořád padá? Honem ve stresu hledáte nějaké zálohy nebo nasazené kopie programu, abyste mohli zákazníkovi dodat alespoň poslední funkční verzi? S verzovacím systémem se vám tohle nestane – jednoduše se vrátíte k verzi, která ještě fungovala (nebo prošla testy) a postupně budete procházet změny a hledat, při které chyba vznikla. Ruční verzování (např. kopírováním do očíslovaných adresářů nebo tarů) je skutečně přežitek a verzovací systém oceníte i u těch nejmenších projektů.
• Týmová spolupráce – verzovací systém je skvělý způsob jak sdílet zdrojové kódy (resp. obecně soubory – třeba týmovou seminárku do školy) s ostatními kolegy. Odpadnou vám starosti se vzájemným přepisováním si souborů na sdíleném disku, nebo věčným otravným kopírováním souborů z poštovního klienta na disk a opětovným vkládáním do e-mailů.
• Práce ve více větvích – zejména při vývoji softwaru se vám bude hodit udržovat více větví téhož programu. Staré verze aplikace mnohdy nemůžete zavrhnout a nepodporovat – je třeba k nim vydávat různé opravy – takže zatímco ve větvi 2.0 budete pracovat na nové a úžasné (byť ještě ne zcela stabilní) verzi svého programu do původní, v produkci nasazené, větve 1.0 budete dopisovat drobné úpravy a opravy. Také můžete portovat nějakou funkcionalitu z nové větve do staré (sloučit některé změny).

Následující obrázek znázorňuje typické uspořádání – máme společný server, na který jednotliví členové týmu odesílají svoje upravené soubory a stahují si změny, které provedli jejich kolegové. Server je jen jeden a pracovní kopii má každý člen týmu vlastní:

Při postoupení (commit) sady změn (changeset) do společného úložiště vzniká verze – je dobrým zvykem ke každé verzi napsat výstižný textový popis, aby ostatní věděli, v čem změna spočívá, aniž by museli procházet jednotlivé zdrojové kódy.

Proč distribuované verzovací systémy

U centralizovaných systémů máme kompletní historii změn jen na serveru zatímco na klientech bývá jen poslední verze a rozpracované soubory. Také zde máme jasně rozdělené role – server (společné centrum) a klienti (na počítačích jednotlivých vývojářů).

V případě distribuovaných (decentralizovaných) systémů jsou všechny uzly rovnocenné – na všech máme kompletní historii a můžeme se vrátit k libovolné verzi, aniž bychom se museli dotazovat nějakého serveru. Role nejsou pevně dané, můžou se dynamicky měnit – každá kopie (klon) může být v roli „klienta“ i „serveru“.

Z těchto vlastností vyplývají výhody distribuovaných verzovacích systémů:

• Práce offline – s distribuovaným systémem nic nebrání vývojáři aby pracoval třeba v letadle nebo ve vlaku i bez internetového připojení. Může vytvářet nové verze nebo se vracet k těm starým, nepotřebuje k tomu spojení se serverem. Toto velká je výhoda nejen v případě zcela chybějícího, ale i v případě pomalého nebo nespolehlivého připojení (např. mobilního).
• Bezpracné zálohování – Na počítači každého vývojáře máme plnohodnotné úložiště včetně všech historických verzí a větví. Takže i kdyby došlo na nejhorší a ztratili jsme server a klasické zálohy, prakticky nic se neděje. Můžeme klidně říct: „server je teď u Karla a změny posílejte k němu“ – tým může plynule pokračovat v práci. Jednak nepřijdeme o žádná data a jednak neztratíme čas čekáním na obnovu serveru.
• Vlastní větve – distribuované systémy jsou velice užitečné při vývoji svobodného softwaru. Např. se nám líbí nějaký projekt a chceme v něm něco vylepšit. Jednoduše si naklonujeme úložiště a pracujeme nad touto kopií – nejsme ochuzeni o verzování, máme svoji vlastní historii změn. Odpadá tak administrativa a vyřizování práva zápisu do centrálního úložiště, nemusíme se ani nikoho ptát. Když uděláme kus práce, pošleme původním autorům odkaz na naše úložiště a když se jim naše práce bude líbit, můžou ji přijmout a začlenit pomocí verzovacího systému do hlavní větve. Ani jedna strana nemusí mít k té druhé právo zápisu – každý si verzuje na svém vlastním písečku a v případě zájmu se změny sloučí.
• Modernější systémy – jelikož jsou distribuované systémy mladší, mohly se poučit z chyb svých předchůdců nebo využít modernějších technologií a postupů. Kromě očekávatelného vyššího výkonu a robustnosti nás potěší i různé drobnosti – např. to, že složku .hg, .git nebo .bzr máme v každém úložišti jen jednou, zatímco .svn se nám vždy rozlezlo i do všech podadresářů, což komplikuje např. nasazení aplikace, protože tyto adresáře musíme filtrovat. Šikovnější je také práce s větvemi a štítky. Přestože i starší systémy uchovávají jen rozdíly a vytvoření větve nebo štítku téměř nic nestojí, v pracovní kopii např. v Subversionu se objevují soubory ze všech větví najednou – obvykle tu máme: /trunk (hlavní větev, kmen), /tags (štítky) a /branches (větve). Na straně klienta tak máme všechny soubory v několika kopiích, což jednak může zabírat dost místa a jednak musíme projekt v IDE nebo v editoru otevírat v různých adresářích. V modernějších systémech jsou soubory pořád na stejném místě a mezi jednotlivými větvemi nebo štítky se přepínáme (soubory se aktualizují, ale jsou pořád ve stejném adresáři).
• Více scénářů práce – zatímco u centralizovaných systémů je možný prakticky jen jediný scénář práce (viz první obrázek), u distribuovaných systémů máme možnosti daleko širší. Kromě nouzových scénářů (jako prohlášení některé pracovní stanice za server) můžeme díky rovnocennosti jednotlivých uzlů vymyslet i další uspořádání (viz níže).

Možná se teď ptáte, jestli jsou distribuované systémy jen skvělé a bezchybné, nebo jestli mají oproti svým centralizovaným příbuzným i nevýhody – nějaké se najdou:

• Mírně vyšší složitost – Když jsem v jednom týmu zaváděl Subversion, některým uživatelům chvíli trvalo, než si zvykli, že nepracují se sdíleným diskem a že provedené změny se na serveru neobjeví hned po uložení souboru, ale až po tom, co odešlou změny (commit). U distribuovaných systémů je situace složitější ještě o jeden krok – i když uživatel udělá commit a hezky si pojmenuje verzi, ostatní jeho práci stále nevidí, dokud jim ji nezpřístupní pomocí push (nebo si ji oni nestáhnou pomocí pull). Pokud by to uživatelům činilo potíže, je v některých systémech možné svázat commit a push do jednoho kroku a „emulovat“ tak centralizovaný verzovací systém.
• „Nehezká“ čísla verzí – Zatímco u Subversionu můžeme říct: „Stáhni si verzi 336, tam už je chyba opravená“ u distribuovaných systémů to říct nemůžeme – resp. můžeme, ale není zaručeno, že budeme mít oba tu stejnou verzi č. 336. Číslování (na které se můžeme spolehnout) zde není tak hezky lineární a označení verze vypadá spíše nějak takto: c39a2d3cb6d2.
• Zamykání souborů – zatímco v takovém Subversionu můžete zamknout určité soubory a tím dát kolegům jasně najevo: „teď na tom pracuju, nehrabte mi do toho“ (tzv. model zamknout-upravit-odemknout), v distribuovaných verzovacích systémech nic takového nelze – každý vývojář má svoji větev (resp. kompletní úložiště) a v něm si může dělat, co chce, nikdo mu „zvenku“ nezamyká jeho soubory – případné problémy se řeší až při slučování větví – tzv. model zkopírovat-upravit-sloučit (merge).

Tyto nevýhody nejsou nijak zásadní a neměly by vás odradit od distribuovaných verzovacích systémů, nicméně je dobré o nich vědět.

---

Ve čtvrtek budeme pokračovat hlubším představením distribuovaných verzovacích systémů a tím bude úvod uzavřen.

       

Komentáře

[pavlix]

Moc pěkný úvod, těším se na pokračování.

[Josef Kufner]

Nehezká čísla verzí? Ale u distribuovaných VCS se na tohle přece používají větve: Takže místo "stáhni si verzi 334" to bude "stáhni si odemne větev nove_ikonky". Ještě pořád je to tak ošklivé?

[pavlix]

Je to mnohem hezčí... ale pozor, ne všechny distribuované VCS jsou jako git... existují i takové, kde větev není tak jednoduchá (v gitu odkaz na commit).

[nou]

ani nie. myslim ze vhodnejsie v git su tags. ak potom clovek da git describe tak mu pekne ukaze nieco ako 1.2.6-36-g2294f0c kde je na zaciatku posledny tag potom pocet comitov od toho tagu a nakoniec hash toho comitu kde prave ste.

[pavlix]

Nejlepší je kombinace obojího. Větev označuje pohyblivou verzi (u mnoha projektů se vyvíjí více verzí paralelně, nebo se opravují chyby), tag označuje vydání.

[Josef Kufner]

Git describe je výborná věc na označování konkrétní verze během vývoje, ale pokud někomu chci říct "začleň tohle" tak je lepší se odkázat na větev (která bude po začlenění smazána).

Btw, neví někdo, jak rozšířit výstup git describe o název repositáře (iniciály/zkratka majitele) a případně název větve? Celkem se to hodí při tvorbě balíčku/instalátoru nebo při předání aplikace k otestování, pokud na jedné aplikaci dělá více lidí a existuje mnoho instalací s malými změnami, které jsou teprve na cestě do hlavní větve. Lze to doplňovat později ručně/skriptem, ale to není moc pohodlné a je tam mnoho prostoru pro chyby...

[xkucf03]

Proto je tam ten title="třeba to pro vás bude impulzem k používání štítků (tagů)". Štítky to lineární číslování nejen nahrazují, ale jsou i lepší, protože umožňují označit verze, které jsou z nějakého důvodu zajímavé. Osobně mi to lineární číslování nechybí, ale vím, že je to častý argument/stížnost, proto tam v tom výčtu je.

[CET]

Hezky uvod, tesim se taky na pokracovani. S gitem chci uz dlouho zacit pracovat, ale moc jsem se k tomu nedostal.

Tak dva dotazy na zacatek, mozna v dalsich kapitolach o tom bude rec, akdyz ne, tak jako namet, co by nwbylo od veci zminit.

Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?

Druhej dotaz se tyka struktury. Subversion muzu checkoutovat do FS a vsechno funguje normalne, takze muzu mit v subversion systemovou konfiguraci /etc a zmeny pak ukladat do svn. V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git? Tuaim v projektech unionfs, aufs nebo squashfs jsem videl docela divnou strukturu kopie git repa, ikdyz ted jsem na to koukal a vypada to normalne, je tam jen .git navic, podobne jako .svn. Tak uz se tesim na dalsi dily.

[Jan Marek]

Příloha:

• git-cheat-sheet.svg (165698 bytů)

Hezky uvod, tesim se taky na pokracovani. S gitem chci uz dlouho zacit pracovat, ale moc jsem se k tomu nedostal.

Vřele doporučuju. Zkusil jsem si s ním pracovat na jednom maličkém projektu (asi tak 4 soubory) a teď ho už používám zásadně na všechno. Na root-u lze stáhnout český překlad knihy Pro GIT v PDF. Na začátku jsem ji dost používal. Dál jsem sehnal git cheat sheet, který přikládám do přílohy, to je taková zhuštěná příručka

Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?

Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.

Druhej dotaz se tyka struktury. Subversion muzu checkoutovat do FS a vsechno funguje normalne, takze muzu mit v subversion systemovou konfiguraci /etc a zmeny pak ukladat do svn. V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git? Tuaim v projektech unionfs, aufs nebo squashfs jsem videl docela divnou strukturu kopie git repa, ikdyz ted jsem na to koukal a vypada to normalne, je tam jen .git navic, podobne jako .svn. Tak uz se tesim na dalsi dily.

S gitem je to samozřejmě stejný, stačí dát v /etc příkaz git init a pak (pokud chceme všechny soubory) tak git commit -a. No a pak už jen jednotlivé commity. BTW: v Debianu (potažmo i v Ubuntu) je na tom postaven jeden projekt, jmenuje se etckeeper a dokonce má na výběr, takže kromě git-u lze použít i bazaar, mercurial nebo darcs.

[CET]

Super, diky za ten cheet sheet a pro git uz jsem taky stahnul. Tak ted budu mit aspon co cist

[horada]

Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?

Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.

Nevím jestli jsem to dobře pochopil, ale mám dojem že git ukládá jednotlivé verze jako celek, nikoliv sérii změn (myslím že je to napsáno někde v Pro Gitu). Neupravené soubory asi ne, ale upravené myslím ukládá "vždy znovu". Nevím přesně co to má za výhody, jedna z nich myslím byla že se při požadavku určité revize šáhne přímo pro ni a nemusí se procházet celý strom.

[Josef Kufner]

Git se tváří, že celý commit uloží jakoby vše znovu, ale při tom používá delta kompresi, takže ukládá jen změny od předchozí verze, pokud jsou však změny příliš veliké, tak si daný soubor uloží celý. Pak taky čas odčasu ponechá celý soubor, aby se minimalizoval dosah poruch. (Tedy alespoň podle dokumentace, zdrojáky jsem nečet.)

[Michal Vyskočil]

Je to přesně naopak. Git ve výchozím stavu ukládá plné objekty do adresářů .git/objects/$prefix, kde prefix jsou první dvě čísla sha1. Důvodem je především rychlost přístupu k revizím. Až jako druhá možnost je ukládání rozdílů do .git/objects/packed/, která existuje z důvodu úspory místa (viz git-repack(1)).

[Josef Kufner]

Ale objekt není soubor.

[Michal Vyskočil]

Ale objekt není soubor.

mkdir foo
cd foo/
git init
echo "soubor" > soubor
git add soubor; git commit -a -m "soubor"
find . -type f -cnewer soubor 
./.git/refs/heads/master
./.git/objects/fc/241abf0b9836924d289cc42fe1f218c5c78bf8
./.git/objects/40/6fd5394c9e862fe7b6086437c9b5ef22b6e3b5
./.git/objects/26/3e889a65bde2f9eefcc954003ecbc134d5d342
./.git/index
./.git/COMMIT_EDITMSG
./.git/logs/refs/heads/master
./.git/logs/HEAD

Ve výchozím stavu ukládá git objekty do jednotlivých souborů. V tomto případě vytvoří tři objekty - strom, commit a blob. Až po volání git-repack a git-gc se jednotlivé objekty uloží do pack souboru.

[Josef Kufner]

To jo, objekty ukládá do souborů, ale nějaký main.c není objektem, tím je až např. commit.

[pavlix]

To jo, objekty ukládá do souborů, ale nějaký main.c není objektem, tím je až např. commit.

Soubor (v gitové terminologii blob) je jedním z typů objektů v gitu, takže nemáte pravdu.

[mimi.vx]

Já myslím, že jediný rozdíl bude ve velikosti metadat svn a git-u, protože odhaduju, že se verze ukládají velmi podobně, takže objem "verzovaných" zdrojových kódů bude asi cca stejný... Ale docela by mě zajímalo srovnání.

Zrovna tento predpoklad je dost chybny .... vetsina VCS pouziva sady zmen -- diffy , git uchovava cele soubory ( i kdyz je komprimuje)

[pavlix]

Zrovna tento predpoklad je dost chybny .... vetsina VCS pouziva sady zmen -- diffy , git uchovava cele soubory ( i kdyz je komprimuje)

Zajímavé na tom je, že gitovské celé soubory často zaberou míň místa než SVNkové diffy :).

[Josef Kufner]

U svn máš .svn v každém adresáři. U gitu jen v kořeni. Na /etc a podobné věci to používám. Výhodou gitu je, že nepotebuješ nikde vedle žádný repositář, protože to je všechno v /etc/.git

Velikost repositáře gitu by mohla být menší, tu a tam se chlubí jak to skvle komprimují.

[elenril]

Taky používám git na /etc a další rozsáhlejší konfiguráky (~/.fvwm :) ), je ale třeba mít na paměti jedno podstatné omezení -- neukládá se vlastník a přístupová práva.

[Luboš Doležel (Doli)]

Git si přístupová práva ukládá.

[Jan Včelák]

Neukládá. Uchovává pouze +x bit. Ale je možné to částečně vyřešit různými hooks (viz např. metastore).

[Luboš Doležel (Doli)]

Já že tady vždycky vidím komlet práva. Takže to je vycucaný z prstu?

[trekker.dk]

Pokus:

$ git init
Initialized empty Git repository in .../.git/
$ touch soubor
$ git add soubor 
$ ll
total 0
-rw-r--r-- 1 jirka jirka 0 25. led 21.17 soubor
$ git commit -m "asas"
[master (root-commit) c4a878f] asas
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 soubor
$ chmod 0600 soubor
$ git add soubor
$ git commit -m "asas"
# On branch master
nothing to commit (working directory clean)
$ ll
total 0
-rw------- 1 jirka jirka 0 25. led 21.17 soubor
$ chmod 0700 soubor 
$ git add soubor 
$ git commit -m "asas"
[master f5829cd] asas
 0 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 soubor

Zdá se, že komplet práva, co vidíš, jsou vycucaná z prstu.

[xkucf03]

Mame subversion o velikosti 300GB, z toho jsou asi 80GB binarky (ano, bohuzel nam svn slouzi i jako mezisklad pro binarky, misto kopirovani na disk, ale to nejak zmenime, nicmene porad to vychazi na nejakych 220GB na ostatni repos). Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?

Přiznám se, že takhle velké úložiště jsem nikdy neměl (nejvíc řádově asi 10x menší v P4), ono je i lepší verzovat jen ta nejcennější data (zdrojáky + minimum binárek) než tam dávat všechno. Takové zkompilované binárky vydaných verzí patří spíš na sdílený disk – jednak to jsou data, která není potřeba verzovat (jen přibývají), a jednak to člověka trochu dokope k tomu, aby byl schopný kdykoli sestavit libovolnou verzi (nemělo by se stát, že máš někde binárku/balíček aplikace-v1.2.3 a když o ni přijdeš, tak nevíš, jak ji znova vyrobit).

Jinak ta náročnost při přechodu na nějaký DVCS bude řádově stejná nebo menší, neměl by to být problém. Akorát bych zvážil, jestli to nejde nějak rozdělit nebo vyházet zbytečnosti.

Subversion muzu checkoutovat do FS a vsechno funguje normalne, takze muzu mit v subversion systemovou konfiguraci /etc a zmeny pak ukladat do svn. V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git?

Přesně na tohle používám Mercurial, Git půjde použít taky. Navíc tyhle systémy jsou vhodnější (.svn se rozleze do všech podadresářů)

cd /etc
hg init
chmod 700 .hg
hg addremove
hg commit

Na to nastavení práv nezapomínat – protože kdyby byl .hg čitelný pro všechny, mohl by z něj neprivilegovaný uživatel vytáhnout nějaká tajná data (klíče, hesla atd.).

[pavlix]

Byl by nejakej odhad, jak velky bude git repo po prevedeni ze svn na git?

Do toho se pouštět nebudu, ale pokud používáte verzování mixu zdrojáků a binárek, doporučuju každé do vlastní větve, ať se s tím dá v budoucnu něco udělat (větve spolu nemusí souviset, a neříkám nic o tom, jestli na to má být samostatný repozitář nebo ne).

V /etc mam pak pouze .svn navic, nezname soubory svn ignoruje. Lze stejne pouzivat i git?

Jde, jen můžeš narazit na to, že git nemá úplně stejné vlastnosti jako SVN. Ale rozhodně to jde.

[KarelI]

Jak pisu jinde, v git je bezne, ze velikost repository a pomerne dlouhe historie muze byt mnohem mensi nez velikost vlastnich dat. Zalezi, jak se ty binarky budou dobre pakovat. Rozhodne doporucuju to zkusit.

Git zapleveli vlastni data mnohem min nez svn. U svn je v kopii .svn v kazdem adresari, u gitu je .git pouze v rootu, cili mnohem mene invazivni.

[Andrej]

220GB na repos - to v svn simulujete mavena?

[Heron]

Moc pěkný úvod, těším se na další díly.

Používám SVN právě proto, že je centralizované. Ještě jsem nepřišel na výhody decentralizovaných VCS, akorát bych si musel vytvořit hook na commit a push. Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci. Jinými slovy po prvním checkoutu se to vzájemně rozpadne a všude budou jiná data. Toto snad objasní další díly.

[happy barney]

Skús si pozrieť a pracovať s git-svn ... je to vcelku dobrý medzikrok a kedykoľvek sa môžeš vrátiť k samotnému svn.

[Michal Vyskočil]

akorát bych si musel vytvořit hook na commit a push

Po takové "degradaci" gitu na svn přijdeš o spoustu dalších vychytávek a zůstane ti jenom bleskurychlé prohlížení historie. Výhodou odděleného commit a push je to, že větší sadu změn lze snadno rozdělit (commitovat) na řadu menších patchů a pushovat až výsledek. Navíc lze lokálně dělat spoustu věcí jako rebase -i, alias hergot, teď v šestém commitu v mojí sadě je pitomý překlep.

Navíc git umožňuje spolupráci i v případě, že nemám přístup do centrálního repository - třeba do Linusova stromu nemá přístup nikdo jiný, než on a kód se do něj dostává přetahováním změn z ostatních stromů. Nebo send-patch je šikovná metoda přispívání do projektu, aniž by se musela řešit administrativa s přístupovými právy. Hezkým důsledkem je, že Linusův strom je hlavní pouze proto, že se na tom většina vývojářů shoduje - technicky není problém vyhlásit za nový hlavní strom strom kkohokoli jiného.

Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci.

No synchronizace vzdálených a lokálních dat je základním předpokladem pro každý slušný systém pro správu verzí, ne? Však v zásadě jediné, co git clone oproti svn checkout dělá navíc je to, že stáhne všechny revize všech souborů, které si udržuje ve stromu revizí.

[trekker.dk]

Navíc lze lokálně dělat spoustu věcí jako rebase -i, alias hergot, teď v šestém commitu v mojí sadě je pitomý překlep

Přesně, díky rebase se s klidem můžeš prohlásit ("podívejte se na historii") za neomylného programátora, který na všechno myslí dopředu. Teda aspoň do chvíle, než ten kód nahraješ někam ven.

[Milan Jurik]

Ta vzájemná synchronizace je provedena správci (vývojaři) jednotlivých "uzlů" podle potřeb jednotlivých projektů. Pokud na svých projektech pracuješ pouze sám a máš vždy rozdělaný jen malý počet nových vlastností v projektu, asi to moc neoceníš, snad jen, že nezávisíš na jednom centrálním stroji při vývoji.

Pokud je ten projekt o pár milionech řádcích kódu, o pár stovkách přispěvatelů a pár desítkách velkých změn, z nichž některé jsou vyvíjeny mnoho let mimo hlavní větev, pak ti distribuovanost řeší problém škálovatelnosti vývoje.

[Heron]

Pracuju sám stylem svn update, práce na projektu, svn commit a proto potřebuju mít všude poslední data. Což centrální svn splňuje už z principu. Proto nějak nevidím důvod (a výhody) VCS. Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge). Zcela totéž bych ale musel řešit u Dist. VCS

snad jen, že nezávisíš na jednom centrálním stroji při vývoji

Vzhledem k tomu, že ten stroj na kterém jsem pracoval před hodinou je teď nedostupný, tak to stejně musím commitnout na nějaký centrální bod.

Možná to jen špatně chápu, ale třeba to někdo vysvětlí:

Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.

No a teď, v článku je naznačeno, že v případě výpadku se může udělat centrální uzel z libovolného jiného uzlu. No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.

Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.

Možná je jen problém, že si to celé představuju jako multimaster replikaci.

[trekker.dk]

No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.

To vyloženě záleží na tom, jak často si ostatní synchronizují úložiště s tím původním centrálním serverem. Což - pokud na nových vlastnostech pracují ve svých samostatných větvích a to by měli - můžou dělat třeba každou hodinu.

Ale jinak jo, asi by se v takovém případě musel vzít nejaktuálnější uzel a do něj ručně našoupat novější změny, to znamená ruční práci stejnou, jako když se to šoupalo do původního centrálního serveru.

[Filip Jirsák]

Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge).

Dál na tom projektu pracovat můžete, slučování nebudete dělat ručně, ale udělá to VCS. Samozřejmě pokud chcete editovat ten nový kód, potřebujete ho – ale k tomu nepotřebujete nutně mít všude poslední data, stačí si s sebou třeba vzít ten poslední commit.

Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních).

Nepotřebuje a zpravidla ani nechce. Od ostatních chci mít odladěný a funkční kód, ne to, co mají zrovna rozpracované. Pokud už na něčem pracuju s kolegou, chceme si vyměňovat kód jenom mezi sebou – když mi upraví rozhraní, chci jenom to změněné rozhraní, nechci si kvůli tomu z centrálního úložiště stahovat neodladěný kód všech ostatních a řešit třeba jejich změny rozhraní. S DVCS mi jen kolega pošle ten správný commit, nebo si vytvoříme společný centrální bod jen pro nás dva, nebo si vytvoříme novou větev. V centralizovaném VCS bychom museli vytvářet novou větev, a s tím se kvůli jednomu souboru opravdu nikdo dělat nebude. Takže pak (třeba se SVN) skončíte tím, že si ten jeden změněný soubor pošlete e-mailem, takže vaše představa o aktuálním kódu v centrálním bodu je jen iluzí, ve skutečnosti je aktuální kód roztroušený někde v e-mailech.

[washeck]

Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.

Nemusí. Např. na githubu si najdeš projekt, který se ti líbí a potřebuješ do něj jednu změnu. Uděláš si fork, přidáš svoji fíčuru a provedeš commit a push. Původnímu autorovi se tvoje změna může líbit a přetáhne ji k sobě, nebo pokračujete ve vývoji každý zvlášť. Takových forků může být spousta a žádný není hlavní. Linusův kernel je ten hlavní z politicko-manažerských důvodů, ale z hlediska správy verzí je rovnocený s Ingovým nebo Tedovým.

Pravda, v komerční komerční praxi to není obvyklý model. Ale oddělení commit a push má svůj význam. My používáme svn, všichni jedeme z trunku, protože slučování větví je opruz. Zároveň je to záloha pro případ havárie mého notebooku. Jenže když dělám nějaký větší refactoring, který by ovlivnil ostatní nemůžu ho commitnout dokud není hotový a otestovaný. Nebo kolega, který s oblibou doma bez VPN po nocích opravuje všechno napříč aplikací. Ráno přijde do práce, udělá megacommit 5 oprav a 2 nových feature v jednom. U distribuovaného systému by to v noci commitoval a ráno v práci pushnul.

Jinak tenhle úvod je zajímavý, ale přínosnější by byly články z praxe o přechodu ze SVN na distribuovaný systém. My jsme třeba vzdali přechod na Mercurial, protože neumí checkout podadresáře, což je pro nás vzhledem k historickému layoutu repozitáře zásadní problém.

[Program]

Mercurial neumí "checknout" podadresáře? Tak to fakt nevím, jak se vám povedlo... Možná tak prázdné stejně jako git, protože zpracovává soubory a adresář je cesta k souboru. Jako asi by stálo za to se nad tím zamyslet...

[washeck]

http://mercurial.selenic.com/wiki/UnderstandingMercurial#What_Mercurial_can.27t_do

"Many SVN/CVS users expect to host related projects together in one repository. This is really not what Mercurial was made for, so you should try a different way of working. In particular, this means that you cannot check out only one directory of a repository."

Prostě v SVN běžný způsob práce (vše v jedno repository) není u Mercurialu vhodný. Neříkám, že to není řešitelné, ale komplikace s tím spojené u nás převážily nad výhodami. Mimochodem, v jedné velké firmě jsem zažil, že v jednom repository byly projekty dokonce za celé oddělení, každý se svými podadresáři trunk, branches, tags.

[Program]

Aha takhle... To už je ale i v SVN docela prasárna, i když se to dělá... V CVS to bylo podporováno, tam je to úplně jedno. Ale to může být přeci docela řešitelný problém, prostě se to repo importuje, naklonuje a v každém klonu se nechá jen ten požadovaný projekt... Jako jen čistě z poradního hlediska bych to doporučil zkusit...

[Josef Kufner]

Btw, git je na tom stejně a skládání repositářů dohromady řeší pomocí submodulů (dobré na knihovny a podobně).

[ebik]

Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.

Kazdy si nastavi novy hlavni server jako defaultni remote, a vsichni kteri maji praci, ktera na tom novem 'hlavnim serveru' pak provedou "git push" (nebo ekvivalent v jinem VCS, eventuelne synchronizuji jinou metodou (spravce udela pull, nebo tak neco)). Je to bez cehokoliv dalsiho (tedy skutecne jen napisi "git push" a stisknou enter). Vzhledem k tomu, ze pushuji pravidelne tak je jeden push navic nezabije.

Pokud nejaky vyvojar chce aktualni praci jineho vyvojare (bez ohledu na vypadek hlavniho serveru, ten druhy vyvojar z nejakeho duvodu jeste nemusel pushovat), tak si to proste od nej pullne (za predpokladu ze ma cteci pristup do jeho repozitare). Tak muze napriklad spravce projektu pullnout k sobe, zkontrolovat jestli to dela co ma a pak pushnout na 'distribucni' server, jako oficielni verzi.

[mkoubik]

Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge).

Dlouholetý uživatel svn se pozná tak, že mu při vyslovení "merge" naskočí husí kůže S gitem (nebo obecně DVCS) je potřeba trochu změnit přístup. Merge (resp. rebase) je naprosto běžným nástrojem bez problému používaným na každodenní bázi. Navíc můžeš opustit "commitnu to až dokončím fíčuru, nebo na konci šichty". V gitu se obvykle commitují atomické změny (několikařádkové změny v pár souborech), které ani nemusí projít testy.

Teď skusím vysvětlit, jak funguje rebase:

Já a kolega máme u sebe 4 verze A, B, C a D.

D
|
C
|
B
|
A

Já udělám změnu E1, a když pullnu kolegův repozitář, zjistím, že on udělal změnu E2, která také vychází z verze D.

E2 E1
| /
D-
|
C
|
B
|
A

Změnu E1 proto rebasnu - upravím "patch" tak, že nevychází z verze D, ale z verze E2 (a končí stejným stavem zdrojáků). Dostanu tak:

E1
|
E2
|
D
|
C
|
B
|
A

Kolega si pullne můj repozitář a jede se dál. Nebo můžu udělat merge, pak ale získám:

M-
| \
E2 E1
| /
D-
|
C
|
B
|
A

Tohle se dělá v gitu naprosto běžně, nejsou s tím problémy a je to rychlé (časová náročnost merge roste jenom s velikostí zdrojáků/změn, ne s počtem commitů ve větvích, na běžném počítači nepostřehneš, že se něco děje).

[pavlix]

Každý člen týmu lidí pracujících na jednom projektu potřebuje mít aktuální verze (od všech ostatních). Tedy i ten distribuovaný VCS musí mít někde centrální bod (a má) kam jednotlivý vývojáři udělají push a z něj něco jako update.

Technicky nemusí. To je jen jeden ze způsobů práce. Ale typicky, každý projekt, sebevíce decentralizovaný, mívá nějaké oficiální verze na jednom oficiálním místě typicky spravovaném jedním člověkem.

Decentalizace nespočívá v tím, že zrušíš hlavní úložiště, ale že můžeš pracovat i bez něj a v extrému se může používat třeba pouze pro distribuci a klonování při zakládání nových větví.

No a teď, v článku je naznačeno, že v případě výpadku se může udělat centrální uzel z libovolného jiného uzlu. No ale jak, když tento uzel v typickém případě zcela jistě nebude mít data synchronizovaná s tím bývalým centrálním? Tedy bude v nějakém starším čase.

Jednoduše, když se z ně stane centrální uzel, tak se do něj postupně dostanou ztracené změny znovu, protože je někdo vždycky má.

Možná to půjde řešit tak, že na tento nový uzel všichni ostatní pushnou práci vytvořenou od toho staršího času, ale to mi přijde jako dost ruční práce.

Tahle ruční práce je ale každodenní záležitost buď vývojářů (centralizovaný model) nebo začleňovačů (složitější modely).

Možná je jen problém, že si to celé představuju jako multimaster replikaci.

Na multimaster replikaci je problém to, že jednak musí být automatizovaná, což VCS typicky není, a druhak v multimaster typicky není definovaná hierarchie, což u lidmi řízených projektů typicky je.

[Josef Kufner]

Do multimaster to má celkem daleko. Spíš se role uzlů v čase mění, podle toho, kdo komu předává změny. A tyto změny se pak scházejí v nějakém vybraném uzlu se kterým se pak všichni více či méně synchronizují.

Ta decentralizace ani není o tom, že není centrální bod, ale o tom, že ho k práci nepotřebuješ, lze lehce nahradit a slouží více jako komunikační kanál než skladiště.

[Milan Jurik]

Pracuju sám stylem svn update, práce na projektu, svn commit a proto potřebuju mít všude poslední data. Což centrální svn splňuje už z principu. Proto nějak nevidím důvod (a výhody) VCS. Pokud se stane, že na předchozím místě zapomenu na commit, tak nemůžu pracovat dál (musel bych pak dělat ručně merge). Zcela totéž bych ale musel řešit u Dist. VCS

Co je na merge vlastniho kodu spatneho? Delam jich fury. Naopak merge vlastniho kodu je pohodicka, protoze tam mam dost jasnou predstavu, jak ten kod ma dopadnout. A diky plne kontrole nad vlastnim klonem si mohu ten merge provadet podle svych potreb a v intervalech, ktere si urcim.

Možná je jen problém, že si to celé představuju jako multimaster replikaci.

Ale ano, muzete to brat jako multimaster replikaci. A distribuovane VCS toho schopne jsou. Ale to by postradalo smysl pro typicky vyvoj produktu, spise se na to lze divat jako na strom, kde v koreni je obvykle to, co pak release engineering vezme a postavi nad tim vysledny produkt. Pripadne je to les takovych stromu.

[trekker.dk]

Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci. Jinými slovy po prvním checkoutu se to vzájemně rozpadne a všude budou jiná data.

Pokud máš všechny uzly pod kontrolou ty sám, tak to není problém; záleží na tom, jestli chceš, aby ve všech uzlech byla jiná data, nebo ne.

Když chceš synchronizaci, tak prostě jeden uzel prohlásíš za hlavní (třeba jako bare repository) a na všech ostatních, když něco změníš, tak to do něj nahraješ a odtud potom distribuuješ na ostatní uzly. Jak je řečeno i v článku, Git se v tomhle umí chovat jako SVN (tj. jeden centrální server)

Když chceš jiná data na každém uzlu, tak bych to viděl na větve.

[Josef Kufner]

Přisuzuješ gitu vlastnosti svn. Zkus to a uvidíš. Vyexportuj si svůj svn repositář pomocí "git svn clone" a zkus si s tím chvíli hrát.

Merge je v svn strašidlo, ale v gitu to funguje tak nějak samo. Navíc pokud někde něco rozděláš a pak si vzpomeneš, že se mezitím objevily změny odjinud, tak v klidu nacommituješ cos právě udělal a provedeš rebase. Tvoje změny budou odstraněny, stáhnou se cizí commity a následně se ty tvoje změny zas aplikují zpět. Při troše štěstí ani není třeba řešit žádné konflikty a git jen napíše, že to je hotové.

I když nevyužiješ vše co ti git nabídne, tak je toho dost navíc i při centralizovaném způsobu práce. A čim více menších commitů budeš dělat, tím líp se git používá.

[Heron]

Asi jsem měl napsat, že svn nepoužívám ani tak na zdrojáky (roky už neprogramuju), jak spíše na binární data (nejčastěji writer, calc, pdf, malůvky a fotky png apod). Merge starého a nového odt to rozhodně samo neudělá.

[Josef Kufner]

Aha, no to pak máš smůlu

[mkoubik]

Pokud odt rozbalíš (je to zip), tak dostaneš adresář plný xml souborů, obrázků atd. Ten už verzovat a mergeovat půjde.

[Heron]

To vím, že to je zip, ale tohle nemyslíš vážně

[Josef Kufner]

Hehe, tohle mě napadlo taky a přesně takovouhle reakci jsem čekal.

[mkoubik]

To jsem myslel pro případ, kdy je slučování změn primárním požadavkem (např týmová práce na jednom dokumentu), pak by to bylo dost použitelné. Na inkrementální backupování většího množství binárních souborů se ovšem VCS moc nehodí.

[Heron]

To jsem myslel pro případ, kdy je slučování změn primárním požadavkem (např týmová práce na jednom dokumentu), pak by to bylo dost použitelné.

Aha, tak na toto je vhodnější wiki engine.

[xkucf03]

Myslím, že Tortoise SVN nebo něco takového umělo udělat diff wordovského dokumentu (pak v něm byly vyznačené nové a odtsraněné části), ale stejně to pak nejde rozumě zpracovat (je to dobré leda na sledování, co přibylo). Rozbalování zipů je blbost -- to by chtělo podporu Writeru nebo nějaký specializovaný nástroj -- zkoumání rozdílů těch XML souborů ti moc nedá. Tady se projevuje výhoda textových formátů -- např. XHTML nebo DocBook, případně LaTeX nebo nějaký wiki formát (třeba Texy).

[Petr Tomášek]

Tady se projevuje výhoda textových formátů -- např. XHTML nebo DocBook, případně LaTeX nebo nějaký wiki formát (třeba Texy).

Nebo abiword

[pavlix]

Nebo abiword

Vedle. AbiWord je název aplikace, jejích nativní formát je postavený nad XML (teda aspoň podle wikipedie), takže žádný zázrak.

[pavlix]

Myslím, že Tortoise SVN nebo něco takového umělo udělat diff wordovského dokumentu

Tak já se s tím setkal poprvé u gitu, ale volat externí diff umí skoro každý VCS, ne?

[pavlix]

Tak na to bych používal spíš git než svn už z principu. Merge holt nepoběží na úrovni řádků, ale celých souborů, ale když s tím počítáš, tak si kolize nezpůsobíš (a když ano, tak si to vyžereš do dna). Ale každopádně je git na synchronizaci podle mě jednodušší.

[Petr Tomášek]

Naopak, na tohle je lepší SVN!

Přinejmenším se z SVN dá udělat WebDAV server, který pak funguje (při "autocommit") navenek jako síťový server, ale ve skutečnosti ukládá jednotlivé verze...

[ebik]

'Autocommit' se da postavit nad vsim. I nad starym RCCS. Dav "modulu" (treba v php, nebo cemkoliv jinem) je dost na to, aby si za ne clovek snadno navesil cokoli chce. Jedina vyhoda svn tu je, ze uz je to predem resene. Ale myslim, ze pri autocommitu binarnich dat nema smysl udrzovat verze /adresare/, ze staci udrzovat verze jednotlivych souboru. To je vyrazne jednodussi uloha, kterou zvladne i nekolikaradkovy shellskript. Vyhoda je potom ta, ze reseni si muzes usit na miru souborum, ktere ukladas. Tim napriklad hodne usetris na metadatech. Neco slozitejsiho ma smysl pouzit, pouze kdyz mas smysluplny diff mezi soubory (ktery realne a vyzname usetri misto tim, ze budes ukladat jen diffy).

[Petr Tomášek]

Jenže SVN to už má v sobě, chápeš?

[ebik]

Ale ta implementace je takova, ze bych se s ni nechlubil. Chapes?

[xkucf03]

To je pravda. Není to sice nějak často potřeba a přijde mi to dost humpolácké (každé uložení souboru znamená verzi), ale občas to uplatnění najde.

[pavlix]

Naopak, na tohle je lepší SVN!

Aspoň jeden skutečný argument? Vykřičník argumentem není.

Přinejmenším se z SVN dá udělat WebDAV server

Hmm, argument z neznalosti, bezva.

který pak funguje (při "autocommit") navenek jako síťový server, ale ve skutečnosti ukládá jednotlivé verze...

Tím, že uvedeš společnou feature dvou systémů těžko dokážeš, že je jeden lepší.

[Petr Tomášek]

Naopak, na tohle je lepší SVN!

Aspoň jeden skutečný argument? Vykřičník argumentem není.

Argument je jednoduchý: SVN je navržen, aby fungoval jako centrální úložiště, git je navržený jako centralizovaný...

který pak funguje (při "autocommit") navenek jako síťový server, ale ve skutečnosti ukládá jednotlivé verze...

Tím, že uvedeš společnou feature dvou systémů těžko dokážeš, že je jeden lepší.

...to že někdo dobastlit WebDAV do gitu na tom nic nemění.

[trekker.dk]

fungoval jako centrální úložiště, git je navržený jako centralizovaný...

Skoro mám pocit, že jsi chtěl říct decentralizovaný, ale i tak je to jedno. Git je navržen tak, aby fungoval, jak potřebuješ. Centralizovaně/decentralizovaně - můžeš si vybrat.

[pavlix]

Argument je jednoduchý: SVN je navržen, aby fungoval jako centrální úložiště, git je navržený jako centralizovaný...

Když vynechám překlep... to, že neznáš Git a nevíš, jak fungují a k čemu se používají DVCS není zrovna důvod k radosti a sebejistým tvrzením o tom, na co se hodí nebo nehodí.

...to že někdo dobastlit WebDAV do gitu na tom nic nemění.

Že je to nabastlené v SVN mě taky moc nebere. WebDAV je vcelku primitivní rozhraní, není to žádná černá magie. A popravdě řečeno je to na /etc dost nepoužitelné.

[pavlix]

Používám SVN právě proto, že je centralizované. Ještě jsem nepřišel na výhody decentralizovaných VCS, akorát bych si musel vytvořit hook na commit a push. Představa, že na každém uzlu mám všechna data je sice lákavá, ale na druhou stranu si moc neumím představit jejich vzájemnou synchronizaci. Jinými slovy po prvním checkoutu se to vzájemně rozpadne a všude budou jiná data. Toto snad objasní další díly.

Když si jednou zvykneš, už se nebudeš chtít nikdy vrátit k centralizovaným.

Vzájemná synchronizace je (může být) stejná jako u SVN, akorát se používá pull a push místo update a commit.

Při centralizovaném způsobu práce s gitem (i tak má výhody oproti centralizovaným VCS) je jediný rozdíl v tom, že commituješ lokálně, pak dáš pull, abys byl aktuální, opravíš případné konflikty (stejně jako v SVN), a dáš push, který pošle všechny tvé commity včetně toho, který ty dvě linie vývoje spojuje opět do jedné.

Takže v historii to je vidět.

Příkladem výhody DVCS proti centralizovanému při použití centrálního repozitáře je například práce offline, která v SVN prakticky nefunguje.

Takže nic těžšího než SVN.

No a když se dostaneš kousek dál, tak oceníš lokální větve, možnost synchronizace mimo centrální úložiště (testování práce kolegy, autonomní týmy, lokální úpravy použitých opensource knihoven s pozdějším začleňováním do upstreamu, atd...). Ale to už je další level.

[Petr Tomášek]

opravíš případné konflikty (stejně jako v SVN)

Akorát je šance, že těch konfliktů bude u SVN míň...

[ebik]

Ale je take velika sance, ze ti git pri reseni konfliktu bude prekazet vyrazne mene nez svn. Takze jich muze byt teoreticky na pocet vic (pri urcitem druhu prace), a presto se vyvoj zprijemni a zrychli.

[Petr Tomášek]

Jistě, ale to záleží právě na charakteru změn, jejich počtu a počtu autorů...

[pavlix]

Jistě, ale to záleží právě na charakteru změn, jejich počtu a počtu autorů...

Spíš jenom na charakteru změn.

[pavlix]

Akorát je šance, že těch konfliktů bude u SVN míň...

Pokud budeš git používat dostatečně hloupě, tedy jako SVN, tak bude konfliktů úplně stejně.

[Petr Tomášek]

To je ideologický blábol.

[Josef Kufner]

Proč?

[Petr Tomášek]

Protože neposkytuje žádné rozumné argumenty...

[pavlix]

Protože neposkytuje žádné rozumné argumenty...

Taky jsem na žádné rozumné argumenty neodpovídal.

[pavlix]

To je ideologický blábol.

Ne to je technicky podložený fakt. Vzhledem k tomu, že Git i SVN používají velmi podobné metody řešení konfliktů, při stejném způsobu práce budou úplně stejné konflikty a budou se řešit úplně stejným způsobem.

Ideologický blábol je to, že Git způsobuje konflikty.

[Petr Tomášek]

Když si jednou zvykneš, už se nebudeš chtít nikdy vrátit k centralizovaným.

To je teda argumentace jako z reklamy na jogurty...

[trekker.dk]

No na poli argumentace jsi se zatím taky moc nepředvedl, takže bys za to neměl kritizovat jiné...

[Petr Tomášek]

Naopak. Ukazuju na rétorickou figuru „už se nikdy nebudeš chtít vrátit“, která se používá v marketingových kecech, když se chtějí zamlžit skutečné argumenty.

Koneckonců, já nedělám školení na žádný verzovací systém, takže taky nemám důvod, abych se snažil ostatní přesvědčit, že by jeden systém měl být nejlepší za všech okolností a na všechny typy nasazení...

[mnn]

takže taky nemám důvod, abych se snažil ostatní přesvědčit, že by jeden systém měl být nejlepší za všech okolností a na všechny typy nasazení...

práve naopak... toto robíš tu celý čas...

[pavlix]

Naopak. Ukazuju na rétorickou figuru „už se nikdy nebudeš chtít vrátit“, která se používá v marketingových kecech, když se chtějí zamlžit skutečné argumenty.

Asi se moc koukáš na televizi, já za posledních několik let reklamu na jogurt neviděl.

Koneckonců, já nedělám školení na žádný verzovací systém, takže taky nemám důvod,

Ani bych ti to nedoporučil :).

abych se snažil ostatní přesvědčit, že by jeden systém měl být nejlepší za všech okolností a na všechny typy nasazení...

Pokud vím, tak prosazuješ Subversion. Sice asi na určitý typ nasazení, ale neuvedl jsi jediný platný argument, proč by svn mělo být na ten účel lepší.

Takovým pokusem byl možná WebDAV, ale ani to se ti moc nepovedlo. Kdybys u toho zůstal, nikdo by ti nic nevyčítal, ale když přejdeš od argumentů k pouhým chabým pokusům druhého shodit, tak nečekej, že si z tebe sednou všichni na zadek.

[pavlix]

To je teda argumentace jako z reklamy na jogurty...

Jenom proto, že ty nemáš žádný pádný argument, nemusíš někoho urážet. Ale pravda, můžeš, tohle je otevřené fórum, ztrapňuj se dle libosti.

[pavlix]

Mimochodem, ten hook bych nedával... na centralizovaných VCS se běžně aplikuje pravidlo, že se smí commitovat jen funkční verze... čímž jsou commity nepřiměřeně velké a splácané. Na DVCS není potřeba aby commity vedly na funkční verze. Pokud jich posíláš víc najednou, stačí když funguje poslední.

[Josef Kufner]

Akorát když pak někdo chce použít bisect, tak z toho nebude moc nadšený...

[pavlix]

No... to je pravda, díky za připomínku! U projektů, u kterých to takhle dělám bisect nepotřebuju, takže mě to ani nenapadlo.

[Bilbo]

Tak mně napadá - je v gitu na tohle nějaký pokud možno co nejautomatičtější postup, kde X minicommitů (než jsem se dohrabal k něčemu funkčnímu) sloučím do jednoho velkého, který pak pushnu do "oficiálního" upstreamu? Optimálně, aby se ty minicommity i nějak zachovaly (třeba v extra branchi ....)

[Josef Kufner]

Tohle umí rebase. Má i takový editovací režim, kdy ti otevře editor se seznamem commitů a ty tam napíšeš, co s každým commitem má udělat a můžeš i změnit jejich pořadí. Viz "git rebase --interactive". Commity samozřejmě zůstanou, jen se na ně ztratí jedna reference, takže pokud jsou součástí nějaké další větve nebo si pamatuješ jejich ID, není problém se k nim dostat.

[Bilbo]

Tak to zkusím. BTW dá se nějak v gitu snadno (nejlépe jedním příkazem :) zduplikovat branch včetně historie? (pokud si chci ponechat i původní "prasáckou" sadu commitů před pročištěním)

[Josef Kufner]

Jak jsem říkal, ty původní commity se nijak nemění.

[trekker.dk]

Když udělám rebase a squash commitů do jednoho, tak tam ty původní zůstanou? A já myslel, že pomocí rebase se lze vydávat za neomylného... ... a taky pročistit archiv od nadbytečných jednořádkových oprav.

[Josef Kufner]

Jo, zůstanou. Git vyrobí nové, nastaví reference na ně a ty staré tam nechá hnít, dokud je garbage collector nesmaže (git gc). Za neomylného se vydávat můžeš, k tomu to je. Ale to, že commit není v nějaké větvi, ještě neznamená, že neexistuje. Při push se samozřejmě odesílají jen ty commity, na které je odkazováno, takže se nikdo nedoví, jaký patlal jsi

[trekker.dk]

Ach tak. Dík za info.

[pavlix]

Tak rebase je hlavně určený k udržení lineární historie tam, kde je to žádoucí nebo jsou na to lidé zvyklí (z centralizovaných VCS).

[trekker.dk]

Já měl za to, že je určený k tomu, aby se ještě před začleněním vyvíjené větve dala tahle větev "založit" na novějším výchozím bodě, aby se omezily konflikty, až se vyvíjená větev bude začleňovat do té původní

(Něco jako - mám master, udělám větev vlastnost, master se vyvíjí, já jednou za čas stáhnu master a udělám rebase vlastnosti na master tak, aby to vypadalo, že jsem svoji práci odvodil od aktuálního master a ne od nějakého starého commitu - AFAIK by to potom mělo zjednodušit začlenění vlastnost do master, i když historie nebude lineární)

Ale hádat se o tom nebudu...

[Ladicek]

Já myslím, že dneska lze s klidem říct, že rebase je určený k jakýmkoli změnám historie za aktuálním HEADem (na ten stačí commit --amend): přeházení pořadí commitů, jejich úprava, slučování i rozdělování, změna commit message, prostě co si člověk představí.

[Gilhad]

Pripadne nechas vetev tak jak je a jenom do masteru commitnes squasnute zmeny. Vetev je pak u tebe netknuta s milionem malych commitu, v masteru se "najednou zazrakem" objevi jeden commit zavadejici vsechny potrebne zmeny naraz v definitivnim zneni. Az po letech bude vse promlceno, lze davno nepotrebnou vetev smazat.

[Josef Kufner]

Zrovna tohle je celkem ošklivé, protože se takový commit těžko reviduje. Místo toho bych radši viděl obyčejný merge.

[Gilhad]

V nekterych pripadech to osklive je, v jinych je to naopak hezke. Ale je to odpoved na to konkretni zadani.

Priklad, kde to je hezke a kdy jsem to tak udelal je kdyz jsem v hlavni rade normalne pilne pracoval, zatimco v branchi jsem pridaval novou, dost komplexni a na zbytku prakticky nezavislou vlastnost. Protoze me prace v hlavni rade dost vytezovala, tak jsem v branchi pracoval jen po malych kouscich ve volnych chvilkach, prubezne prerusovan jinymi zalezitostmi. Takze ten branch mel nekolik desitek komitu, ktere byly ve stylu :

Zalozen soubor A a pridano 10 radek. Pridano 10 radek na konec souboru A.Pridano 10 radek na konec souboru A.Pridano 10 radek na konec souboru A.Pridano 10 radek na konec souboru A.

Zalozen soubor B a pridano 10 radek. Pridano 10 radek na konec souboru B.Pridano 10 radek na konec souboru B.Pridano 10 radek na konec souboru B.Pridano 10 radek na konec souboru B.

Zalozen soubor C .....

Nikde zadne opravy, jenom se to tahlo asi mesic. Nakonec se v hlavni rade objevil strucny zaznam: Pridana featura #123 (soubory: A 50 radek, B 50 radek, C 120 radek...)

Jestli jsem 28. radek souboru C psal pred obedem nebo po nem v tomto kontexu fakt roli nehralo, proste jsem potreboval poridit desnou hromadu textu a neslo to udelat v jednom zaberu, ale kdy jsem si mezitim daval pauzy nikoho nezajimalo.

Kdybych to normalne mergnul dovnitr, tak budu mit pri kazdem prochazeni hlavni historie spoustu naprosto nic nerikajicich komitu, ve kterych ten system nebyl kompletni ani prelozitelny a pritom by v nich nebylo nic, co by jakkoli usnadnilo ladeni. Proste to z jakehokoli rozumneho hlediska byl jeden logicky vele-komit, kde se pridaval jeden taaaaaakovyhle balik nove porizeneho textu bez uprav a vnitrniho cleneni, protoze tam nic takoveho taky nebylo.

(Proste jsou pripady, kdy obecne oskliva vec muze byt v konkretnim pouziti naopak veci hezkou - a samozrejme i pripady opacne)

[Josef Kufner]

Na tohle bych asi použil --amend už v průběhu tvorby. Poslední commit by prostě pozvolna rostl...

[Gilhad]

Asi ano, ale to bych si na to musel vzpomenout driv. Ono to na zacatku vypadalo, ze to bude celkem kratke a ze to strhnu naraz, ale pak zazvonil telefon ... a ja zacal resit co horelo a nestudoval manual gitu, zda neni lepsi cesta, nybrz jsem pouzil co jsem mel proverene - commit, zmenu branche, zachranit situaci ...

Ale asi nejsem sam, komu se takovehle veci deji (ci dokonce vyhovuji), protoze si nekdo dal tu praci a tu funkci do gitu zakomponoval.

(A taky se mi libilo vic mit v te vetvi komentare typu "pridan konfigurak do /etc" "Pridano cteni konfiguraku" "pridan vypis konfigurace do logu" - ze jsem videl, jak to postupuje a co uz je a co jeste neni, aniz bych musel lezt do kodu. S tim, ze v dusledku to pak stejne byl cely balik jako jeden blok, ale v prubehu jeho psani mi to usnadnovalo zivot)

[Gilhad]

Coz je taky vec, co se mi na gitu libi - ze nema tendenci mi rikat "ale to sis mel rozmyslet driv" a kdyz si vzpomenu az pozdeji, tak mi da nastroje to udelat dobre a snadno.

[diacone]

Myslim, ze vhodny je merge:

git merge --no-ff --no-commit --log vetev
git commit -e

[xkucf03]

Škoda, že je ten článek rozdělený na dva -- ale prý by to bylo dlouhé jak týden

Ve zkratce: DVCS umí to, co centralizované systémy, a ještě něco navíc -- ten centralizovaný scénář jde klidně realizovat i v mercurialu, gitu, bazaaru atd.

[Milan Jurik]

Ta trocha historie je trošku odbytá. Distribuované VCS začínají o více jak 10 let dříve než je zde uvedené, podstatně dříve než Subversion

[pavlix]

Můžete doplnit. Jinak nemám pocit, že by Franta tvrdil, že historie začíná u Subversion.

[Milan Jurik]

Doplnit? Z verejne znamych DVCS cas zacina pred rokem 1990 v podobe teamware. A to zmineni Subversion v mem prispevku bylo o tom, ze v dobe, kdy vznikal Subversion, distribuovane VCS uz byly na svete par let.

[pavlix]

Já se sice celkem orientuju v současných opensource DVCS. Ale historii ani closed source scénu neznám. Tak proto jsem se ptal :).

Pak ale úplně nechápu tvůrce Subversion.

[Milan Jurik]

Řekl bych, že i v open source světě byl měl být znám jeden starší closed source DVCS - bitkeeper Je fakt, že setkat se s DVCS před rokem 2000 šlo asi jen ve větších korporacích, kde distribuované systémy nacházely vhodné prostředí dříve než v open source světě limitovaných přenosů dat a kapacit.

[pavlix]

Já se musím přiznat, že v roce 2000 jsem měl teprve rok připojení k Internetu. S opensource jsem se začal setkávat až díky Internetu, takže pro mě už i tohle je historie.

[trekker.dk]

i/y - jelikož jsou distribuované systémy mladší, mohli se poučit

[Luboš Doležel (Doli)]

Díky.

[nikdo]

stačí přidat slovo "vývojáři" :)

Ostatně verzovací systém je neživotný, takže se asi dost těžko mohl poučit :)

[kip]

V kapitole Trocha historie je na konci druhého odstavce "jsou kompilovány sami sebou"; mělo by být "jsou kompilovány samy sebou".

V kapitole Co jsou verzovací systémy a k čemu jsou dobré je na konci odstavce Týmová spolupráce "Odpadnou vám starosti s ... věčném otravném kopírování souborů z poštovního klienta na disk a opětové vkládání do e-mailů"; mělo by být "Odpadnou vám starosti s ... věčným otravným kopírováním souborů z poštovního klienta na disk a opětovným vkládáním do e-mailů", případně "věčné otravné kopírování souborů z poštovního klienta na disk a opětovné vkládání do e-mailů", vztahuje-li se odpadnutí pouze na starosti s přepisováním souborů na disku. Snad jsem se do toho nezamotal...

[Luboš Doležel (Doli)]

Opraveno.

[PEPP]

V zájmu objektivity mi tam chybí nejzásadnější nevýhoda, a tou je právě, že má každý celou historii - u velkého projektu to zabírá hodně místa. Stejně tak i nemožnost klonovat jen podstrom celého vzdáleného uložiště.

[Mordae]

Ne nutne, gitem muzes udelat shallow clone a vytahnout si jen n poslednich commitu. Podstromy mozne jsou, ale jen pokud je tak vytvoris a je to krapet pracnejsi. Na druhou stranu jsou udelane tak, ze muzes do sveho projektu pridat submodule z ciziho verejneho repozitare a nemusis tu historii spravovat sam.

git clone --depth 1 git://git.example.com/project.git
git submodule --help

[trekker.dk]

má každý celou historii - u velkého projektu to zabírá hodně místa

To není žádná nevýhoda. Doba 20MB disků je dávno pryč.

Stejně tak i nemožnost klonovat jen podstrom celého vzdáleného uložiště.

K čemu by to bylo dobré? Akorát by se navíc muselo řešit vyhazování diffu souborů mimo ten podstrom při synchronizaci. Zbytečná práce navíc.

[washeck]

Podívej se o pár komentářů výše. Jsou lidé, co mají repository 300 GB a to bych opravdu nemusel mít na každém notebooku.

U svn se to někdy řeší chceckoutem podstromu. U DVCS by se to asi řešilo rozdělením do více repository.

[Heron]

Ta tak. Když jsem kdysi hledal limity SVN, tak jsem narazil i na diskuse, kde chtěl někdo udělat initial import dat větších než 2TB.

[ebik]

Klonovat podstrom je obezlicka, ktera vznikla v tech VCS, kde se neni rozlisena semantika nekterych obektu. Mam na mysli branche a tagy versus podadresare v svn. To se pak zacalo vyuzivat (zneuzivat) i jinak. Vetsina distribuovanych VCS uz ma rozlisenou vetev a podadresar. Pokud ma byt neco samostatne vyvijeny projekt, tak to ma mit vlastni repozitar. Dalsi vec je i ta, ze u DVCS typu git z principu nemuzes povolit/zakazat pristup k castem stromu. Pokud nema mit k casti stromu nekdo pristup, resi se to novym repozitarem pro tu cast stromu.

Uvedu priklad: mam v archu nastaveni ssh, vcetne pomocnych skriptu. Ty skripty jsou verejne, ale to nastaveni je soukrome. Checkoutuju to dohromady, nicmene jsou to dva repozitare. Kdokoli si muze skripty checkoutovat primo ode mne, zatimco konfiguraci si nejak zajisti sam.

[pavlix]

Pokud nema mit k casti stromu nekdo pristup, resi se to novym repozitarem pro tu cast stromu.

Ono to ani jinak nemá moc smysl.

Uvedu priklad: mam v archu nastaveni ssh, vcetne pomocnych skriptu. Ty skripty jsou verejne, ale to nastaveni je soukrome. Checkoutuju to dohromady, nicmene jsou to dva repozitare. Kdokoli si muze skripty checkoutovat primo ode mne, zatimco konfiguraci si nejak zajisti sam.

Doplním vlastním příkladem. Mám systém na generování webovek (sada skriptů v AWK, která generuje makefiles a za jejich pomocí generuje celý web, momentálně přepisuju do perlu) a zdrojové soubory webovek (wiki-like formát + metadata). Typicky můžu chtít stejný systém použít v kombinaci s jinými daty a skripty zveřejnit, zdrojáky webovek není potřeba zveřejňovat :), ať se lidi podívají na výsledek.

[pavlix]

V zájmu objektivity mi tam chybí nejzásadnější nevýhoda, a tou je právě, že má každý celou historii

Nemusí mít, viz výše, ale samozřejmě obětuješ část výhod. Navíc třeba u gitu těch dat v praxi (zdrojové kódy) zase tolik není.

Stejně tak i nemožnost klonovat jen podstrom celého vzdáleného uložiště.

To není pravda, DVCS neimplikuje nemožnost klonování podstromu. Nicméně třeba git dovoluje pracovat jen s explicitně vytvořenými podstromy (submodules). Ale tak jako tak nelze přenášet vlastnost gitu na obecné omezení DVCS. Navíc i do gitu by to šlo doimplementovat, ale zřejmě o to nikdo moc nemá zájem.

[KarelI]

Moje zkusenost - working copy u svn udrzuje vlastni data + jejich kopii. Kdyz jsem prevedl asi 40k revizi do gitu, tak cela git db mela velikost asi 50% tech vlastnich dat. Cili rezie jedne kopie svn byly 2x vetsi nez cela historie (asi 5 let) v gitu! Velikost tech dat je asi 1GB, mix zdrojaku a binarek.

Podstromy jsem v svn pouzival proto, ze prace s celkem byla v svn silene pomala. V gitu to nepotrebuju.

[ebik]

No, on se navic (z dnesniho pohledu) ne moc dobry navrh snoubi s ne moc dobrou implementaci. U svn se mi obcas stalo, ze si klient mysli neco jineho nez server, a jedine, co pomuze, je udelat checkout do noveho adresare, udelat diff mezi temi adresary, aplikovat ho do toho noveho adresare a pak ten stary adresar uplne zahodit. V takovych chvilich mne svn neuveritelne stvalo. (Slo o nejake svn copy, svn delete a svn mv vhodne zkombinovane za sebou.)

[Josef Kufner]

A teď si ještě představ, že máš soubor, smažěš ho, commitneš smazání, vyrobíš nový, commitneš nový a pak chceš kouknout do historie na ten starý a ono nic. Prostě najednou ten starý není a vrátit to nejde.

[alblaho]

Díky za tu zmínku o Fossilu. Vypadá opravdu zajímavě, pro nějakou sortu projektů to může být zajímavá volba.

Jinak bez gitu si svou práci už ani neumím představit.

[Gilhad]

Ano, az kdyz jsem poznal GIT, tak mi doslo, co vsechno mi u SVN chybelo a nebo delalo zbytecne problemy. Faktem je, ze jsem se musel ten git vlastne naucit od zakladu, protoze nektere veci v nem jsou proste zamysleny jinak nez v svn a nema cenu si svazovat ruce omezenima systemu, ktery uz nepouzivam. Ale to preuceni slo velice rychle a za pochodu.

Taky v jednom projektu jsem pouzival naraz SVN (z historickych duvodu a navazane logiky) a GIT (pro vlastni vyvoj) asi pul roku paralelne. Vyvyjel jsem v gitu, s mnoha vetvema, mergovanim a vsim komfortem, do svn jsem pak vzdycky komitnul jen hotovy funkcni vysledek. Protoze se git ale osvedcil az prilis dobre, tak jsem to svn nakonec odboural a vse povesil na git. Prechod probehl naprosto bezproblemove - jednoho dne jsem si proste rekl, ze git je od ted hlavni a smazal vsechny .svn adresare a bylo.

[alblaho]

Jestli něco nesnáším, tak je to křížení gitu a svn, tomu se vyhýbám jak čert kříži

[pavlix]

Když není na výběr jestli čisté SVN nebo Git+SVN, asi bych ve většině případů ten kříž přijal.

[blabol]

Cela diskuze naznacuje, ze je tu pouze GIT. Sam jsem GIT pouzival a ma jiste sve upatneni, ale zacinajicim uzivatelum vzdy doporucuji Bazaar. Rozdily v rychlosti a velikosti metadat jsou zanebatelne pro vetsinu projektu and ziskate intuitivni multiplatformi nastroj (mimo jine s vestavenou podporou centralizovaneho pristupu).

[pavlix]

ziskate intuitivni multiplatformi nastroj (mimo jine s vestavenou podporou centralizovaneho pristupu).

Pak tedy nevidím důvod, proč ho (Git) nepoužít.

[메이저사이트]

Positive site, where did u come up with the information on this posting?I have read a few of the articles on your website now, and I really like your style. Thanks a million and please keep up the effective work. 메이저사이트