Jan "Yenya" Kasprzak o Gitu

26. 6. 2009 | Lukáš Helebrandt | Rozhovory | 7633×

V několika odpovědích nám Jan "Yenya" Kasprzak, jedna ze zakládajících osobností české linuxové scény, představí distribuovaný verzovací systém Git. Rozhovor proběhl na základě jeho přednášky na 34. konferenci EurOpen.CZ.

Jan "Yenya" Kasprzak: osobní web.

1) Mohl by ses představit našim čtenářům? Podílíš se na nějakých open source projektech?

Jsem dlouholetý uživatel Linuxu (někdy od verze 0.99.11) a obecně se o UNIX a jemu podobné systémy zajímám už od doby, kdy jsem se o jejich existenci dozvěděl. Podílel jsem se na založení CZLUGu a pod jeho hlavičkou jsem spolupořádal několik konferencí. Starám se o datový archív ftp.linux.cz a listserver linux.cz, kde je také český mailing list o Linuxu. Kromě této podpory komunity mám ještě několik menších softwarových projektů jako například program mrtg-rrd.cgi, což je grafický front-end pro MRTG, nebo ovladač pro synchronní sériové karty COSA pro Linux.

V současné době je můj čas poměrně dobře vyplněn jak mým zaměstnáním ve vývojovém týmu Informačního systému Masarykovy univerzity, tak výukou UNIXu na univerzitě, ale i mojí rodinou. Takže nemám ambice zakládat další open source projekty. Snažím se komunitě pomoci aspoň důsledným hlášením problémů na které narazím a také ujištěním se, že Linux funguje na každém hardwaru, se kterým se setkám. Myslím, že pořád není dostatek uživatelů, kteří jsou ochotni hlásit chyby a přitom jsou schopni smysluplně reagovat na následné dotazy vývojářů.

Mimo obor mě baví fotografování a mám snahu naučit se japonsky.

2) V jakém projektu ses ty poprvé setkal s Gitem?

V jádře Linuxu, samozřejmě. Protože mě problematika verzovacích systémů vždy zajímala, sledoval jsem pozorně, jak vývoj situace v období, kdy Linus začal používat BitKeeper (Wikipedia: BitKeeper History), tak i okolnosti vzniku Gitu samotného.

3) Můžeš nám Git ve zkratce představit?

Dnes je Git plnohodnotný verzovací systém s dobře napsanou dokumentací i různými tutorialy. Původě byl ale navržen jako databáze adresovatelná podle obsahu: Uživatel dá SHA-1 hash a dostane soubor s tímto hashem. Jednoduchá a geniální myšlenka (mimochodem převzatá ze systému Monotone). Snímek projektu v určitém okamžiku je pak možno popsat textovým seznamem jmen souborů a SHA-1 hashů jejich obsahů v tom okamžiku. SHA-1 hash tohoto seznamu je vlastně celosvětově jednoznačný popis stavu projektu v daném čase. Trochu jsem to zjednodušil, ale toto je hlavní myšlenka.

Nad touto databází je pak postavený celý distribuovaný verzovací systém.

4) Jaké jsou největší výhody distribuovaného systému?

Asi největší výhoda je ta sociální: Každý klon repozitáře je plnohodnotný, a není tedy problém, aby pár lidí začalo mezi sebou spolupracovat na vývoji nové vlastnosti nějakého většího projektu a přitom využívat všech výhod verzovacího systému. Nepotřebují souhlas nebo udělení oprávnění ze strany správců toho projektu. Čili odpadá politika typu „já jsem člen core teamu a mám právo commitu, zatímco ty ne“, a naopak se snižuje vstupní bariéra pro nové vývojáře.

Distribuovaný model také lépe škáluje. Projekt velikosti jádra Linuxu by prostě s centralizovaným systémem nemohl fungovat.

Zajímavou vlastností v podstatě všech distribuovaných verzovacích systémů je, že repozitář může být aspoň pro čtení reprezentován statickými soubory zveřejnitelnými přes HTTP nebo FTP. To znamená, že se sníží závislost na centrálních systémech typu SourceForge: Ke zveřejnění svého repozitáře je třeba jen přístup k libovolnému webhostingu.

Výhod je více, uvedu ještě jednu: Vestavěnou vlastností distribuovaných verzovacích systémů je snadné slučování větví. Kdo někdy zkoušel například v CVS pracovat s větvemi, dá mi za pravdu, že jakmile rozvětvíte, už nikdy rozumně nesloučíte. Čili větve jsou tam použitelné tak maximálně pro oddělení stabilní a vývojové verze. Distribuované systémy si pamatují, co a kam sloučily, takže není problém tutéž větev sloučit podruhé, případně ji sloučit do více jiných větví (například jistou paralelně vyvíjenou vlastnost promítnout jak do stabilní, tak do vývojové verze).

5) Co bys vypíchl jako „killer feature“ Gitu?

Pro ty, kdo nikdy nepracovali s distribuovaným verzovacím systémem, je jistě killer feature ona distribuovanost. Sice nějakou dobu trvá, než se člověk s distribuovaným modelem vnitřně ztotožní, ale výhody jsou jednoznačné.

Pokud jde o Git versus jiné distribuované verzovací systémy, je killer feature určitě důraz na čitelnost záplat. Git (i vývojový model Linuxu) je postavený na tom, že produktem není jen čitelný kód, ale i čitelná a srozumitelná cesta, jak jsme se k tomu výslednému kódu dostali. Je snaha, aby verze (commit) nebyla „to, co jsem za dnešek vykódoval“, ale malé logické celky typu „oprava té a té manuálové stránky“ nebo „přidání toho a toho parametru do funkce a všech volání této funkce“.

Toto Git všemožně podporuje. Jde například o možnost kdykoli změnit nebo upravit commit, ve kterém jsem našel neoptimálnost (git-commit --amend), nebo odložit svou práci, udělat někde jinde triviální opravu a pak se k rozdělané necommitnuté práci vrátit zpět (git-stash). Dále je zde možnost přesunout své commity tak, jako by vycházely z jiné základní verze (git-rebase). Čitelnosti vývoje také napomáhá snadná práce s větvemi. Git vývojáři umožní mít nikoliv jednu větev pro celou svoji vývojovou práci, ale vytvářet tzv. feature-specific branches: Každou logicky oddělenou vlastnost mít v samostatné větvi. To umožní správci projektu převzít od vývojáře třeba jen ty vlastnosti, které se mu líbí. Není tak v komunikaci s vývojářem omezen na „převzít všechno nebo nic“.

6) Existují nějaké nevýhody?

Jak jsem říkal, pochopení distribuovaného přístupu vyžaduje jisté mentální úsilí, zvláště pokud člověk předtím vždy pracoval s centralizovaným systémem.

Jistou nevýhodou je také práce s modulárními projekty, kdy do svého repozitáře chci například zařadit nějakou část (typicky knihovnu) vyvíjenou samostatně. Git moduly podporuje, ale tato podpora není nijak zvlášť elegantní.

Po mé přednášce na konferenci EurOpen.CZ padl dotaz na začlenění do různých grafických vývojových prostředí. Tímto si nejsem jistý, ale je možné, že podpora nebude ještě úplně dokonalá.

7) Vymizí někdy centralizované verzovací systémy?

V dnešní době je absolutní nesmysl začínat nový projekt s centralizovaným verzovacím systémem. Nicméně myslím, že i tak se na existujících (hlavně closed source) projektech tyto systémy udrží ještě dlouho. Nejspíš ale bude docházet k tomu, že vývojáři budou „potají“ používat distribuovaný systém a navenek své změny promítat do centralizovaného repozitáře. Například Git má dobrou podporu pro práci se Subversion repozitářem. A skutečně, programátoři v mnoha firmách přiznávají, že převést si vše do Gitu a interně pracovat v něm je pro ně snazší.

8) Říkáš, že spravuješ mailing list o Linuxu. Je nějaký rozdíl mezi mailing listy a webovými diskusemi?

Popularita mailing listů byla v minulosti jistě větší. Například list o Linuxu měl nejvíc okolo 1100 uživatelů a přes sto příspěvků denně, zatímco teď má jen něco přes 700 čtenářů a okolo deseti příspěvků denně. Přijde mi ale, že kvůli vyšší vstupní bariéře (obvykle nutnost přihlásit se před tím, než je možno poslat příspěvek) bývá diskuse na vyšší úrovni.

Diskutujícím ve webových diskusích bych chtěl vzkázat: Nebuďte tak konzervativní! Přijde mi podivné, jak se s každou novou vlastností open source softwaru najdou spousty názorů typu „co si to zase vymysleli za novotu, vždycky to přece fungovalo tak a tak a stačilo to“. Před pár roky bylo moderní takto nadávat na udev, HAL a D-Bus, dneska je v podobné situaci například PulseAudio.

Přitom mnohdy si lidé neuvědomí, že buďto pláčou na nesprávném hrobě (u PA je často na vině flashplayer, který zablokoval zvukovou kartu, případně jistá distribuce nemající preemptivní kernel), anebo že věci, nad které jsou oni povzneseni, mnoho jiných lidí ocení (abych zůstal u příkladu PA, tak třeba přesměrovávání zvukových výstupů za běhu, případně ovládání hlasitosti celého zvukového řetězce jediným prvkem uživatelského rozhraní).

Ale to je asi vlastnost tohoto oboru – každý, kdo aspoň trochu s něčím příbuzným přišel do styku, má pocit, že on tomu rozumí nejlépe. Vždycky se najdou lidé, kteří jsou přesvědčeni, že kdyby měli jen týden času, tak určitě napíšou správu zvukových karet nebo třeba informační systém univerzity výrazně lepší, než je stávající. Čtenáři to jistě znají sami :-)

Díky za rozhovor.

Bylo mi potěšením.

       

Komentáře

[eoj]

Čtu a najednou už je konec, jako by tomu něco chybělo.

[Lukáš Zapletal]

Třeba poděkování za pěkný rozhovor/článek?

[eoj]

Ne, poděkování za rozhovor tam je...

[a]

treba nebylo

[zoul]

V dnešní době je absolutní nesmysl začínat nový projekt s centralizovaným verzovacím systémem.

Tohle je trochu přísný. Podle mě existuje fůra projektů, pro které může být Subversion mnohem praktičtější než kterýkoliv ze současných distribuovaných systémů. Kvůli slušným grafickým frontendům, bezproblémové integraci do dalších programů, centrálnímu zamykání a podobně. Sám nad naším repository používám git-svn a jsem za něj moc rád – momentálně především díky offline commitům – ale takhle jednoznačné to určitě není.

[Peto]

Zavisi na tom, aky je to projekt, Ak vyvojarinepracovali so ziadnym systemom spravu verzii je lepsi centralizovanay tak isto na hodnotenie studentskych projektov v dvojiciach je lepsi centralizovany system. Ale ak je viac nez 5 ludi v teame distribuoavany system je lepsi...

[Yenya]

Koukam ze jsem to nevysvetlil uplne dobre: i distribuovany verzovaci system muzete pouzivat centralizovane a pro nektere typy vyvoje (jako treba ty co zminujete) nema absolutne smysl delat nejaky dalsi repozitar krome centralniho a pak osobni repozitar kazdeho vyvojare s jeho pracovni kopii, odkud treba pres push promita zmeny do centra.

Ale i v tomto pripade ziskate, pokud budete pouzivat distribuovany verzovaci system centralizovane, nez kdybyste pouzivali centralizovany verzovaci system. Veci jako feature-specific branches, spekulativni vetve pro experimenty, citelne commity, rozdeleni operace "commit" zname z centralizovanych systemu na dve operace (commit a obvykle push), vsechno tohle je pridanou hodnotou oproti centralizovanemu VCS. Jako velmi rychly uvod je mozne pouzit treba stranku gitcvs-migration.

-Yenya

[Leoš Literák]

Ja mam stale zminovany mentalni blok, abych pochopil ty distribuovane systemy. Chapu vyhody na strane developera. Ale jak to je centralni spravou? Kdyz si kazdy ve sve vetvi commituje, co chce, jak se to dostane do te jedne, oficialni, ze ktere se delaji oficialni buildy? To delaji ti programatori nebo admin centralni repozitore?

[zoul]

Viděls’ Linusovu přednášku o gitu? Tam celkem zajímavě vysvětluje, jak díky distribuovanému modelu krásně škáluje vývoj jádra. Linus merguje do hlavního stromu kód od pár lidí, kterým důsledně věří, tyhle lidi mergují kód od dalších pár důvěryhodných lidí, a tak dále. Takže do „oficiální větve“ může mergovat kdokoliv, záleží na dohodě. Technicky se to dá ohlídat snadno třeba přes SSH key-auth.

[Yenya]

Muze byt i tak i tak.

Budto vyvojar muze delat push do centra, pak je to podobne jako treba u SVN: zkusim push, kdyz push udelal do teze vetve driv nekdo jiny, musim udelat pull, merge a push (podobne jako u SVN delam commit, ten selze, musim udelat update a commit). Akorat u Gitu tohle na rozdil od SVN nemusim delat pokud kdokoli jiny udela commit, ale jen pokud udela commit/push do vetve, kterou se ja taky snazim pushnout ven.

Anebo jsou vyvojari a nejaky supervisor toho projektu, a vyvojar rekne "hele, implementoval jsem to a to, prosim vezmi si 'git://server/vyvojaruvrepozitar.git tahlevetev'", a spravce se rozhodne jestli to chce nebo ne.

Anebo muze byt kmbinace obojiho, ze "spravce" (release engineer?) ma jednu vetev, ostatni pushuji svoji praci do svych feature-specific branches v centralni repository, a spravce jen dela merge tech vetvi ktere se mu libi do sve "release candidate" vetve.

-Yenya

[Filip Jirsák]

Obojí je možné. Buď dáš vývojáři práva commitu do nějaké centrální repository, pak to může udělat sám, nebo chceš všechny patche kontrolovat, pak mu práv anedáš a on ti jen posílá balíky patchů. Ty si ale uvnitř udržují svoji historii, takže když to promítneš do centrálního repository, pořád tam budou vidět jednotlivé commity toho původního vývojáře, a můžeš třeba jeden commit z toho balíku odmítnout ještě před přidáním, nebo revertovat později, případně aplikovat na jiný strom. Mercurial má dokonce popsané tři způsoby použití (třetí je ještě model vývoje linuxového jádra, kdy není jeden správce, ale je to hierarchie stromů).

[Filip Jirsák]

Grafické frontendy, podpora IDA a dalších programů – to beru )ale bude se to postupně zlepšovat). Centrální zamykání ale není výhoda centralizovaných VCS. To samé můžete udělat i s distribuovaným VCS – prostě si uděláte kopii stromu, a do té vám nikdo nic nedá.

[zoul]

Centrální zamykání ale není výhoda centralizovaných VCS. To samé můžete udělat i s distribuovaným VCS – prostě si uděláte kopii stromu, a do té vám nikdo nic nedá.

Úplně totéž to není. Například u binárek (dejme tomu obrázků) je podle mě dobrý, když si je člověk může opravdu zamknout, protože nejdou kloudně mergovat. V Subversion si můžu nastavit, že všechny soubory s příponou PNG vyžadují zámek. V pracovní kopii jsou takové soubory označené jako read-only, dokud si je přes Subversion nezamknu. Pak je mnohem těžší dojít ke konfliktu, který je u binárek nepříjemný. Pokud tomu dobře rozumím, v DCVS dostanu konflikt s křížkem po funuse při mergování. Nicméně chápu, že tohle většinu lidí nebolí. (Mě taky ne, mluvím o tom jen pro zajímavost.)

[Filip Jirsák]

Jenže u CVCS tu binárku zpravidla zamknete zbytečně při zamčení celého stromu. Pokud je potřeba někdy výjimečně zamknout binárku, asi je jednodušší se na tom domluvit s lidmi, kteří by ji mohli změnit. A pokud je potřeba to dělat často, asi není VCS založený na textových diffech to pravé.

[zoul]

Jenže u CVCS tu binárku zpravidla zamknete zbytečně při zamčení celého stromu.

Nerozumím. Subversion umí zamykat jednotlivé soubory.

Pokud je potřeba někdy výjimečně zamknout binárku, asi je jednodušší se na tom domluvit s lidmi, kteří by ji mohli změnit.

Binárky v repository jsou u některých projektů naprosto běžný jev, například grafické podklady pro web nebo hry. Pak je určitě příjemné mít možnost zařídit zamykání přímo softwarem.

A pokud je potřeba to dělat často, asi není VCS založený na textových diffech to pravé.

Při vší úctě, tohle už nezní jako konstruktivní argument.

[Filip Jirsák]

Nerozumím. Subversion umí zamykat jednotlivé soubory.

Jenže zpravidla se používá zamčení celého stromu, protože je to jednodušší než dělat třeba branch pro build.

Binárky v repository jsou u některých projektů naprosto běžný jev, například grafické podklady pro web nebo hry. Pak je určitě příjemné mít možnost zařídit zamykání přímo softwarem.

Pak se ale buď VCS používá pouze jako úložiště těchto binárek, a nějaké mergování nemusím řešit, prostě platí poslední verze. A nebo chci plnou podporu VCS i nad binárkami, a pak asi není moc rozumné používat VCS, který s binárkami pracovat vlastně neumí.

Při vší úctě, tohle už nezní jako konstruktivní argument.

Co je na tom nekonstruktivního? Prostě když je nějaký nástroj na danou činnost nevhodný, je na ní nevhodný a není to jeho chyba, ale chyba toho, kdo se ho snaží takhle použít. Když se někdo pokusí malovat obrázky ve vimu a bude si stěžovat, že to jde ve vimu špatně, není to chyba vimu, ale dotyčného „grafika“. Stejně tak když se někdo pokusí použít VCS pro textové soubory na binární soubory, nemůže si stěžovat, že to funguje špatně.

[zoul]

Co je na tom nekonstruktivního?

Srovnáváme výhody decentralizovaných a centralizovaných verzovacích systémů. Já říkám, že výhodou centralizovaných systémů může být výhradní zamykání souborů, které předchází neřešitelným konfliktům [a které se bez centrální autority neobejde]. Ty říkáš, že pokud někdo potřebuje často zamykat binárky, měl by si pořídit úplně jiný verzovací systém. Přijde mi to nefér, protože když se nabízí Subversion jako celkem přijatelné řešení problému, označíš tenhle problém za něco patologického, co by se stejně mělo řešit jinak. ¶ Myslím, že všechny užitečné argumenty už zazněly, takže bych to s dovolením nechal být :)

[zoul]

Ještě, pardon:

Pak se ale buď VCS používá pouze jako úložiště těchto binárek, a nějaké mergování nemusím řešit, prostě platí poslední verze.

Mergování řešit musím. Grafik A si otevře soubor, začne pracovat. Ještě před commitem si grafik B otevře tentýž soubor a začne taky pracovat. Pokud grafik B udělá netrivální kus práce a grafik A mezitím commitne, B je v rejži. Výhradní zámky tenhle problém spolehlivě řeší: Grafik A si soubor zamkne a pokud se grafik B pokusí udělat totéž, verzovací systém mu zámek nedá. Distribuované systémy problém neřeší, konflikt jen odloží na později.

[Filip Jirsák]

V tomhle případě je ale podle mne opravdu nevhodné používat VCS založený na mergování textových souborů – a je jedno, zda je to Git nebo Subversion. Že zrovna Subversion se umí trochu přizpůsobit i tomuto nevhodnému způsobu využití mi nepřipadá jako jeho plus – je to stejné, jako kdyby vim podporoval editaci obrázků o něco lépe, než jiné textové editory. Úplně stejný problém totiž nastane, pokud grafik A udělá změnu v branchi a grafik B v headu – a tam už zámky nic nevyřeší. Takže pro tenhle případ bych opravdu raději použil nějaký VCS, který není postaven na předpokladu, že se konfliktní změny (textově) mergují, ale na předpokladu, že se konfliktním změnám musí předcházet.

[zoul]

Úplně stejný problém totiž nastane, pokud grafik A udělá změnu v branchi a grafik B v headu – a tam už zámky nic nevyřeší.

To je pravda, to je dobrá připomínka. Ony se samozřejmě dají napsat skripty pro zamknutí souboru na více větvích, ale to už jsme na velmi, velmi tenkém ledě.

[Filip Jirsák]

Pak by to dopadlo takhle nějak

[Lukáš Benda]

No na starem projektu sme meli konstanty definovane v XSL souboru ze ktereho se pak generoval pomoci maker java kod a SQL dotazy do databaze.

Tento XSL soubor musel byt pred upravou zamknut. A samozrejme kdyz ho nekdo chtel upravit a mela-li se zmena promitnout do vice vetvi, musel pozamykat soubor ve vsech vetvich a upravit vsechny soubory rucne.

Nicmene takovy soubor byl v cele aplikaci jediny.

A tento jediny soubor zapricinil ze pri prechodu z CVS -> jinam, bylo rozhodnuti ucineno ve prospech SVN, protoze distribuovane systemy neumi tento jediny soubor zamknout.

Opravdu si ale take myslim, ze problem nelezel na strane VCS, ale proste v tom, ze vedeni projektu neumelo udelat rozhodnuti, kterym by prevedla XSL do XML, coz je pomerne trivialni zalezitost a vsechny podobne problemy se zamykanim binarky by odpadly.

[Filip Jirsák]

Předpokládám, že šlo o XLS (Excel), a ne XSL (eXtensible Stylesheet Language).

[Leoš Literák]

XSL jako generator kodu jsem uz videl,ale  XLS si nedovedu predstavit.

[bibri]

>Myslím, že pořád není dostatek uživatelů, kteří jsou ochotni hlásit chyby a přitom jsou schopni smysluplně reagovat na následné dotazy vývojářů.

+1 - tesat do kamene.

[Lukáš Zapletal]

Vše nejlepší ke včerejšímu svátku...

[Jakub Lucký]

Bohužel, já se v Debianu spíš setkávám s opakem...

No developer on the other side of bugtracking system...

Už těch bugů mám nahlášených docela dost, ale často se mi ani nedostane strohé odpovědi jako: Can't reproduce, fixed in upstream...

pár příkladů: #500829 #484284 #510917 #518830 #533163

Některé možná nejsou nareportované dokonale, neboť nejsem vývojář a nevím, co všechno může takový Cčkař potřebovat ke štěstí, nicméně mi není zatěžko přidat libovolné informace... A na ty se nikdo neptá... A tak hnijí některé bugy i 5 let...

[David Jaša]

Bohužel, já se v Debianu spíš setkávám s opakem...

Ubuntu, stejná zkušenost. Bohužel...

[User682]

zdravim,

pridam komentar a trocha zamysleni.

O git-u jsem cetl dost clanku. Sam jej pouzivam u jednoho projektu na vyvoj. Ve firme se git pouzival. Na nektere veci velmi uspesne. Ma to ale dost much.

Ono dneska vetsina lidi propaguje nejaky server a konsolove rozhrani. Vyjimecne samostatnou aplikaci.

To, co ale chybi je uplna podpora do IDE. Pro me specielne pluginy do Eclipse nebo NetBeans nebo dalsich podobnych. Ono neco jiz je, ale neni to uplne.

A mam pocit, ze pokud toto nebude v nejakem prijatelnem stavu, tak bude git pouze nastroj nebo hracka pro par adminu, par programatoru delajicich v konsoli. Delat vetsi projekt v radu jednotek ci desitek MB zdrojaku, tak to proste rozumne nejde. Zejmena pak neco mergovat. Samozrejme, ze to pujde, ale s vyssimi naroky na cas a s vetsim poctem chyb.

Git je skvely pocin a v urcitych smerech je velmi dobre projektove rizen. Ale lepsi funkcionalitu mi nabizi Subversion a moduly/pluginy k ni.

Nekdy mam pocit, ze vyse popsane hodne lidi nechape.

Kdyz jsme u tematu: funkcni plugin pro git do Eclipse, existuje ? Bud zdarma nebo do 250$.

 

[Jakub Lucký]

http://git.or.cz/gitwiki/EclipsePlugin

Evidentně se na něm pracuje...

[Vladimir Kralik]

Moja evolucia je SCCS -> CVS , prechod do inej firmy, ktora pouzivala Visual Source Safe, utek naspat do CVS ( aj za cenu, ze server a infrastrukturu okolo som si vybudoval sam bez podpory systemoveho oddelenia.)

Teraz ma tlacia na prechod do SVN ako firemneho standardu ( medzitym im doslo ze Visual Source Safe nie je to prave orechove ), mne sa vsak do toho nechce, pretoze mi to neprinasa nic podstatne.

Velmi pokukujem po Mercurial ( http://mercurial.selenic.com/wiki/ ).

Je to distribuovany VCS, ma to prikazovy riadok, GUI pre Windows ako aj plugin do Eclipse.

A najma to ma podporu pre obchodny model vydavania verzii, ktory po nas vyzaduje zakaznik.

Prechod je vsak este dost vzdialeny, uvidim ako to dopadne.

 

[Pepa]

Mercurial pouzivame uz dlouho. Je to asi hodne podobne git-u. Proc vlastne psali git, kdyz uz existoval mercurial?

 

[zoul]

Pokud si dobře vzpomínám, Linus říkal, že je na tom Mercurial dost špatně s výkonem.

[Yenya]

Tady pisou, ze hg byl oznameny o 5 dni pozdeji nez git. Pro nekoho kdo zna jen centralizovane systemy asi moc rozdil nebude - prechod na distribuovany je urcite nejvetsi zmena. Jinak je podle me hlavnim rozdilem prace s vetvemi, ktera je v Gitu vyrazne jednodussi. V hg nejsou vetve uplne "first-class citizen". Na druhou stranu se rika (nevim, nezkousel jsem, klidne to muze byt urban legend) ze hg ma intuitivnejsi prikazy: v gitu napriklad push neni pravym opakem pull, podobne add neni opakem rm.

-Yenya

[Lukáš Zapletal]

Zajímalo by mě -- jak často se vyskytují konflikty? To není opravdu na světě jediné verze souboru, který by měl stejný hash? Jde mi čistě o praktický pohled...

[linear]

 ono se to obvykle pocita tak ze kdyby vsichni lide na svete denne vygenerovali kazdy x (napr. 100) hashu v ramci stejneho projektu a nahodny konflikt nastal jeden za y let (napr. milion), tak je hash povazovan za dostatecne neprustrelny. Teoreticky ale konflikt nastat muze, holt se jednou (mozna za nekolik milionu let) Linus stim bude muset poprat a nikdo nebude chapat co se stalo a jak

[Lukáš Zapletal]

No ale dneska se spoustu zdrojáků různě generuje z jiných... dobrá tedy. Spokojím se s tvrzením, že to prostě není statisticky možné.

[M. Lox]

Možná zkus vyhledat něco z historie ReiserFS – tam se dřív používala hashovací funkce Rupasov, která byla vhodná díky tomu, že podobné soubory měly podobné hashe, ale kvůli častým kolizím se muselo přejít (v jedné z prvních verzí, už je to dost dávno, snad ještě před začleněním) na vylepšenou funkci r5.

[zoul]

Ono je dobrý si uvědomit, že se v tomhle případě bavíme o kolizi heší dvou smysluplných souborů, která je mnohem méně pravděpodobná než uměle vytvořená kolize dvou pečlivě vygenerovaných náručí binárního smetí. Onehdy jsem přesně tohle googloval a našel jsem zajímavý post v archivech gitu.

[Cohen]

Už z principu fungování hashování ke kolizi pochopitelně dojít může (výstupem hashovací funkce je řetězec pevné délky, vstup přitom může být libovolně dlouhý (pomineme-li technické detaily)), ale pravděpodobnost, že na dva soubory se stejným hashem narazíte (u dostatečně kvalitních hashovacích funkcí) je strašně malá (např. SHA-1 má výstup 160 bitů dlouhý, tzn. je tu 2¹⁶⁰ různých možností, jak se vstup zahashuje – uvědomte si, že 2¹⁶⁰ je strašlivě obrovské číslo, a přitom komu by přece jen nestačilo, může použít např. SHA-512 s 512bitovým výstupem, tzn. s 2⁵¹² různými možnostmi, na které vstup mapovat).

Ostatně na nepravděpodobnost kolizí kvalitních hashovacích funkcí se spoléhá u digitálního podepisování. Nikdy se nepodepisují samotná data (asymetrická kryptografie je velice pomalá), ale jen jejich hash. Daný podpis tedy platí pro libovolná data se stejným hashem. I přesto se digitálnímu podpisu věří např. v bankovnictví atd.

[Lukáš Zapletal]

Já sám jsem uživatel a propagátor (de)centralizovaného Bazaaru, ale po přečtení rozhovoru mi nesedí jedna věc: V dnešní době je absolutní nesmysl začínat nový projekt s centralizovaným verzovacím systémem.

V komerční sféře je vždy silný tlak na centralizaci, a to i/hlavně v softwarových firmách. Administrátoři chtějí mít vše pod kontrolou (nezpečnost, zálohování), to platí dvojnásob u know-how softwarové firmy (zdrojové kódy, knihovny). Ačkoli decentralizované systémy umožňují jistým způsobem centralizovat (ukládat kopie hlavních větví na jednom místě za účelem kontroly a zálohování), centralizované systémy tu budou podle mého názoru napořád. Stejně tak má smysl vytvářet nové projekty s centralizovaným verzovacím systémem. Absolutní nesmysl mi zkrátka nesedí. Svět není černo-bílý.

Díky za rozhovor.

[Yenya]

Ja bych rekl, ze centralizovany _pristup_ nevymizi. Ale mit pod tim centralizovany _verzovaci system_, tj. nemit moznost si u sebe udelat vetev nazvanou "test", neco vyzkouset (treba zkusit vratit zpet nejaky starsi commit), vyzkouset [ne]funkcnost, a vetev zase zrusit, je podle me opravdu vlastnost ktera chybi.

Co se tyce zalohovani a podobne - stejne jako v komercnim svete muzete mit politiku "nejpozdeji pri odchodu z prace je treba udelat commit", muzete totez v distribuovanem verzovacim systemu prepsat jako "nejpozdeji pri odchodu z prace je treba udelat push".

A i v centralizovanem komercnim svete jsou situace, kdy mate dlouhotrvajici paralelni vetve vyvoje, ktere potrebujete _opakovane_ slucovat. Coz v centralizovanem verzovacim systemu fakt nejde.

Jina vec muzou byt ty pluginy do ruznych IDE a tak. V tom fakt nemam prehled. Ale to podle me neni principialni vec - spis pouha otazka casu.

-Yenya

[zoul]

Ja bych rekl, ze centralizovany _pristup_ nevymizi. Ale mit pod tim centralizovany _verzovaci system_, tj. nemit moznost si u sebe udelat vetev nazvanou "test", neco vyzkouset (treba zkusit vratit zpet nejaky starsi commit), vyzkouset [ne]funkcnost, a vetev zase zrusit, je podle me opravdu vlastnost ktera chybi.

To přeci v Subversion jde, ne? Pokud je klíčový výraz „u sebe“, tak to mi jako tak zásadní problém nepřijde. Moje zdrojáky jsou vesměs pár kilobajtů, nemám problém tu větev poslat po síti. Chápu, že u větších projektů je to trochu jiný problém. (Mám pocit, že to zastánci DCVS občas berou zbytečně černobíle.)

A i v centralizovanem komercnim svete jsou situace, kdy mate dlouhotrvajici paralelni vetve vyvoje, ktere potrebujete _opakovane_ slucovat. Coz v centralizovanem verzovacim systemu fakt nejde.

Mám zkušenosti akorát se Subversion 1.4, kde jde opakované mergování opravdu blbě udělané. Novější verze Subversion už si mergované revize pamatujou, takže by to nemělo být tak zlé…?

[Filip Jirsák]

Moje zdrojáky jsou vesměs pár kilobajtů, nemám problém tu větev poslat po síti.

Jenže to pošlete aktuální stav zdrojáků, bez historie commitů. Ten druhý se pak může na zdrojáky jenom dívat, nebo je začne editovat, tím ale okamžitě vyrobí konflikt.

[zoul]

zoul@naima:wc$ echo "trunk" >> foo
zoul@naima:wc$ svn add foo
A         foo
zoul@naima:wc$ svn commit -m "Wrote 'trunk' to foo."
Adding         foo
Transmitting file data .
Committed revision 3.
zoul@naima:wc$ svn cp ^/trunk ^/branches/alice -m "Created alice's branch."

Committed revision 4.
zoul@naima:wc$ svn sw ^/branches/alice
At revision 4.
zoul@naima:wc$ echo "This is alice." > foo
zoul@naima:wc$ svn commit -m "Signed Alice in foo."
Sending        foo
Transmitting file data .
Committed revision 5.
zoul@naima:wc$ svn cp ^/branches/alice ^/branches/bob -m "Copied alice's branch to bob."

Committed revision 6.
zoul@naima:wc$ svn sw ^/branches/bob
At revision 6.
zoul@naima:wc$ echo "This is bob." > foo
zoul@naima:wc$ svn commit -m "Signed Bob in foo."
Sending        foo
Transmitting file data .
Committed revision 7.
zoul@naima:wc$ svn sw ^/trunk
U    foo
Updated to revision 7.
zoul@naima:wc$ svn merge ^/branches/alice
--- Merging r4 through r7 into '.':
U    foo
zoul@naima:wc$ svn merge ^/branches/bob
--- Merging r6 through r7 into '.':
G    foo
zoul@naima:wc$ cat foo 
This is bob.

Ano, v gitu by to bylo pohodlnější. Tohle mi ale vůbec nepřipadne zlé. Osobně větve zas tolik nepoužívám, takže budu opravdu rád [bez ironie], když mi někdo vysvětlíte, v čem je háček.

[Filip Jirsák]

Je to nepohodlné, proto se to taky málo používá. Nemůžete si sbalit zdrojáky na notebook a odpojit se od serveru, ale dál používat VCS. Při merge se vše promítne jako jedna změna, ne jako sada změn.

[Yenya]

Pokud je klíčový výraz „u sebe“

Ne, klicovy vyraz je "vetev".

-Yenya

[zoul]

Uf, tak proč bych tedy tu testovací větev nemohl stejně dobře založit i v Subversion? Pokud je to zjevné, omlouvám se, ale rád bych to slyšel polopatě.

[mikro]

100% suhlas. Nie je nic jednoduchsie ako z (grafickeho!) klienta spravit niekde create lokalneho repository a potom spravit merge, ked uz tak velmi trvame na offline "commitoch". Pani uz dlho nerobili s SVN :)

[Filip Jirsák]

Ono umí SVN mergovat tak, že se zachová historie commitů? Tj. z trunku odštěpím tag A, do něj commitnu patche 1, 2, 3, udělám merge zpět do trunku a tam budu mít v historii commity 1, 2, 3, můžu jeden z nich revertovat, vyrobit z něj diff atd.?

[zoul]

Myslím, že ne. Standardně nejsou commity 1–3 ani v historii trunku. Jde to obejít přepínačem --use-merge-history, ale to je myslím zhruba všechno. (Je docela dobře možné, že se pletu – budu rád, pokud mě někdo opraví.)

[Yenya]

Protoze v Subversion si v centralni repository dva lide zaroven nevytvori stejne pojmenovanou vetev "test", natoz aby ji mohli v pripade ze se ukaze jako slepa cesta po sobe beze stopy smazat.

Pokud je pravda to co se pise vedle, ze by si clovek mohl udelat kopii repozitare, vyvijet v lokalni kopii a pak a mezi ruznymi repozitari mergovat (vcetne cele historie), pak uvitejme Subversion mezi distribuovanymi verzovacimi systemy a zapocteme dalsi hlas me tezi, ze centralizovane verzovaci systemy jsou dnes uz nesmyslne.

-Yenya

[Karell]

Takze duvod proc v SVN branch nestaci je to, ze se neda udelat vic stejne pojmenovanych vetvi a nedaji se smazat beze stopy? To myslite vazne? Myslim, ze treba zachovani historie je neco co je naopak v komercni sfere zadouci.

 

[Yenya]

Zachovani historie neceho co se pak opravdu pouzije je zadouci. Ale neni zadouci zachovavat historie slepych cest, protoze to pak vede k tomu, ze vyvojar radsi tu pokusnou vec do verzovaciho systemu neda, dokud nevi ze to nekam povede. A az se pak rozhodne ze to asi nekam povede, ma uz prilis mnoho kodu na to aby vysledny jeden commit byl citelny.

-Yenya

[Leoš Literák]

V komercnich firmach s CVS/SVN pracuju osm let, ale politiku "co den, to commit" jsem nikde nezazil. vzdycky se commituje podle ucelu, neco dodelam, tak to commitnu. Mohu treba commitnout rozpracovanou verzi, aby k ni meli pristup dalsi lidi, nebo aby se na ni sjely automaticke testy, ale to je stejne u DSCM.

[Yenya]

Psal jsem "nejpozdeji", a to v odpovedi na pripominku k zalohovani a celkove kontrole nad projektem.

-Yenya

[Radim Kolář]

Podivejte se na system SCM Rational Jazz. Ten je centralizovany a pokud se jedna o workflow patchu je o generaci lepsi nez Bzr/Git/Hg protoze neni snapshot oriented ale patch oriented.

Misto vetvi pouziva streamy kam se posilaji jednotlive patche, ktere mohou byti i v konfliktu, takze neni nutne merge before push. Meneni historie neni problem, ze streamu se daji vyhazovat patche. Developeri maji kazdy vlastni workspace (navic centralne zalohovane) v kterem si mohou kutit co chteji a muzou si rozdelanou verzi 'dat nastranu' a pracovat na necem jinem, coz je mnohem lepsi nez delat private vetve, protoze odpadaji problemy se resynchronizaci. Navic muze jeden developer delat push/pull i z workspace jineho developera, takze si muzou posilat zmeny i jinak nez pres oficialni streamy.

Pracuje se s tim uplne nadherne. Dlouho jsem pracoval s bzr a hg a Jazz je u vetsiho projektu o generaci lepsi.

[Filip Jirsák]

Jaký je rozdíl mezi streamem Jazzu a changesetem Mercurialu? Stream je přímo repository, nad kterým se dá pracovat?

Jinak pro OSS projekty, na kterých spousta lidí pracuje ve volném čase třeba někde na cestách na notebooku je velice přínosný už jenom samotná nezávislost na centrálním repository. U firem to záleží na organizaci práce – pokud někde vývojáři pracují třeba na dálku, můžou tuto výhodu použít také.

[Radim Kolář]

Stream je neco jako mailing list kam jednotlivi lide posilaji sve patche. Aby jste mohl pracovat musite si nejdriv vytvorit workspace (neco jako checkout, ale je to spis neco jako soukrome git repo) ktere zinicializujete snapshotem ze streamu. Stream obsahuje dva typy objektu - jednak changesety a jednak snapshoty. Snapshoty se nedaji menit a vsechny changesety casove pred snapshotem se uz nedaji ze streamu odebrat, protoze jsou soucasti snapshotu, jsou to integracni body. V bzr/git/hg existuji jenom snapshoty, protoze se neda comitnout verze s konflikty. Trochu podobny Jazzu byl Darcs

Kdyz se provadi integrace patchu aby se vytvoril snapshot, tak pokud tam existuji konflikty ktere je treba vyresit je dobre si stream zamknout aby se do nej nedaly pridavat nove patche to by pak prace nebyla hotova nikdy. Kdyz se vam nejaky patch nezda, tak ho proste ze streamu smazete. Patch se pak znova objevi u vyvojare v jeho workplace jako outgoing. Provedete integraci, udelate build+unit testy, vytvorite snapshot a odemknete stream. Integrace se u vetsich projektu delaji obvykle tydne pripadne casteji podle potreby. Clenove ostatnich tymu kteri na dane komponente nepracuji si ze streamu neberou jednotlive patche, ale jen snapshoty, kterymi si aktualizuji sva workspace. Snapshotum se rika v Jazz terminologii baseline.

workspace nasubscribujete do streamu podle libosti a IDE vam bude ukazovat rozdil mezi vasim workspace a jednotlivymi streamy - kolik patchu mate oproti nim navic a kolik a ktere patche maji navic oni. Podle sveho uvazeni muzete patche z jednotlivych streamu prijimat (a vyresit si konflikty pokud jsou) ci posilat (pokud mate na to prava). Kdyz udelate nejakou praci a zakomitujete tak se pak ten patch zobrazi jako outgoing pro prihlasene streamy, muzete ho poslat hned ci nemusite. V podstate mate tedy vlastni VCS repository, ktere se uklada centralne, centralne se uklada i rozdelana ale nezakomitovana verze souboru, nikoliv az kdyz je to hotovo (t.j. outgoing patch).

Patche se daji pripojovat k workitemu (bug tracker polozka) aby se s nimi lepe manipulovalo a snadneji se vyhledala skupina patchu ktere patri treba k bugfixu. workitemy nejsou soucasti streamu, ty jsou normalni bug manager ala bugzila.

Offline provoz nebo provoz pres WAN Jazz zvlada, protoze umi synchronizovat (vcetne merge) lokalni workspace s kopii workspace ulozenou na serveru. Takze se muzete odpojit od serveru a lokalne si komitovat jak je libo. Protoze se posilaji na centralni server jenom zmeny (pokud se zrovna nevytvari novy workspace, to se pak poslou cele soubory) je to dostatecne rychle i pres WAN. Sam to pres WAN pouzivam a je to dost rychly i s pingem 180ms. Podpora pro propojovani vice jazz serveru (DVCS) se pripravuje, mozna v 2.0 uz nejaka zakladni je v bete jsem videl v administraci serveru nejake takove polozky.

Demo ke stazeni na http://jazz.net/ vcetne zdrojaku nekterych casti; OSS projektum snad davaji licence na pouziti zdarma. Ma to byt nahrada clearcase; CC se mi nikdy moc nelibil.

[Filip Jirsák]

Možná je to jenom tím, že ještě nedokážu výhody VCS orientovaného na patche a ne na snapshoty ocenit, ale osobně mi připadá ta orientace na snapshoty lepší. Přeci jen při běžné práci chci vidět „head“ verzi stromu, na kterém pracuji, a nezajímá mne, z jakých patchů vznikla a už vůbec se o to nechci starat. Možná se s tím dá pracovat úplně stejně, ale pořád mi připadá přirozenější dívat na zdroják jako na celek, který je v nějakém stavu, do kterého dospěl sérií patchů, než jako sérii patchů, která tvoří nějaký stav zdrojáku. připadá mi ta časová posloupnost důležitá, protože patche nejsou na sobě úplně nezávislé, ale velice často patch závisí na některém z předchozích.

[z/OS]

My jsme taky presli na Jazz, IBM nam to porad cpala a musim rici, ze je to opravdu vyborny. Ten workflow je mnohem lepsi a prirozenejsi. Zavislost patchu to nenarusuje, kazdy patch si nese s sebou i svoji historii. Taky tu nebylo zdurazneno ze patch neni nedelitelny, da se i rozdelit a jednotlive casti sloucit pak s jinym patchem, pripadne zamitnout.

HEAD verze stromu je prezitek ze snapshot orientovanych VCS systemu. Na jedne strane tu pokladate vyvoj ala CVS - centralni 1 vetev za archaicky model a na druhe strane pozadujete vzdy posledni snapshot jinak nejste schopen pracovat. Nevite co vlastne chcete.

My mame denni integracni stream (kazdy den udelame 1 baseline pred koncem pracovni doby kde zaintegrujeme patche co se udelali pres den nebo co nam litaji z minula okolo) soukromy pro nas team a tydeni integracni stream ktery exportujeme ostatnim teamum. Pokud jsme treba zmenili API nebo tak, tak muzeme udelat tydeni baseline i driv aby si ostatni aktualizovali workspaces drive.

Naloudujete posledni baseline a pripadne nekonfliktni patche ze streamu (to jsou v terminologii Jazzu takove ktere modifikuji jine soubory nez mate zmenete ve workspace. Ty co modifikuji stejne se nazyvaji potencionalne konfliktni) a venujete se svoji praci. Je to mnohem vice skalovatelnejsi, protoze se nemusite proste starat co vas kolega zrovna zakomitoval a jak to ovlivnuje vasi praci, protoze HEAD verze se meni neustale.

[Milan Jurik]

HEAD verze stromu je prezitek ze snapshot orientovanych VCS systemu. Na jedne strane tu pokladate vyvoj ala CVS - centralni 1 vetev za archaicky model a na druhe strane pozadujete vzdy posledni snapshot jinak nejste schopen pracovat. Nevite co vlastne chcete.

Ani ne, kdyz si vezmete model vyvoje, kdy vetsina tymu pracuje s nejaktualnejsim stavem vyvoje ostatnich, kdezto nekolik tymu si spravuje vlastni kopie a vysledek jejich prace bude pridam do hlavni verze az po nekolika mesicich/letech (a jen obcas si pribiraji aktualni stav hlavni vetve), a k tomu jeste existuje nekolik dalsich verzi jiz dorucenych zakaznikum, o ktere se staraji jini a ty nemaji s "hlavni" vetvi po case moc spolecneho. Takze kazdy ma v takovem modelu jinou potrebu ohledne HEADu.

Baseline + nekonfliktni patche (predpokladam ty, jejichz vsechny patch-zavislosti jsou nekonfliktni) je pak aktualni HEAD, jak ten vas popis chapu.

Moznost commitnuji konfliktnich patchu pak predstavuje jen obezlicku na to, ze tymy s delsim vyvojovym cyklem nemaji vlastni klon hlavniho repozitare, ale musi vysledky sve prace cpat do centralniho. Coz u decentralizovaneho neni treba, protoze takove tymy vysledky sve prace davaji do sveho sdileneho vyvojoveho repozitory. Tim padem potreba konfliktni patchu v centralnim repozitari odpada a konflikty se resi okamzite, jak je je potreba resit (ne drive, ne pozdeji) a clovekem, ktery smysl daneho konfliktniho kodu nejlepe chape.

Jedinou vyhodou centralniho rizeni z meho pohledu je pak to, ze management ma okamzity prehled o stavu prace commitnute vsemi tymy. Jenze treba z prirozenosti cloveka pak vyplyva snaha necommitovat zabordeleny kod a ten si naopak syslit u sebe, coz muze vest ke ztrate znalosti. Nebo naopak se do repozitory dostava hromada nekvalitniho/neotestovaneho kodu, ktery u decentralizovaneho nema narok jit do hlavniho repozitory. Decentralizovany model klade vetsi duraz na potrebu pravidel prace, ovsem ma pak sirsi moznosti pro vyvojare.

Samozrejme je mozne, ze mi zpusob prace s Jazzem stale unika, ale prozatim v nem nevidim vyhody. Urcite lze takovy model bez problemu uzivat, jen je treba prislusne nastavit styl prace a ve vysledku lze namapovat na ten decentralizovany.

[Radim Kolář]

Ono se to dost tezko vysvetluje. Mne samotnemu ackoliv jsem zvladal workflow ala GIT (ktere mi pripada vylozene jednoduche. zakladni jednotkou je vetev a ty se pak mezi sebou merguji) tak mi trvalo nekolik mesicu nez jsem si uplne zvykl na workflow Jazz SCM. Pro pochopeni jsem si musel Jazz nainstalovat doma vytvorit si nekolik uzivatelu, prepinat se mezi nimy a zkouset si ruzna schemata. Taky jsem si prostudoval serial na developerworks a vyukova videa. Protoze oproti snapshot oriented VCS na ktery jsem byl zvykly je tohle uplne neco jineho. Je fakt ze pro velke projekty je to mnohem lepsi.

Zakladni rozdil bych videl v tom ze v GITu si musite vetev sam explicitne vytvorit a nove patche se pripojuji vzdy na konec vetve, neda se (presneji receno nepocita se ze by se to bezne delalo) menit historie, a nemuzete mit ve vetvi konflikty.

V Jazzu se vetve (ackoliv se jim vubec vetve ani nijak jinak nerika) ve vyvoji vytvari automaticky, pokud mam ve workspace neprijate zmeny ze streamu a neco zakomituji. Jazz SCM nema prikaz na to pracuj s urcitou vetvi, ale muzete se prepnout workspace do predem ulozeneho stavu (baseline). Pred prepnutim na jinou baseline se vam dokonce zazalohuje aktualni stav workspace jako nova baseline, takze se k nemu muzete snadno vratit. Bezne se takto vetve neemuluji, je lepsi si pro prehlednost udelat novy workspace. Kdyz workspace neni uz potreba, tak ho proste zrusite a vsechny zmeny ci baseline ktere nebyly odeslany do streamu nebo do jineho workspace se znici.

Chce si ten Jazz opravdu vyzkouset.

[Yenya]

Jazz neznam, ale jak to tady ctu - neni Jazz neco jineho nez verzovaci system? Z open source sveta bych mozna videl podobnost ve vecech jako je Patchwork Quilt nebo Stacked-Git.

-Yenya

[Radim Kolář]

Proc by to nebyl verzovaci system? Baseline jsou obdobou snapshotu t.j. verzi v gitu a ostatni je tam navic.

Ty dva jmenovane systemy neznam

[Karell]

Ja bych rekl, ze centralizovany _pristup_ nevymizi. Ale mit pod tim centralizovany _verzovaci system_, tj. nemit moznost si u sebe udelat vetev nazvanou "test", neco vyzkouset (treba zkusit vratit zpet nejaky starsi commit), vyzkouset [ne]funkcnost, a vetev zase zrusit, je podle me opravdu vlastnost ktera chybi.

Naopak, je zadouci, aby si vyvojar pojmenoval vetev nejak smysluplne, vysledky daval na server a nesmazal to tak, ze uz to nikdo nedohleda. Pokud chce jen vyzkouset revert nejakeho commitu, tak na to ani nepotrebuje vetvit.

Co se tyce zalohovani a podobne - stejne jako v komercnim svete muzete mit politiku "nejpozdeji pri odchodu z prace je treba udelat commit", muzete totez v distribuovanem verzovacim systemu prepsat jako "nejpozdeji pri odchodu z prace je treba udelat push".

Takze chcete resit zalohovani DVCS tak, ze se to nakonec stejne bude davat vsechno do centra, cimz jsme udelali veletoc zpet k centralnim systemum. V komercni sfere stejne neni zadouci aby si vyvojar neco syslil u sebe, z mnoha duvodu.

A i v centralizovanem komercnim svete jsou situace, kdy mate dlouhotrvajici paralelni vetve vyvoje, ktere potrebujete _opakovane_ slucovat. Coz v centralizovanem verzovacim systemu fakt nejde.

Proste to lze, i kdyz to mozna neumite, i kdyz jeste 100x zopakujete ze to nejde, presto to lze. Treba to funguje jinak, ale to neznamena, ze to nejde.

Jina vec muzou byt ty pluginy do ruznych IDE a tak. V tom fakt nemam prehled. Ale to podle me neni principialni vec - spis pouha otazka casu.

Tady uz je temer priznacne, ze jste po nekolika druhoradych duvodech proc komercni sfera potrebuje DVCS elegantne presel docela zasadni duvod proti . Ale uz se neco rodi...

Obecne mam pocit, ze jste zvykly nejak delat veci s GITem a vase argumentace proti jinym systemum je je stavena na tom, ze nefunguji presne jako GIT. To je jako si myslet, ze se neda jezdit na motorce, protoze nema volant. Zkuste trochu uvolnit mysl a popustit uzdu fantazii...

[petr_p]

Co se tyce zalohovani a podobne - stejne jako v komercnim svete muzete mit politiku "nejpozdeji pri odchodu z prace je treba udelat commit", muzete totez v distribuovanem verzovacim systemu prepsat jako "nejpozdeji pri odchodu z prace je treba udelat push".

Takze chcete resit zalohovani DVCS tak, ze se to nakonec stejne bude davat vsechno do centra, cimz jsme udelali veletoc zpet k centralnim systemum. V komercni sfere stejne neni zadouci aby si vyvojar neco syslil u sebe, z mnoha duvodu.

V jedné přednášce o gitu na podobné otázky bylo odpovězeno: git dává svobodu, politiku si musíte vytvořit a vynutit jinak.

[kralyk z abclinuxu]

Jo, to je dnes v módě. Když řeknete, že cokoliv dává svobodu, hned to lidi pozitivně naladí

[Ladicek]

V komercni sfere stejne neni zadouci aby si vyvojar neco syslil u sebe, z mnoha duvodu.

Tak. A že ony to ty vývojářské mrchy stejně dělají, co?!

A co se podpory v IDE týče – IDEA podporu má (neviděl jsem, ale jak znám JetBrains, bude to o řád lepší než všechno ostatní), a zbytek je nezajímavý

Čímž se nechci nijak stavět na stranu DVCS, natožpak Gitu, jen prostě realita není černobílá.

[Filip Jirsák]

Centralizovaný systém je ale podmnožinou decentralizovaného – vždy můžete decentralizovaný používat tak, jako by byl centralizovaný. V zálohování také není rozdíl – buď zálohujete jenom centrální repository, a pak stejně nemáte zálohované změny, které si programátor syslí u sebe na disku (protože zrovna z nějakého důvodu nemůže commitovat do centrálního repository), nebo můžete zálohovat i ty lokální kopie (a pak asi bude snazší zálohovat repository distribuovaného VCS, protože stačí zálohovat změny).

[l4m4]

Tohle je k ničemu. Argumentem ,vždy můžete zařídit, aby to tak bylo` nepřesvědčíte toho, kdo chce, aby to tak prostě bylo.

[mirec]

Decentralizovaný systém sa dá používať rovnako ako centralizovaný. Okrem toho má množstvo výhod (napr. môžem pracovať pčas cesty vlakom, čo takmer vždy využívam).

[Milan Jurik]

Jenze zrovna rozumne komercni firmy vyhody distribuovanych RCS uzivaly drive nez vubec git existoval (distribuovane RCS jsou zde uz 20 let).

Centralizovane verzovaci systemy jsou jen osekanou podobou decentralizovanych, nic neprinasi navic. Argumentace bezpecnosti ci zalohovani je mylna. Jaka bezpecnost? Aktualni kod ma stejne k dispozici vyvojar v obou pripadech. Naopak zalohovani je spise vyhodou, protoze mate k dispozici obcas i desitky tisic uplnych kopii rozdistribuovanych po svete. A pritom stale "master build" delate z predem urceneho workspace, do ktere ostatni drive ci pozdeji pushnou vysledky sve prace, a tedy to zlatou kopii, kterou muzete s chuti zalohovat ci archivovat.

[Martin Böhm]

V cem je pro Vas lepsi Bazaar nez Git? Pouzival jsem bzr, kdyz jsem jeste pomahal v Ubuntu, ale jakmile se moje zajmy zmenily, zkousel jsem i Git a prisel mi prakticky stejne jednoduchy a pouzitelny, navic o trochu (rozeznatelnou trochu) rychlejsi.

Neberte to jako flame, jen mne zajima, jestli mate i nejaky duvod, proc Bazaar.

[z/OS]

Mne se u bzr libi jednak to ze podporuje vice protokolu, pouziva one branch per directory, nemusi se delat git gc, ma lepsi web browser na revize, umi lepe rename adresaru, cisla verzi ma lidstejsi, ma intuitivni prikazy a podporuje hafo pluginu a podporuje launchpad. Taky beha lepe na widlich.

[Yenya]

Bzr moc neznam, ale aspon se neco priucim. Nejprve ke gitu:

• Git prece take podporuje vice protokolu (http, https, nativni git, git+ssh, ...).
• Git-gc se delat uz dlouho nemusi (probiha samo podle potreby na pozadi, pokud to explicitne nevypnete).

A ted k bzr:

• Jak dosahuje bzr "lidstejsich" a pritom celosvetove unikatnich cisel verzi?
• Jak umi "lepe" rename adresaru? Vzdyt na rename neni nic tezkeho. Co naopak je tezke a bylo by dobre mit, je sledovat "kde vznikl tento kus kodu" (napriklad na ktera vsechna mista byl rozkopirovan). Viz tez permalink.gmane.org/gmane.comp.version-control.git/217.
• launchpad: jednou z vyhod distribuovanych VCS je to, ze repozitar muze byt staticky adresar, cili neni treba specialnich hostovacich platforem typu SourceForge nebo treba Launchpad.
• co je "one branch per directory"? Jakoze pracovni kopie muze obsahovat jen jednu vetev? Cili kdyz potrebuju opravit trivialni chybu v jine vetvi, musim vedle udelat novy checkout potencialne obrovskeho projektu? To mi jako vyhoda nepripada, ale mozna jen nerozumim co se pod tim mysli.

-Yenya

[stativ]

Jak dosahuje bzr "lidstejsich" a pritom celosvetove unikatnich cisel verzi?

Tady se naskýtá otázka: „Jsou celosvětově unikátní čísla verzí opravdu potřeba?“

Osobně dávám přednost inkrementálnímu číselnému označení verzí. Na první pohled vidím, která verze je novější. Je to výhodné i z pohledu baliče – není potřeba používat různé „obezličky“ jako číslování podle data, kde opět není na první pohled vidět, kterému commitu verze náleží.

[Yenya]

A jak se domluvim s ostatnimi, kdyz chci treba rict "bisect mi rika, ze tato chyba byla zanesena commitem cislo XY". Tam prece potrebuju celosvetove unikatni cislo verze, ne?

-Yenya

[stativ]

K čemu? Přece víš, o jaký software se jedná.

[zoul]

Pokud tomu dobře rozumím, tak v distribuovaném systému musíš čísla revizí nějak synchronizovat. Nemůže se stát, že by jeden vývojář měl pod revizí X tyhle změny a druhý vývojář (téhož softwaru, ve vlastním repository) něco úplně jiného. Hešování tenhle problém velice elegantně řeší, za cenu poněkud neskladných čísel revizí.

[kralyk z abclinuxu]

Pokud tomu dobře rozumím, tak v distribuovaném systému musíš čísla revizí nějak synchronizovat.

Synchronizovat? Snad ne centralizovaně? :P

[Filip Jirsák]

Proč centralizovaně? Stačí statisticky – použít hash, kde je riziko konfliktu bezvýznamné.

[Karell]

Pripada mi, ze uzivatele GITu, casto postihuje jakasi zaslepenost a maji najednou pocit, ze v jinych VCS nejdou ani zakladni veci jako branch, merge... Polovina povidani o GITu je prachsprosty FUD, na ktery plati argumentace z praxe. Nas sw je radove stejne velky jako linux (9mil radku, 45k souboru, 850mb), pouzivame SVN, na klientech TSVN. Mame radove 20-30 vetvi, bezne je mergujeme. Protoze je vse centralni, je jednoduche to zalohovat, delaji se na tom buildy a testy.

Jedna z veci, ktera byla zasadni pro nasazeni je slozitost pouzivani. Pokud pro tohle potrebuje GIT jiste mentalni usili tak bych to tak jasne s tim vymizenim nevidel .

Aby bylo jasno, nemam nic proti GITu samotnemu, je dobre, ze to existuje a ze to slouzi tem co potrebuji takove moznosti, ale vadi mi, kdyz se z toho dela nabozenstvi.

[alblaho]

Já to chápu. Nikdo neříká, že vývoj na SVN nemůže fungovat. Já měl SVN vždycky rád a taky jsem myslel, že "to stačí". Pak jsem zkusil Git, udělal si pár opravdu levných větví, užil si opravdového merge trackingu, ale hlavně jsem viděl, jak je to celé k*revsky rychlé. Od té doby to (až náboženské) nadšení Gitařů chápu, je to prostě o řád výkonnější nástroj.

V práci používám relativně spokojeně SVN. Znám dobře jeho omezení. Naopak jsem se neodhodlal k použití git-svn (přestože s tím někteří kolegové pracují), protože jeho omezení pořádně neznám a nejsem si jistý co můžu a nemůžu.

[Palo]

Ano, ano, ano. Problem je ze ludia si neuvedomuju ze SVN vie dobre robit povedzme 80% toho co GIT. A niektorym to proste staci lebo tych 20% nepotrebuju.

[Josef Kufner]

Ne že bych chtěl nějak SVN křivdit, ale těch 80% je trošku nadnesených, zejména ve spojení se slovem "dobře"

[nh]

jen ze zvedavosti bych se chtel zeptat kolik lidi/teamu pracuje nad takovym repozitarem a zda vyuzivate nejaky per clovek/team branching nebo to vsichni tlaci do jedne vetve.

[Karell]

Jak jsem uvedl ten pocet vetvi, tak jsem tim myslel aktivne pouzivane. Cili je najednou asi 20 projektu, kazdy ma vlastni vetev. Na kazdem dela zhruba 1-5 vyvojaru.

[Pev]

Cili je najednou asi 20 projektu, kazdy ma vlastni vetev. Tedy 1 projekt má 1 větev? To pak ani není potřeba mergování, né?

[Karell]

ty projekty rozsiruji funkce celeho programu, takze bez toho, aby se pak sesly v hlavni vetvi by nemely moc smysl. Podobne jakoby byly u linuxu vetve na novy FS, driver apod.

[kralyk z abclinuxu]

Diskutujícím ve webových diskusích bych chtěl vzkázat: Nebuďte tak konzervativní! Přijde mi podivné, jak se s každou novou vlastností open source softwaru najdou spousty názorů typu „co si to zase vymysleli za novotu, vždycky to přece fungovalo tak a tak a stačilo to“. Před pár roky bylo moderní takto nadávat na udev, HAL a D-Bus

Hehe, to je naprosto přesné...

[Martin Böhm]

Na HAL a D-Bus nadavam dodnes, a nejsem sam... pravda, jsme spis banda vousatych mudrlantu z pochybnych univerzit :o)

[stativ]

Jo, taky mám za to, že HAL je příšernost. Co je ještě horší, že k němu neexistuje žádná kloudná dokumentace. Teď tedy vkládám veškeré naděje do PolicyKitu, snad to bude použitelnější.

[mirec]

No nemyslím, že má lepšiu dokumentáciu ;) U týchto služieb je problém nájsť na čo to vôbec slúži, o poriadnej dokumentácii sa mi môže len snívať.

[kralyk z abclinuxu]

No jo, to je takovej ten bohatýrskej přístup ve stylu "Nejlepší dokumanteace je zdrojový kód"

[kralyk z abclinuxu]

dokumentace

[stativ]

To jsem neřekl. Myslel jsem to tak, že doufám, že to nebude takový moloch.

[Martin Böhm]

Bude to jen takove rypnuti a jeste ne do vas, ale k cemu jako uzivatele svobodneho softwaru potrebujeme dalsi userspacove vrstvy abstrakce jako HAL/DeviceKit?

Mam takove tuseni (pozor, jen tuseni, rad se necham poucit/opravit), ze je to z nasledujicich duvodu:

• Software Foo chce pouzivat hardware na dvou svobodnych operacnich systemech, ktere nejsou kompatibilni, protoze oba tabory si mysli, ze jejich pristup je lepsi. Pak molochem jako HAL (snizenim vykonu) platime za neschopnost vyvojaru se domluvit. Super.
• Software Foo chce pouzivat hardware na svobodnem a proprietarnim systemu. Pak platime zhruba za to same jako v bode 1, akorat tady je prakticky nulova sance, ze autori toho proprietarniho systemu ustoupi. Proc bychom nemohli radeji napsat water, ktery by na onom systemu emuloval nase nativni kernelova rozhrani, a sami netrpeli snizenym vykonem?

Tak ci onak, mam pocit, ze jakakoli dalsi rychle upecena vrstva abstrakce slouzici spis jako "zaplata" nejakeho problemu vyvojaru aplikaci, nez systemove reseni, je odsouzena k tomu, aby nas trapila po dlouha leta :o)

[stativ]

Jiné části jsou na tom i hůř. Třeba taková ALSA → Pulse Audio → Xine → Phonon → Aplikace která chce něco přehrát je už opravdu slušný extrém. A v podstatě jde pořád o totéž. Nějakému vývojáři se nelíbí současná vrstva abstrakce, protože je „moc vysoko“ nebo „moc nízko“ tak si vytvoří vlastní, která je mezi…

[marbu]

Treba takovy HAL mi prijde jako systemove reseni (btw pamatujete si nekdo na drivejsi automount daemony, to bylo _osklive_) a pokud nekdo nepotrebuje, tak ho pouzivat nemusi. Druha vec je, jestli ho do toho nuti jeho distribuce. Jinak pokud te zajimaji duvody proc mit v systemu DeviceKit, mozna te zaujme tahle prednaska: Building a Modern Multi-User Desktop [PDF].

[Martin Böhm]

"Pokud nekdo nepotrebuje, tak to pouzivat nemusi" je jeden z nejmene oblibenych argumentu, co znam. Skoro na vsechno, na co se pouziva (od alkoholu pres cigarety az k softwaru), se da najit duvod, proc propagace takoveho objektu zkazi situaci pro vetsinu populace. Ale to jen na okraj.

Proc Vam HAL prijde jako systemovy? Jaky problem resi, ktery by se nemel resit nikde jinde nez v Hardware Abstraction Layer, jak se pysne jmenuje?

Budu znit jako brucoun, ale cerno-bile slidy, kde se musi prechazet na dalsi, aby se odkryl jeden radek, se mi moc dobre nectou. Nemate neco snesitelnejsiho pro me zraky? :o) Ale co jsem pochopil, tak se to tyka hlavne Fast User Switchingu, a argumentovat touhle blbinou pro HAL a *Kity... no nevim.

Nerikam, ze GNU/Linux uz je pro bezneho uzivatele rajem, ale budu vic nez spokojeny, az bude nasim hlavnim problemem to, ze uzivatelum vadi, ze po prepnuti uzivatele nabiha prihlasovaci okno (zjednodusene) :o)

[marbu]

K tomu, ze to nemusite pouzivat: Prave naopak, vetsine desktopovych uzivatelu bude HAL k uzitku, ale to neznamena, ze by neexistovali lide, kteri ho nepotrebuji a v tom pripade se bez neho opravdu obejdou - vzdyt HAL je jen daemon. Pokud ma uzivatel nejake to KDE nebo Gnome, muze napr. cekat, ze kdyz pripoji k bezicimu systemu fotak pres firewire, system ho pozna a napr. ukaze uzivateli, ze ho pripojil. To, ze k tomuto ucelu v systemu daemon, ktery posle po d-bus sbernici aplikacim zpravu: "hele, uzivatel pripojil fotak" povazuji za sytemove - cpat tohle do jadra je nesmysl a zaroven si tohle nemusi resit kazde desktopove prostredi samo. A pokud jde o server nebo kdyz uzivatel preferuje neco jako fluxbox nebo xmonad a sluzby, co nabizi HAL nepotrebuje, tak mu system muze fungovat i bez nej.

Ale na druhou stranu HAL se pomalu zabydluje napr. v Xorg - coz by melo umoznit za behu pripojit dalsi mys, ktera bude moci byt nakofigurovana jinak, nez ty predchozi (napr. citlivost). To by bez HALu nebylo mozne, protoze Xserver tradicne nastavoval hw pri startu - a opet diky HALu si to X server nemusi resit sam, ale vyuzije k tomu specialniho daemona.

Neco o tom, proc mi to prijde systemove uz jsem zminil v predchozim textu. Ono mne osobne to jmeno "HAL" docela matlo a rozhodne linuxovy HAL je neco uplne jineho nez HAL na WinNT. A co teda dela HAL? V podstate eviduje zarizeni - vi, ze na tehle usb portu je nejaky fotak a dalsim nejaka mys. Zasila po d-busu aplikacim zpravy, kdyz se neco pripoji (na to muze reagovat treba desktopove prostredi vytvorenim ikonky na plose nebo zobrazenim dialogu) a umoznuje aplikaci dotazovat se na zarizeni: napr. chci vypsat vsechny fotaky pripojene k systemu. O pripojovani a vytvareni souboru v /dev se ale stara jine daemon - udev.

Mam tu jeste jednu prednasku o linuxu na desktopu, shodou okolnosti taky od Yenyi z nektereho minuleho EurOpen - o HALu jsou tam sice jen 2 stranky, ale treba se bude libit vic :)

[Josef Kufner]

Tož ono něco jako HAL je potřeba, ale současná implementace je dosti děsivá a dokumentace tajemná. Doporučuju zfilmovat -- jako horor to bude mít úspěch.

Na druhou stranu, d-bus je celkem povedený.

[Martin Böhm]

Jak se HAL dozvi, ze nejake zarizeni objevilo? Predpokladam, ze pouziva nejake jaderne mechanismy, a la inotify (ted docela spekuluji, uznavam). Proc tyto mechanismy nemohou pouzivat primo aplikace, nebo, pokud lide maji pocit, ze tyto mechanismy jsou slozite, se nenapise knihovna, ktera tyto mechanismy aplikacim primo zpristupni bez nutnosti dalsiho daemona?

[marbu]

Daemon udev, ktery tomu zarizeni napr. vytvori spec. soubor v /dev, posle po systemove d-bus sbernici udalost pro HAL, ktery ji pak zprostredkovava zase pres uzivatelskou d-bus sbernici aplikacim. HAL dostava ale od udev pomerne surove informace (typuju), ktere se snazi aplikacim podavat v (pro ne) pouzitelne forme (ma u sebe databazi zarizeni a jejich popis atd.) - je to popsane v tom pdf o linuxu na desktopu. Cele se to dela proto, aby bylo mozne zarizeni evidovat, dynamicky pridavat a odebirat a generovat tim na ruzne udalosti. Kdyby byl HAL knihovna, stejne by nekde musela byt cetralni databaze zarizeni, ktera by musela existovat nezavysle na ostatnich aplikacich - ale jak jinak to udelat, nez pomoci daemona - kdyby to bylo primo v jadre, bylo by to hadam nerealizovatelne nebo osklive.

[Martin Böhm]

Udev jako program, ktery vytvari spec. soubory v /devu, beru. Proc ale nemuzeme mit rovnou mechanismus v knihovnach podobny inotify, ktery mi zajisti, ze se mi nejaka obsluzna funkce zavola ve chvili, kdy v /dev pribyl ten soubor? Proc musi udev volat dbus, ten volat hal, ten volat dbus, ten volat aplikaci? Neni to zbytecne pro valnou vetsinu pripadu?

Myslim si, ze jednu centralni evidenci zarizeni uz mame, jmenuje se /dev. Vytvareni jejich kopii mi neprijde jako ta spravna UNIXova cesta. Jednou jsme si ten system zalozeny na souborech vymysleli, tak proc se od nej prave ted odvracet?

(Nehlede na to ze se mi v dbusu krajne nelibi ta myslenka "stinoveho filesystemu - pseudo-cesty k objektum".)

[Yenya]

Ja myslim ze adresovat objekty cestou je docela logicke a pekne. A ne, neni to stinovy /dev, protoze to zdaleka neni jen pro zarizeni. Objekt na D-Busu muze byt treba i rozhrani aplikace. Napriklad ekiga muze byt taky viditelna po D-Busu jako objekt, muzete tomu objektu rikat "zavolej na to a to cislo", nebo naopak ten objekt muze pres D-Bus posilat jinym zpravu "vyzvani prichozi hovor" a ti jini treba muzou ztlumit prehravani, pustit grab X serveru, nebo cokoli podobneho.

Volani udev---(dbus)-->HAL--(dbus)-->aplikace je proto, ze HAL (pres PolicyKit, ConsoleKit a dalsi) umi resit pristupova prava a nastavit treba ACL podle toho kdo je zrovna prihlaseny na konzole/konzolach. A taky proto ze aplikace se chce dozvedet "vznikl novy fotak" a nemuset si pamatovat, ze fotak muze byt USB mass storage, USB proprietarni pres gphoto2, FireWire a kdovi co jeste. Podobne treba s klavesnicemi a jejich specialnimi tlacitky. Kazdopadne na tom neni nic neefektivniho, predpokladam ze na beznem systemu nemate stovky hot-plug udalosti za vterinu.

-Yenya

[Martin Böhm]

Ano, pouziti pro adresovani objektu v IPC komunikaci beru, to mi zas tak nevadi - dokud to bude domena GNOME a KDE aplikaci, pak s tim nemam problem. Mluvil jsem o zrcadleni systemu zarizeni v d-busu skrz HAL.

Adresovat objekty cestou je zhruba tak spatne, jako adresovat objekty skrz nejakou formulaci jako "http://www.amarok.net/selectwidget". Neni to uplne spatne, ale proc predstirat, ze to je URL, kdyz to vlastne vubec zadna URL neni? Ja pristup skrz objektum pomoci cesty (a la Plan 9) vidim jako super napad, ale tohle polopropecene reseni, kdy se to jen jako cesta tvari, ale na pristup potrebujeme aplikaci XYZ, to se mi ani trosku nelibi.

Argumentujete pridanim ACL vlastnosti pro zarizeni, cimz mi skvele nahravate k dalsimu argumentu: HAL, stejne jako PolicyKit a dalsi aplikace, nebyl domyslen poradne. Chapu rekneme uzitecnost ACL a "zastaralost" stareho UNIXoveho pristupu. Ale podle meho neni spravne pridavat "poloreseni" pro zarizeni skrz nejakou novou vrstvu, zatimco na pozadi to vsechno beha s temi starymi UNIXovymi pravy. Pro mne by bylo mnohem lepsi ta prava opustit a zavest jednotny system ACL pro filesystem, ktery by byl pouzitelny i mezi aplikacemi, uvnitr jedne aplikace a tak dale.

Stejny argument vidim i pro HAL - misto abychom nejak vylepsili aktualni rozvrzeni zarizeni v /dev a rozsirili jej rozumnym zpusobem, tak navrhujeme "lepsi" rozhrani pro aplikace, ale podminujeme ho povinnym clenstvim v klubu d-bus (desim se dne, kdy vim bude zaviset na d-busu).

Uznavam, ze jmena mohou klamat, ale kdyz vidim aplikaci, ktera prevzala jmeno podle aktualne moderniho jadra prohlizece, mam sve obavy, jestli vyvojari nahodou nepristupovali stejne i k navrhu - prdneme tam, co je moderni, a bude.

K te neefektivnosti budu nejdriv reagovat anekdotou: pro kratky seznam prvku je stihnutelne i jejich setrideni metodou "projdu vsechny permutace a najdu tu, ktera je setridena". Ale je to "efektivni" reseni? Z vaseho pohledu (nemam stovky prvku) ano, z meho je to bida nejvetsi :o)

Touhle anekdotou nechci ale svuj argument zakoncovat, je spis pro zasmani. Pristup "ja potrebuju ACL/XYZ, pridam daemona, co mi to zprostredkuje" nevede sice k okamzitemu asymptotickemu zhorseni vykonu, ale spis ke spouste novym chybam (prvni vydani Ubuntu. kde se objevil PolicyKit, bylo desuplne) a "kapkovitem" zpomaleni - pak nebudeme schopni rici, jestli system je neresponzivni kvuli GNOME daemonum, HALu, D-Busu... protoze kazdy z nich prida svou trosku do celkove negativniho dojmu.

[Filip Jirsák]

Adresovat objekty cestou je zhruba tak spatne, jako adresovat objekty skrz nejakou formulaci jako "http://www.amarok.net/selectwidget". Neni to uplne spatne, ale proc predstirat, ze to je URL, kdyz to vlastne vubec zadna URL neni?

Proč by to nebylo URL? URL je Uniform Resource Locator, objekt je zdroj, „adresovat“ je locator, jednotnost adresování je snad také zřejmá.

[Pev]

(desim se dne, kdy vim bude zaviset na d-busu)

Tak toto mě opravdu rozesmálo .

[Yenya]

Ja nevim jestli si rozumime. Podle me HAL neni zrcadleni /dev jeste jednou.

Adresovani objektu cestou je podle me prirozene. Jde o namespace, a v UNIXu se tradicne namespace dela jako posloupnost jmen oddelenych lomitkem. Samozrejme bylo by to daleko vic UNIXove, kdyby i tento namespace byl soucasti filesystemu. Neni, no co uz.

Namitce s ACL prilis nerozumim. To neni zadne "poloreseni" - proste se vyuziva nejaky demon, ktery prihlasenemu uzivateli umi u souboru v /dev nastavit ty ACL. Ty stejne ACL ktere si muzete nastavit i rucne - neni to tak, ze by "na pozadi behala stara UNIXova prava" - Linux uz dost dlouho podporuje ACL, a muzete si je nastavovat u vseho, na co mate prava. A navic neco za vas nastavi i HAL, mate-li ho. Proste okamzikem prihlaseni (zaregistrovani u ConsoleKitu) dostanou nektere soubory v /dev daneho uzivatele do ACL. A tady se projevi vyhoda HALu - HAL totiz rozlisuje i mezi dost podobnymi zarizenimi pripojenymi pres tutez sbernici: napriklad vi, ze beznemu uzivateli prihlasenemu na konzole nema dat pravo zapisu na systemovy disk /dev/sda, zatimco mu klidne da pravo zapisu na /dev/sdb, coz je treba fotak nebo ctecka karet.

Ve zbytku komentare jsem bohuzel nenasel zadnou konkretni pripominku, ke ktere bych se mohl vyjadrit. Rekl bych ze ten zbytek (posledni 4 odstavce) je presne to, o cem mluvim v posledni otazce toho rozhovoru (neberte si to osobne).

-Yenya

[mirec]

HAL má isté výhody. Ja ho používam minimálne kvôli trackpointu. Vďaka HAL-u je možné samostatne nastaviť vlastnosti každého zariadenia, s ktorým pracuje X.org. Preto si teda môžem nastaviť citlivosť pre každú myš zvlášť, každá klávesnica môže mať nastavený iný model, inú mapu kláves a pod.

[jano]

My v praci pouzivame ClearCase,.. ten tiez umoznuje snapshot-y, ale nikto nie je taky samovrah aby to skusal, projektove voby maju niekolko GB a maintanuje sa niekolko verzii, takze aj keby clovek to miesto nasiel, checkout by trval nejaky ten cas. Git je velmi optimisticky ladeny, to znamena mergujeme smerom dopredu a dozadu sa niekto zriedka ohliadne. To co mi na git-e chyba najviac je nejaky version tree v style clearcase, pri vacsom pocte branch-i je ten gitovsky neprehladny (qgit, gitk). Rovnako by sa zisla aj moznost vidiet version tree nielen pre cele commity, ale aj pre jednotlive subory.

[Andrej Herceg]

Rovnako by sa zisla aj moznost vidiet version tree nielen pre cele commity, ale aj pre jednotlive subory.

Niečo ako gitk subor?

[jano]

Presne! Ale skutocny tree a nie tu splet vodorovnych ciar, co produkuje gitk.

[Lukáš Benda]

Spleť vodorovných čar. To znamená spleť rovnoběžek .

[kralyk z abclinuxu]

Prohlídl jsem si porovnání na wiki jakož i několik vygooglovaných článků na to téma a usoudil jsem, že nasadím mercurial. Takže se s tím těd seznamuju a vypadá zatím fajn...

Že má o několik procent nižší výkon mi fakt nevadí, nejsem totiž velká mezinárodní firma ale hobby-programátor (zatím, od září student ). Naopak má některé výhody jako že je celkom user-friendly atd...

[Adilkhatri]

검증된 파워볼사이트 를 찾으신다면 eos파워볼사이트 가 있는 파워볼사이트추천 에서 파워볼 을 즐기시길 바랍니다. 5년 이상 운영된 메이저업체 이며 지금까지 많은분들께 사랑받은 안전한파워볼사이트 입니다. 안전한파워볼사이트