Linus Torvalds a Gitről és a többiről

Vélemény

Torvalds folytatja "Linus szerint" előadássorozatát, ezúttal az SCM-eket veszi górcső alá a Google-nél tartott fellépésében.

Pár fontosabb vélemény a többi megoldásról:

  • Subversion has been the most pointless project ever started.
  • Subversion used to say CVS done right: with that slogan there is nowhere
    you can go. There is no way to do CVS right.
  • If you like using CVS, you should be in some kind of mental institution or
    somewhere else.
  • Get rid of Perforce, it is sad, but it is so, so true...

A video a Google-nél flash-sel:

és .avi-ban is elérhető:

http://www.meebey.net/temp/Tech%20Talk:%20Linus%20Torvalds%20on%20git.avi

( phanatic | 2007. 06. 03., v – 18:01 )

nagyon élvezetes előadás volt szerintem sok igazsággal...
--
ubuntu linux member

attól hogy egy hozzászóláson belül van az idézet és az egoista szó, még nem feltétlenül kapcsolódnak össze (ahogy én sem kapcsoltam őket össze), csupán egy végszóként, csattanóként biggyesztettem oda azt a mondatot...

a humorérzékem pedig köszöni jól van (majdnem végigröhögtem az egész előadást) - még angolul is.
--
ubuntu linux member

Nekem az a rész tetszett mikor:
"Azon gondolkodtam, hogy tudnék-e 2 hét alatt valami jobbat írni, mint ami most van és igen tudtam, igazam volt. :)
---
A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station

( Huncraft v | 2007. 06. 03., v – 19:16 )

Csak nekem vicces az, hogy a google a saját videót nem a vide.google.com-ra pakolja, hanem az általa megvett youtube-ra? :)
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

( bastya_elvtars | 2007. 06. 03., v – 19:44 )

Azt olvastam, hogy a CVS-t azért szeretik sokan, mert minden szart flatfile-ban tárol, ergo ha sérül valami a repóban, könnyű javítani.
Meg persze hagyomány.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

A CVS akkor jó, ha 1 ember tárolja benne a fejlesztéseit. Ha több ember van már gondok vannak. Ha patcheket kell alkalmazni, ágakat létrehozni, majd mergelni már nagyon kényelmetlen. De sokkal könnyebb javítani egy elosztott rendszerben, ahol lehúzod a szomszédtól, ami nálad sérült nem?
--
A bus station is where a bus stops. A train station is where a train stops. On my desk, I have a work station

Én nem azt mondtam, hogy jó a CVS, sőt ez nem is az én véleményem.
Egyébként meg ahogy néztem, a git azért jó, mert tud (hellyel-közzel) cvs-kompatibilis üzemmódban futni.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

( arpi_esp v | 2007. 06. 03., v – 21:04 )

Megjegyzem, az ffmpeg(+mplayer) is most ter at git-re, volt elotte egy jo hosszu thread ahol kiveseztek a cvs vs. svn vs. git temat. Gyakorlati tapasztalatokkal mindegyik mellett/ellen. A git ellen talan az volt az egyetlen negativum, hogy sokaig tart az initial checkout, de ez orvosolhato egy snapshot tarballal.

A'rpi

Ezt magyarázd el barátnőmnek, aki Windows-t használ, gui-s mplayer-rel. De a hangsávváltás még ennél is borzasztóbb.
Viszont kezelhetőségben még mindig az mplayer a nyerő, ezt aláírom.
--
'Please, just tell people to use Windows.' - Linus Torvalds on KDE and GNOME
Registered M$funboy #006 (vigyázat: memetikai dágvány!!!11)

hatja.. kell kompromisszumokat kotni:)
de a win-es progik is haladnak a bloatware fele.. nero 100+ mega.. _az embernek_ pedig csak egy qva cd/dvd iro kell!! nade itt van a kis mplayer ami tenyleg feature-less (VPS hivoknek) de gyorsabb mint mindegyik/sok player, meg a mediaplayerc eleg jo. adol egy configure --helpet mplayernek azert ott is van par dolog ami *neked* nem kell meg sok default usernek se

Szerintem sosem lesz. En ezt megmondtam 5 eve is, es tartom a velemenyem. Ahhoz ui. teljesen ki kene forditani az egeszet, pont forditva kene mukodnie az egesz pipeline-nak.

Az mplayerben igy van: az audio out diktalja a tempot (nosound eseten a timer), ehhez van szinkronizalva a video output (fps alapjan), az huzza a filtereken at a codecet, a codec pedig hivogatja a demuxert, ha kell meg neki adat, a demuxer pedig az input/streaming layert ami olvass a a filet ha kell.

A dvd navigacio pedig ugy van kitalalva, ahogy a hw dvd lejatszok mukodnek: ezekben van egy hw mpeg2 decoder chip, ami ugy megy, ha kap a bemenetere egy framenyi adatot, akkor azt hirtelen dekodolja es kirakja a framebufferbe ami emiatt megjelenik a kepernyon.
A dvd navigacio lenyege, hogy egy virtualis gepben futo menu-program hajtodik vegre, ami szabalyozza mikor honnan es mennyit kell olvasni a diskrol es kuldeni a decoder chipnek. Ha csak 1 framenyit kuld, megjelenik 1 kep (menu), ha tobbet akkor animacio. Ha semmit, akkor all a kep (still frame).

Igy mar talan ertheto, hogy miert nem lehet ezt (maximum orbitalis nagy ganyolassal/hackelessel) megoldani az mplayer g1-ben, es a g2-ben sem. Persze mindig vannak akik nem adjak fel, es megprobaljak a lehetetlent, tobb-kevesebb sikerrel.

A'rpi

( ropi | 2007. 06. 04., h – 08:23 )

rendkivul szenzaciohajhasz, paraszt eloadas volt, az biztos. raadasul a "cvs/svn nem jo, en meg a git kiralyok vagyunk" ervelesen kivul _semmi_ lenyeges nem hangzott el. vagy lehet, hogy en vagyok a gyik, es meg mindig nem ertem, miert jo az, ha egy kontrollalt kornyezetben levo developpa sajat maganal mutyizgat, aztan
a) beszarik a gepe es sir, hogy jaj elveszett a kod, hiaba kommitolta,
b) nem tudja megosztani a kodot, mert ul a kis modemje/gprs kapcsolata mogott (ha mar a vonaton is dogozik es felpusholna valami publik helyre)
c) merge-elne mas emberekkel a munkat, csakhogy mindenki sajat maganal mutyizott, es van harom kurvara kulonbozo forrasfa (ergo kurvanehez a merge, es tudja a fene, hogy ki mergeljen).

eddig svnben ugy csinaltuk, hogy gyakori commitok a trunkbe (jatszoterre sajat branch) es gyakori update-ek segitsegevel mindenkinel aranylag konzisztens volt a trunk forrasa, a jatszoter meg mindenkinek sajat, az kit erdekel, nyilvan. ugy tunik, hogy a jatszotereket erositi az elosztottsag, a trunk jellegu dolog meg eltunik (vagy korulmenyesebben erheto el, na).

ha meg kvazi elkeszult egy riliz, akkor kapott egy taget es egy patch branchet, utana mindenki orult. semmi gond nem volt ezzel addig, amig valaki be nem kommitolt mindenfele nem kello (sot, masok szamara artalmas ;]), PATH elemeket tartalmazo sajat konfiguraciot.

ne ertsetek felre, nem agresszivkodas ez, csak meg mindig nem latom at az elosztott scm uberalles josagat. valaki segitsen ma' :)

- Elosztott rendszerrel megvalósítható a központosított, vagyis dolgozhatsz úgy, hogy mindenki egy központi repóba push-ol, és onnan is pull-ol.
- Központi rendszerben is elveszted a helyi másolatodon végzett, nem kommitált módosításaidat egy összeomláskor. Nyilván ajánlatos elosztott rendszerben (is) gyakran "kommitálni" ennek kivédésére, ráadásul több (backup) helyre is mehet - ami központosított rendszerrel kicsit nehézkesebb.
- Az tény, hogy a brancsok könnyebben el tudnak menni egymás mellett, ezért egy eloszott rendszerrel (még) fontosabb a fejlesztők közti kömmunikáció és együttműködés.

Linus stílusát tényleg szokni kell, de ha csak ez maradt meg benned az előadásból, akkor elszalasztottad a lényeget a gitről, a kernel fejlesztésének munkammenetéről, performanciáról, megbízhatóságról, az együttműködés ösztönzéséről, stb.

- elosztottal nyilvan megvalosithato a kozpontositott stilus, mint ahogy traktorral is mehetek diszkoba, csak nem szorgalmazza senki ;)
- nyilvan elveszthetem, de mivel gyakran kommitolok, a kommit pedig egy aranylag megbizhato helyre megy, nem annyira kell felnem, mintha a sajat gepembe ontenek egy pohar vizet (mint ahogy az megtortent mar)
- ezt a "brancsok konnyebben tudnak menni" szlogent nem ertem. svnben is tudok brancsolni, innentol kezdve csak a kommit helye az, ami valtozik (local vs. remote)

az teny es valo, hogy a merging valoban csak okosabb lehet a svn merge-nel, es hogy egy alap, mukodo szoftver eseten a "jatszoter" uzemmod sokkal jobban hasznalhato egy elosztott rendszerrel. csak kontrollalt kornyezetben (aka munkahely) es normalis fejlesztesi modellben (tehat nem cowboy codingnal) azert nagyjabol lehet tudni, hogy kinek mit kell csinalnia a kovetkezo milestone-ig, es nincs helye a mutyizos megoldasoknak, a kozponti, folyamatos integracionak meg de.

a gitrol valoban csak annyi maradt meg, hogy a nagyarcu linukszisten irt egyet c-ben (es hogy a mercurial full python alapu elosztott rendszere gyorsabb meg valamennyivel tobbet is tud, csak errol nem szolt semmit), a kernel fejleszteserol (tarball+patchek kuldese) meg linus "en vagyok a legkiralyabb, mindenki mas segg, az scm meg alapjaban veve szar" mentalitasarol inkabb nem mondanek semmit 2007-ben ;)

Csak a nagyarc temahoz vonatkozoan: nekem az jott le, hogy fokent a kozonseg szorakoztatasara csinalta. A 20. ilyen poen utan mar szamomra is vesztett a fenyebol a vicc, de nekem nem jott le, hogy tenyleg nagy lenne az arca, hanem sztem hulyeskedett. Persze most lehet irni, hogy egy ekkora publicitasra szamot tarto eloadasnal etikus-e igy poenkodni, de sztem miert ne, igy nem lesz olyan szaraz az anyag :)
Aki meg fel akar haborodni, az legalabb haboroghat (itt nem feltetlen rad gondolok) :)

- itt nem arról van szó, hogy normális autóval vagy traktorral menj dizsibe, hanem hogy egy olyan autóval menj, ami csak dizsibe való, vagy olyannal, amivel lehen menni mondjuk még kocsmába vagy nőzni is :)
- mint írtam - elosztott rendszerben is nyomhatod (akár több) "megbízható" helyre a módosításaidat - szerintem ebben nincsen különbség a kétfajta megközelítés között
- azt azért kicsit nehézkes megoldani központosítottal, hogy több helyre "kommitolj" vagy több helyről "updatelj" - mindezt mindenféle külső "varázslás" nélkül

Szerintem nem kérdés, hogy egy elosztott verziókövető rendszer legalább annyit tud, mint egy központosított - úgy látom erről vitatkozunk. Az nyilvánvaló, hogy a fejlesztési menetet, gondolkodásmódot át kell hozzá alakítani, és Linus is mondja, hogy bizonyos (kontrollált) környezetekben akár "jobb" is lehet a központosított megközelítés.

- elosztottal nyilvan megvalosithato a kozpontositott stilus, mint ahogy traktorral is mehetek diszkoba, csak nem szorgalmazza senki ;)

Most a csomón is kákát keresel...? Teljesen szokvány workflow elosztottnál, hogy a local repóba kommitolsz, majd push-sal tolod fel a központi szerverre, ha már elérkezett erre az idő, és megvan az infrastruktúra is hozzá (online vagy). Az elosztottság nem alternatívája a központosítottnak, hanem egy plusz ahhoz képest. Az az extra lehetőség ti., hogy teljesértékű kopit kaphatsz ami kétirányú kommunikációra képes az eredetivel.

a gitrol valoban csak annyi maradt meg, hogy a nagyarcu linukszisten irt egyet c-ben (es hogy a mercurial full python alapu elosztott rendszere gyorsabb meg valamennyivel tobbet is tud, csak errol nem szolt semmit)

A hg sem full python. És honnan veszed hogy gyorsabb es hogy többet tud? Szerinted fekete-fehéren meg lehet mondani melyik a gyorsabb/okosabb? Az UI egyszerűbb és a szemantika érthetőbb a mercurialnál. Ez nekem per pillanat elég nagy fór ahhoz, hogy előnyben részesítsem a gittel szemben. De ezen túl ódzkodnék a fekete-fehér kijelentésektől.

És igenis próbált beszélni az érdemi különbségekről (git content centrikus, ellenben a többi SCM fájl [node] centrikus szemantikájával), csak ez már nehezebben érthető téma és neki sem igazán sikerült elmondania. (Én sem látom át, mi ennek az impaktja.)

Most a csomón is kákát keresel...? Teljesen szokvány workflow elosztottnál, hogy a local repóba [...]

nem, nem keresek csomot, ne ertsd felre. arra reagaltam, hogy ugyanazt a workflow-t meg lehet vele csinalni, mint ami egy kozpontositott rendszernel van.

nem tudom, ki mennyit utazik vagy van net nelkul ugy, hogy kodolnia is kellene (en nagyon minimalisan, a kert kozepeig eler a wifi), ezert valahogy nem dob fel az offline kommitolasi lehetoseg. hasznos, tenyleg, de (szamomra) marginalis kerdes. a changesetes-pusholos-mergelos dolog jatszoter-projekteknek nagyon jo, csak figyelni kell a merge-re. neha ugy tunik, hogyha egy kozponti helyre dolgoznak az emberek, akkor sokkal kevesbe kell figyelni a mergelesre.

neha meggyozom magam, hogy jobb a disztributalt rendszer, aztan eszembe jut, hogy mennyivel kaotikusabb is ;)

A hg sem full python. És honnan veszed hogy gyorsabb es hogy többet tud?

jo, igaz, a hq majdnem full python, igy jobb? ;) a githez kepest minimalis benne a lowlevel kod, na.

gyorsabb? volt valami egy evvel ezelotti bencsmark, arra alapoztam a velemenyemet, nyilvan valtozhatott ossze-vissza, bar legrosszabb esetben is mondjuk inkabb azt, hogy kb. hasonlo sebesseggel birnak.

tobbet tud? van hozza egy csomo plugin, meg van benne olyan -- nekem -- hasznos funkcio, ami a gitben nincs (a teszt szerint nem volt) ;) azert is irtam (vagy csak akartam?), hogy "talan", de legfeljebb itt is mondjuk azt, hogy kb. hasonlo a ficsormennyiseg mindket oldalon.

nem tudom, ki mennyit utazik vagy van net nelkul ugy, hogy kodolnia is kellene (en nagyon minimalisan, a kert kozepeig eler a wifi), ezert valahogy nem dob fel az offline kommitolasi lehetoseg. hasznos, tenyleg, de (szamomra) marginalis kerdes. a changesetes-pusholos-mergelos dolog jatszoter-projekteknek nagyon jo, csak figyelni kell a merge-re. neha ugy tunik, hogyha egy kozponti helyre dolgoznak az emberek, akkor sokkal kevesbe kell figyelni a mergelesre.

neha meggyozom magam, hogy jobb a disztributalt rendszer, aztan eszembe jut, hogy mennyivel kaotikusabb is ;)

OK, OK. Kicsit azokra az arcokra emlékeztet a hozzáállásod,
akik, amidőn felmerült a Java esetleges openszorszolása, elkezdtek
aggodalmaskodni itt a HUP-on, hogy jaj, mégse tegyenek már ilyet,
mert szétfragmentálódik a Java.

Én másképp láttam akkor is, de hát nem vagyunk egyformák.

gyorsabb? volt valami egy evvel ezelotti bencsmark, arra alapoztam a velemenyemet, nyilvan valtozhatott ossze-vissza, bar legrosszabb esetben is mondjuk inkabb azt, hogy kb. hasonlo sebesseggel birnak.

Amennyire én látom a helyzetet, a git sebességben és repoméretben is veri a Mercurialt, habár nem vészesen. OTOH, gitnél mindig
repackelgetni kell az obgyekteket, ha az optimális méretet fenn akarod tartani, aminek a gondolatától is égnek áll a hátamon a szőr. Ellenben a Mercurial meg szépen békésen kumulálja magát, még
csekkpointokat se kell csinálgatni, mit sok más SCM-nél.

tobbet tud? van hozza egy csomo plugin, meg van benne olyan -- nekem -- hasznos funkcio, ami a gitben nincs (a teszt szerint nem volt) ;) azert is irtam (vagy csak akartam?), hogy "talan", de legfeljebb itt is mondjuk azt, hogy kb. hasonlo a ficsormennyiseg mindket oldalon.

Erre mondja azt Ted Tso, hogy a git meg kurvajól szkriptelhető,
"without breaking into Python". Erre mondja azt valaki, hogy ez "double edged sword", mert épp az ilyenektől unix-bound a git (erre sajnos most nem lelem a referenciát). YMMV. Meg érdemes belenézni
ebbe a szálba is, ami a ficsöröket illeti...

Azt magyarázta, hogy a git relatíve lassan tud egy fájllal kapcsolatos infókat előbányászni a repójából, viszont villámgyorsan dolgozik a teljes tree-n ("nem érdeklik az egyes fájlok"), pl. csinál diffet egy könyvtárhierarchiáról, vagy olvaszt be foltot. Még azt is mondta egy kérdésre, hogy lehet részlegesen kicsekkolni tartalmat repóból, csak nem igazán lehet vele dolgozni, úgyhogy sok értelme nincsen. Azt mondta, ha valamivel külön akarsz dolgozni, akkor azt rakdd külön repóba - rossz példának hozta a kde projektet, ahol azok az összes komponenst, mindent egy repóba raktak. Az sha1 hash is az egész repótartalomra vonatkozik az egész naplóval együtt.
(nem használok git-et)