abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
dnes 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 1
dnes 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
včera 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 1
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 3
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
13.12. 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 992 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

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

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

    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

    link

    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é

    link

    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í:

    Centralizované verzovací systémy – typické uspořádání

    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

    link

    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.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    pavlix avatar 25.1.2011 01:33 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Moc pěkný úvod, těším se na pokračování.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Josef Kufner avatar 25.1.2011 01:48 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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é? ;-)
    Hello world ! Segmentation fault (core dumped)
    pavlix avatar 25.1.2011 01:51 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    25.1.2011 12:12 nou
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 12:31 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Josef Kufner avatar 25.1.2011 12:46 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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...
    Hello world ! Segmentation fault (core dumped)
    xkucf03 avatar 25.1.2011 15:56 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    25.1.2011 06:28 CET
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 07:21 Jan Marek | skóre: 16
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Příloha:
    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.
    25.1.2011 07:39 CET
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Super, diky za ten cheet sheet a pro git uz jsem taky stahnul. Tak ted budu mit aspon co cist:-)
    25.1.2011 13:11 horada | skóre: 3
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 14:05 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.)
    Hello world ! Segmentation fault (core dumped)
    25.1.2011 14:35 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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)).
    When your hammer is C++, everything begins to look like a thumb.
    Josef Kufner avatar 25.1.2011 19:07 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Ale objekt není soubor.
    Hello world ! Segmentation fault (core dumped)
    26.1.2011 09:41 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    When your hammer is C++, everything begins to look like a thumb.
    Josef Kufner avatar 26.1.2011 12:40 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    To jo, objekty ukládá do souborů, ale nějaký main.c není objektem, tím je až např. commit.
    Hello world ! Segmentation fault (core dumped)
    pavlix avatar 26.1.2011 14:35 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    25.1.2011 16:49 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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)

    USE="-gnome -kde";turris
    pavlix avatar 26.1.2011 14:36 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 :).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Josef Kufner avatar 25.1.2011 10:44 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    Hello world ! Segmentation fault (core dumped)
    wiskas avatar 25.1.2011 14:29 wiskas | skóre: 21 | blog: Raziel
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Libav developer. | The world is just a lot of people trolling each other.
    Luboš Doležel (Doli) avatar 25.1.2011 15:07 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Git si přístupová práva ukládá.
    25.1.2011 19:03 Jan Včelák | skóre: 28 | blog: Fcelda
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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) avatar 25.1.2011 22:26 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Já že tady vždycky vidím komlet práva. Takže to je vycucaný z prstu?
    26.1.2011 00:21 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    xkucf03 avatar 25.1.2011 11:37 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.).
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    pavlix avatar 25.1.2011 12:34 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    25.1.2011 15:19 KarelI
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 21:36 Andrej | skóre: 8
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    220GB na repos - to v svn simulujete mavena?
    Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
    Heron avatar 25.1.2011 08:26 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 08:52 happy barney | skóre: 34 | blog: dont_worry_be_happy
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 08:55 Michal Vyskočil | skóre: 60 | blog: miblog | Praha
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    When your hammer is C++, everything begins to look like a thumb.
    25.1.2011 09:44 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    25.1.2011 09:24 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 09:55 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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.

    25.1.2011 10:17 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    25.1.2011 10:22 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 10:24 washeck | skóre: 4
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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.

    25.1.2011 12:20 Program
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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...
    25.1.2011 12:58 washeck | skóre: 4
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 13:22 Program
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 14:07 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Btw, git je na tom stejně a skládání repositářů dohromady řeší pomocí submodulů (dobré na knihovny a podobně).
    Hello world ! Segmentation fault (core dumped)
    25.1.2011 10:36 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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 avatar 25.1.2011 11:54 mkoubik | skóre: 5 | blog: lorem_ipsum | Praha 8 - Bohnice
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 13:04 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Josef Kufner avatar 25.1.2011 14:14 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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ě.
    Hello world ! Segmentation fault (core dumped)
    25.1.2011 13:31 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 09:37 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    Josef Kufner avatar 25.1.2011 10:55 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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á.
    Hello world ! Segmentation fault (core dumped)
    Heron avatar 25.1.2011 11:00 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 11:42 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Aha, no to pak máš smůlu :-D
    Hello world ! Segmentation fault (core dumped)
    mkoubik avatar 25.1.2011 11:56 mkoubik | skóre: 5 | blog: lorem_ipsum | Praha 8 - Bohnice
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Pokud odt rozbalíš (je to zip), tak dostaneš adresář plný xml souborů, obrázků atd. Ten už verzovat a mergeovat půjde.
    Heron avatar 25.1.2011 12:17 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    To vím, že to je zip, ale tohle nemyslíš vážně :-D
    Josef Kufner avatar 25.1.2011 12:54 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Hehe, tohle mě napadlo taky a přesně takovouhle reakci jsem čekal. :-D
    Hello world ! Segmentation fault (core dumped)
    mkoubik avatar 25.1.2011 15:42 mkoubik | skóre: 5 | blog: lorem_ipsum | Praha 8 - Bohnice
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 15:45 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 16:40 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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).
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    Petr Tomášek avatar 25.1.2011 17:41 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 14:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 26.1.2011 14:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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?
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 25.1.2011 13:09 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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šší.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Petr Tomášek avatar 25.1.2011 15:26 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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...
    25.1.2011 16:13 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    '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 avatar 25.1.2011 16:33 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Jenže SVN to už má v sobě, chápeš?
    29.1.2011 10:09 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Ale ta implementace je takova, ze bych se s ni nechlubil. Chapes?
    xkucf03 avatar 25.1.2011 16:24 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    pavlix avatar 25.1.2011 16:39 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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ší.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Petr Tomášek avatar 25.1.2011 17:38 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    25.1.2011 21:20 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    pavlix avatar 26.1.2011 14:46 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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é.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 25.1.2011 12:41 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Petr Tomášek avatar 25.1.2011 15:29 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    opravíš případné konflikty (stejně jako v SVN)
    Akorát je šance, že těch konfliktů bude u SVN míň...
    25.1.2011 16:17 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 16:37 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Jistě, ale to záleží právě na charakteru změn, jejich počtu a počtu autorů...
    pavlix avatar 26.1.2011 14:47 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Jistě, ale to záleží právě na charakteru změn, jejich počtu a počtu autorů...

    Spíš jenom na charakteru změn.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 25.1.2011 16:44 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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ě.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Petr Tomášek avatar 25.1.2011 17:36 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    To je ideologický blábol.
    Josef Kufner avatar 25.1.2011 19:16 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Proč?
    Hello world ! Segmentation fault (core dumped)
    Petr Tomášek avatar 26.1.2011 11:52 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Protože neposkytuje žádné rozumné argumenty...
    pavlix avatar 26.1.2011 14:49 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Protože neposkytuje žádné rozumné argumenty...

    Taky jsem na žádné rozumné argumenty neodpovídal.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 26.1.2011 14:48 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Petr Tomášek avatar 25.1.2011 17:39 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Když si jednou zvykneš, už se nebudeš chtít nikdy vrátit k centralizovaným.
    To je teda argumentace jako z reklamy na jogurty...
    25.1.2011 21:21 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    No na poli argumentace jsi se zatím taky moc nepředvedl, takže bys za to neměl kritizovat jiné...
    Quando omni flunkus moritati
    Petr Tomášek avatar 26.1.2011 11:45 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í...
    26.1.2011 12:02 mnn | skóre: 1
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 14:56 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 26.1.2011 14:51 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 25.1.2011 12:43 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Josef Kufner avatar 25.1.2011 12:58 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Akorát když pak někdo chce použít bisect, tak z toho nebude moc nadšený...
    Hello world ! Segmentation fault (core dumped)
    pavlix avatar 25.1.2011 13:17 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    Bilbo avatar 25.1.2011 23:18 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 ....)
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    Josef Kufner avatar 25.1.2011 23:44 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Hello world ! Segmentation fault (core dumped)
    Bilbo avatar 25.1.2011 23:56 Bilbo | skóre: 29
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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)
    Big brother is not watching you anymore. Big Brother is telling you how to live...
    Josef Kufner avatar 25.1.2011 23:59 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Jak jsem říkal, ty původní commity se nijak nemění.
    Hello world ! Segmentation fault (core dumped)
    26.1.2011 00:25 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    Josef Kufner avatar 26.1.2011 00:48 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 ;-)
    Hello world ! Segmentation fault (core dumped)
    26.1.2011 00:53 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Ach tak. Dík za info.
    Quando omni flunkus moritati
    pavlix avatar 26.1.2011 14:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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).
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    26.1.2011 16:07 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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...
    Quando omni flunkus moritati
    26.1.2011 16:26 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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í.
    Ještě na tom nejsem tak špatně, abych četl Viewegha.
    26.1.2011 17:25 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 18:07 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Hello world ! Segmentation fault (core dumped)
    26.1.2011 18:39 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 19:02 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Na tohle bych asi použil --amend už v průběhu tvorby. Poslední commit by prostě pozvolna rostl...
    Hello world ! Segmentation fault (core dumped)
    26.1.2011 19:13 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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)
    26.1.2011 19:15 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    24.2.2011 21:58 diacone
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    Myslim, ze vhodny je merge:

    git merge --no-ff --no-commit --log vetev
    git commit -e
    xkucf03 avatar 25.1.2011 16:21 xkucf03 | skóre: 46 | blog: xkucf03
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Š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.
    Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-Výuka.cz, Nekuřák.net
    25.1.2011 09:15 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 14:58 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Můžete doplnit. Jinak nemám pocit, že by Franta tvrdil, že historie začíná u Subversion.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    27.1.2011 23:38 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 27.1.2011 23:56 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    28.1.2011 16:09 Milan Jurik | skóre: 21 | blog: Komentare | Ova
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Ř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 avatar 28.1.2011 16:24 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    25.1.2011 09:38 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    i/y - jelikož jsou distribuované systémy mladší, mohli se poučit
    Quando omni flunkus moritati
    Luboš Doležel (Doli) avatar 25.1.2011 09:51 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Díky.
    25.1.2011 10:12 nikdo
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    stačí přidat slovo "vývojáři" :)

    Ostatně verzovací systém je neživotný, takže se asi dost těžko mohl poučit :)
    25.1.2011 10:03 kip | skóre: 8 | blog: kip | Nový Jičín
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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) avatar 25.1.2011 10:22 Luboš Doležel (Doli) | skóre: 98 | blog: Doliho blog | Kladensko
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Opraveno.
    25.1.2011 10:05 PEPP
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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ě.
    25.1.2011 10:20 Mordae
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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
    25.1.2011 10:22 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Quando omni flunkus moritati
    25.1.2011 10:31 washeck | skóre: 4
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 10:35 Heron | skóre: 51 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 10:53 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)

    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 avatar 25.1.2011 13:16 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    pavlix avatar 25.1.2011 12:49 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    25.1.2011 15:14 KarelI
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    25.1.2011 16:25 ebik
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 25.1.2011 23:48 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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.
    Hello world ! Segmentation fault (core dumped)
    alblaho avatar 25.1.2011 10:37 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Zaujal mě Fossil
    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.
    26.1.2011 17:36 Gilhad | skóre: 20 | blog: gilhadoviny
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    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 avatar 26.1.2011 23:13 alblaho | skóre: 17 | blog: alblog
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Jestli něco nesnáším, tak je to křížení gitu a svn, tomu se vyhýbám jak čert kříži:-)
    pavlix avatar 27.1.2011 00:10 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Distribuované verzovací systémy – úvod (1)
    Když není na výběr jestli čisté SVN nebo Git+SVN, asi bych ve většině případů ten kříž přijal.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.
    29.1.2011 13:58 blabol
    Rozbalit Rozbalit vše Bazaar
    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 avatar 29.1.2011 15:40 pavlix | skóre: 54 | blog: pavlix
    Rozbalit Rozbalit vše Re: Bazaar
    ziskate intuitivni multiplatformi nastroj (mimo jine s vestavenou podporou centralizovaneho pristupu).

    Pak tedy nevidím důvod, proč ho (Git) nepoužít.
    Já už tu vlastně ani nejsem. Abclinuxu umřelo.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.