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í
×
24.10. 22:52 | Nová verze
Vývojáři Raw editoru RawTherapee vypustili verzi 4.2. Ta obsahuje nové nástroje (například barevné tónování, simulaci filmu), přidává podporu pro nové fotoaparáty a přináší řadu výkonnostních a paměťových optimalizací.
Marián Kyral | Komentářů: 12
24.10. 09:39 | Nová verze
Laboratoře CZ.NIC dnes vydaly novou verzi (1.6.0) autoritativního DNS serveru Knot DNS. Tato verze přináší podporu perzistentních časovačů pro události zóny (refresh, expire a flush), jejichž stav bude zachován i během restartu serveru. Zároveň se jedná o verzi s prodlouženou dobou podpory (LTS, Long-Term Support). Více informací naleznete na poštovní konferenci Knot DNS Users.
Vilem Sladek | Komentářů: 17
24.10. 01:23 | Zajímavý projekt
Studio Weybec ve spolupráci s Blender Institute představilo krátký pětiminutový open-source film Monkaa (YouTube). Film byl vytvořen pomocí Blenderu, GIMPu a dalšího otevřeného softwaru. Zájemci o datové soubory uvolněné pod licencí CC-BY si mohou zakoupit DVD nebo předplatit přístup do Blender cloudu.
Ladislav Hagara | Komentářů: 21
23.10. 21:30 | Nová verze
Bylo vydáno Ubuntu 14.10 s kódovým jménem Utopic Unicorn. Ke stažení jsou k dispozici Ubuntu Desktop a Server, Ubuntu Cloud Server, Ubuntu Netboot, Ubuntu Core, Kubuntu, Lubuntu, Ubuntu Studio, Ubuntu GNOME, Ubuntu Kylin, Xubuntu a Mythbuntu. Podrobnosti v poznámkách k vydání.
Ladislav Hagara | Komentářů: 0
23.10. 14:08 | Zajímavý článek
Ovladač čipů FTDI pro Windows naštval spoustu uživatelů čínských napodobenin tím, že u těchto napodobenin mění ProductID v EEPROM na 0, čímž zabrání jejich fungování nejen ve Windows, ale i v Linuxu.… více »
David Šmíd | Komentářů: 143
22.10. 23:34 | Komunita
V Düsseldorfu proběhla minulý týden GStreamer Conference 2014, tj. konference vývojářů multimediálního frameworku GStreamer. Videozáznamy přednášek jsou k dispozici na portálu UbiCast's WebTV.
Ladislav Hagara | Komentářů: 0
22.10. 12:32 | Zajímavý článek
Satya Nadella, CEO Microsoftu, ve svém vystoupení věnovaném cloudové platformě Microsoft Azure (Wikipedia) zmínil také Linux. Přímo řekl, a v prezentaci zdůraznil, že Microsoft má rád Linux (Microsoft ♥ Linux, webcast, 13:55). Důvod je jasný. Linux běží na 20 % Azure.
Ladislav Hagara | Komentářů: 26
22.10. 10:48 | Pozvánky
GDG Prague a GDG Unicorn College pořádá v sobotu 1.11.2014 od 9:30 v Praze celodenní Dart + Polymer Hackathon. … více »
Gug.cz | Komentářů: 0
21.10. 00:36 | Nová verze
Vyšel Emacs 24.4. Mezi novinky patří vestavěný webový prohlížeč (M-x eww), podpora více monitorů, celoobrazovkový mód, digitální podpis balíčků, podpora menu v textovém terminálu či nový blokový mód. Více informací v oznámení nebo v historii viditelných změn na stránce projektu.
little.owl | Komentářů: 23
20.10. 19:57 | Pozvánky
Jana Moudrá Vás 15. listopadu v budově Pilsfree v Plzni seznámí s novým skriptovacím jazykem Dart. Uvidíte spoustu ukázek a bude i prostor pro diskusi. Během následující codelab si můžete nabyté zkušenosti procvičit. … více »
hacup | Komentářů: 0
Disketu jsem naposledy použil během
 (45%)
 (0%)
 (18%)
 (36%)
 (0%)
Celkem 11 hlasů
 Komentářů: 2, poslední dnes 00:17
Rozcestník
Reklama
Autoškola testy online Levný benzín

Jan "Yenya" Kasprzak o Gitu

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

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.czlistserver 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“.

jan yenya kasprzak

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, HALD-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.

       

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ář

26.6.2009 02:12 eoj
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Čtu a najednou už je konec, jako by tomu něco chybělo.
26.6.2009 10:56 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Třeba poděkování za pěkný rozhovor/článek?
27.6.2009 01:02 eoj
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Ne, poděkování za rozhovor tam je...
3.7.2009 15:50 a
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

treba nebylo

zoul avatar 26.6.2009 06:36 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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í.
26.6.2009 09:40 Peto
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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...

26.6.2009 10:07 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

26.6.2009 13:11 Leoš Literák | skóre: 74 | blog: LL | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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?

Zakladatel tohoto portálu. Twitter, LinkedIn, blog
zoul avatar 26.6.2009 13:21 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 13:23 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

26.6.2009 13:39 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ů).
26.6.2009 11:36 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 12:29 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.)
26.6.2009 13:31 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 15:45 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 18:55 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 19:48 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 19:54 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 20:15 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 20:26 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Ú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ě.
26.6.2009 20:40 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Pak by to dopadlo takhle nějak :-)
Lukáš Benda avatar 29.6.2009 07:52 Lukáš Benda | skóre: 12 | blog: benBlog | Štítina
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
Google bomba: benzin blog
29.6.2009 08:13 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Předpokládám, že šlo o XLS (Excel), a ne XSL (eXtensible Stylesheet Language).
29.6.2009 13:44 Leoš Literák | skóre: 74 | blog: LL | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

Zakladatel tohoto portálu. Twitter, LinkedIn, blog
26.6.2009 09:55 bibri | skóre: 33 | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

>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.

26.6.2009 10:07 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Vše nejlepší ke včerejšímu svátku... ;-)
Jakub Lucký avatar 26.6.2009 13:17 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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...
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
29.6.2009 10:02 David Jaša | skóre: 44 | blog: Dejvův blog
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Bohužel, já se v Debianu spíš setkávám s opakem...
Ubuntu, stejná zkušenost. Bohužel...
26.6.2009 10:02 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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$.

 

Pavel Kysilka - www.linuxsoft.cz
Jakub Lucký avatar 26.6.2009 11:24 Jakub Lucký | skóre: 40 | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
http://git.or.cz/gitwiki/EclipsePlugin

Evidentně se na něm pracuje...
If you understand, things are just as they are; if you do not understand, things are just as they are. (Zen P.) Blogísek
26.6.2009 12:06 Vladimir Kralik
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

 

26.6.2009 13:22 Pepa
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

 

zoul avatar 26.6.2009 13:36 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Pokud si dobře vzpomínám, Linus říkal, že je na tom Mercurial dost špatně s výkonem.
26.6.2009 13:45 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

26.6.2009 10:06 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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...
26.6.2009 10:32 linear | skóre: 9 | blog: pozor
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

26.6.2009 10:55 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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é.
26.6.2009 13:27 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
make menuconfig, not war!
zoul avatar 26.6.2009 13:11 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 13:12 Cohen | skóre: 18 | blog: Drobnosti | Brno
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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 2160 různých možností, jak se vstup zahashuje – uvědomte si, že 2160 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 2512 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.

OpenPGP key fingerprint: 1CB2 41B9 F029 4B47 EECD 9BDA 90C9 CEB0 524C DACB (https://www.fi.muni.cz/~xruzick7/pgp-klic/)
26.6.2009 10:53 Lukáš Zapletal | skóre: 42 | blog: lzapův svět | Olomouc
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 11:34 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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 avatar 26.6.2009 12:41 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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é…?
26.6.2009 13:41 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 16:51 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 18:59 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 13:51 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Pokud je klíčový výraz „u sebe“

Ne, klicovy vyraz je "vetev".

-Yenya

zoul avatar 26.6.2009 15:47 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ě.
27.6.2009 10:48 mikro
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

27.6.2009 11:08 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 27.6.2009 12:34 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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í.)
29.6.2009 14:31 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

29.6.2009 15:52 Karell
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

 

29.6.2009 16:14 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

26.6.2009 13:07 Leoš Literák | skóre: 74 | blog: LL | Praha
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

Zakladatel tohoto portálu. Twitter, LinkedIn, blog
26.6.2009 13:48 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

-Yenya

26.6.2009 19:21 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Rational Jazz
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.
26.6.2009 20:06 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Rational Jazz
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é.
26.6.2009 23:21 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Re: Rational Jazz

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.

27.6.2009 10:27 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Rational Jazz
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.
27.6.2009 22:02 z/OS
Rozbalit Rozbalit vše Re: Rational Jazz
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.
29.6.2009 12:32 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: Rational Jazz
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.
28.6.2009 20:26 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Re: Rational Jazz
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.
29.6.2009 15:08 Yenya
Rozbalit Rozbalit vše Re: Rational Jazz

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

3.7.2009 22:29 Radim Kolář | skóre: 11
Rozbalit Rozbalit vše Re: Rational Jazz

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

29.6.2009 16:48 Karell
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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...

29.6.2009 19:40 petr_p | skóre: 58 | blog: pb
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

kralуk avatar 29.6.2009 19:55 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Jo, to je dnes v módě. Když řeknete, že cokoliv dává svobodu, hned to lidi pozitivně naladí :-D
29.6.2009 21:08 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ý :-D

Čímž se nechci nijak stavět na stranu DVCS, natožpak Gitu, jen prostě realita není černobílá.
Ještě na tom nejsem tak špatně, abych četl Viewegha.
26.6.2009 11:40 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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).
26.6.2009 14:10 l4m4
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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 avatar 26.6.2009 14:15 mirec | skóre: 28 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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).
LinuxOS.sk | #11037 | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
26.6.2009 15:51 Milan Jurik | skóre: 21 | blog: Komentare | Ova
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 23:32 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
27.6.2009 19:53 z/OS
Rozbalit Rozbalit vše proc Bazaar
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.
29.6.2009 15:23 Yenya
Rozbalit Rozbalit vše Re: proc Bazaar

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 avatar 29.6.2009 16:35 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: proc Bazaar
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ží.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
29.6.2009 21:36 Yenya
Rozbalit Rozbalit vše Re: proc Bazaar

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 avatar 30.6.2009 08:23 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: proc Bazaar
K čemu? Přece víš, o jaký software se jedná.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
zoul avatar 30.6.2009 15:50 zoul | skóre: 43 | blog: | Boskovice
Rozbalit Rozbalit vše Re: proc Bazaar
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í.
kralуk avatar 30.6.2009 16:56 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: proc Bazaar
Pokud tomu dobře rozumím, tak v distribuovaném systému musíš čísla revizí nějak synchronizovat.
Synchronizovat? Snad ne centralizovaně? :P
1.7.2009 11:15 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: proc Bazaar
Proč centralizovaně? Stačí statisticky – použít hash, kde je riziko konfliktu bezvýznamné.
26.6.2009 14:41 Karell
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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 avatar 26.6.2009 16:29 alblaho | skóre: 17 | blog: alblog
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
26.6.2009 22:50 Palo
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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 avatar 27.6.2009 12:34 Josef Kufner | skóre: 64
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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" ;-)
Hello world ! Segmentation fault (core dumped)
27.6.2009 23:47 nh
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
28.6.2009 18:15 Karell
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

29.6.2009 09:13 Pev | skóre: 28
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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é?
29.6.2009 10:36 Karell
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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.

kralуk avatar 26.6.2009 23:11 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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é...
26.6.2009 23:40 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
Na HAL a D-Bus nadavam dodnes, a nejsem sam... pravda, jsme spis banda vousatych mudrlantu z pochybnych univerzit :o)
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
stativ avatar 27.6.2009 13:29 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ší.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
mirec avatar 27.6.2009 14:38 mirec | skóre: 28 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ť.
LinuxOS.sk | #11037 | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
kralуk avatar 27.6.2009 14:44 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
No jo, to je takovej ten bohatýrskej přístup ve stylu "Nejlepší dokumanteace je zdrojový kód" :-D
kralуk avatar 27.6.2009 14:45 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
dokumentace
stativ avatar 27.6.2009 19:00 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
To jsem neřekl. Myslel jsem to tak, že doufám, že to nebude takový moloch.
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
27.6.2009 19:41 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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)
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
stativ avatar 27.6.2009 20:34 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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…
Ať sežeru elfa i s chlupama!!! stativ.kx.cz
27.6.2009 20:59 Martin B. | skóre: 28 | blog: hromada
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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].
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
27.6.2009 21:45 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
"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)
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
28.6.2009 11:23 Martin B. | skóre: 28 | blog: hromada
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
Josef Kufner avatar 28.6.2009 14:57 Josef Kufner | skóre: 64
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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ý.
Hello world ! Segmentation fault (core dumped)
28.6.2009 16:49 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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?
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
28.6.2009 17:24 Martin B. | skóre: 28 | blog: hromada
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
28.6.2009 17:34 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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".)
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
29.6.2009 14:46 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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

29.6.2009 16:01 Martin Böhm | skóre: 17 | blog: Martinův stánek | Je mi to MFUK
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
5 z 0 přetečení bufferu doporučuje Korespondenční seminář z programování (pro středoškoláky programátory).
29.6.2009 16:20 Fa & Bi | skóre: 65 | blog: Delfinárium
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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á.
29.6.2009 16:28 Pev | skóre: 28
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
(desim se dne, kdy vim bude zaviset na d-busu)
Tak toto mě opravdu rozesmálo :-).
29.6.2009 16:42 Yenya
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu

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 avatar 28.6.2009 08:49 mirec | skóre: 28 | blog: mirecove_dristy | Poprad
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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.
LinuxOS.sk | #11037 | USE="-fotak -zbytocnosti -farebne_lcd +vydrz +odolnost +java" emerge telefon
26.6.2009 23:15 jano
Rozbalit Rozbalit vše Snaphost u seba
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.
26.6.2009 23:32 Andrej Herceg | skóre: 43
Rozbalit Rozbalit vše Re: Snaphost u seba
Rovnako by sa zisla aj moznost vidiet version tree nielen pre cele commity, ale aj pre jednotlive subory.
Niečo ako gitk subor?
27.6.2009 11:43 jano
Rozbalit Rozbalit vše Re: Snaphost u seba
Presne! Ale skutocny tree a nie tu splet vodorovnych ciar, co produkuje gitk.
Lukáš Benda avatar 29.6.2009 09:24 Lukáš Benda | skóre: 12 | blog: benBlog | Štítina
Rozbalit Rozbalit vše Re: Snaphost u seba
Spleť vodorovných čar. To znamená spleť rovnoběžek :-D.
Google bomba: benzin blog
kralуk avatar 29.6.2009 20:01 kralуk | skóre: 27 | blog: Untitled
Rozbalit Rozbalit vše Re: Jan "Yenya" Kasprzak o Gitu
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...

Založit nové vláknoNahoru

ISSN 1214-1267   Powered by Hosting 90 Server hosting
© 1999-2013 Argonit s. r. o. Všechna práva vyhrazena.