Linus priča o svom omiljenom source code management alatu: http://www.youtube.com/watch?v=4XpnKHJAok8 (priča je poprilično općenita)
Malo je oštar prema starijim alatima, al je generalno čitava prezentacija veoma zanimljiva.
btw, koristi li ko (distribuirane) SCM alate novije generacije? Ako niste probajte Mercurial ili GIT, prijatno ćete se iznenaditi 
Evo ja sam danas isprobao git i mogu vam reci da ima vise mogucnosti od mercuriala. Svidja mi se “bisect” funkcija za trazenje “bugova” (nekoliko revizija oznacis sa “good” nekoliko drugih sa “bad” i onda ti git nadje linije u kojim je moguce da se nalazi BUG).
Takodje Rails community je poludio za git-om. Oficijelni rails repozitorij je migrirao sa svn-a bna git, a taj primjer su pratile i 5-6 drugih, manje poznatih ruby web frameworka. Takodje otvoren je i project hosting site www.github.com koji izmedju ostalog daje besplatan git hosting …
Meni lično git je mrvicu zakomplikovan (blago rečeno), ali kao i izbor editora, izbor SCM sistema je izrazito “religiozna” stvar. Ono što je bitno za sve alate novije generacije (donekle uključujući i SVN) jeste da je moguća konverzija u svim smjerovima.
Mercurial ima convert ekstenziju, mislim da i git ima nešto slično. Tako da ja recimo mogu koristeći hg (inkrementalno) vući izmjene sa nekog GIT repozitorija, a ako baš hoću biti koristan, šaljem izmjene na upstream mailom (patchbomb, git diff format), ili kažem upstream developerima da povuku izmjene s mog repozitorija.
Ukratko, svako ko koristi git, hg, bzr, darcs, monotone is my friend 
Git ima i git svn ekstenziju koja mu omogucava da “klonira” repozitorij sa svn-a i … nakon manipulacija da radi i “push” na svn ponovo …
Salji na ovaj repo, skidaj sa onoga, merge-aj ondje, bisect-uj tu… nije ni cudo sto Linus merge-a povazdan. Kako je krenulo, kompanije ce poceti zaposljavati i “merge majstore”, jer “bum” developeri ne bi nista drugo radili.
A ti predlažeš kakvu alternativu?
Ma to je samo konzervativnost starijih ljudi :)))
Uostalom kernel je UVIJEK bio na distribuiranom source code management alatu …
(i prije nego sto je napravljen git)
A ti predlažeš kakvu alternativu?
Nesto sto ne zahtijeva na stotine merganja prije nekog releasea. Naziv vec znate
Ma to je samo konzervativnost starijih ljudi
Bitno je ono u cemu je neko produktivan a ne neki buzzword na koji se neko (privremeno) nalozi. Kernel ekipa je produktivana sa distribuiranim scm-ovima a kde ekipa sa centralizovanim.
Resistance is futile 
Džaba se trudite, za par godina više neće biti ni jednog klasičnog “centraliziranog” VCS alata.
Distribuirani VCS alati su tehničkim rječnikom nadskup centraliziranih (znači podržavaju i klasični CVS like workflow), te su vrlo često konzistentniji i lakši za korištenje (barem u slučaju Mercurial-a).
Na CVS-u ne koristiš brancheve, merge, i pogađaš uz pomoć kockica koji commit je uzrokovao bug/regression?
[quote=Sanel]> Ma to je samo konzervativnost starijih ljudi
Bitno je ono u cemu je neko produktivan a ne neki buzzword na koji se neko (privremeno) nalozi. Kernel ekipa je produktivana sa distribuiranim scm-ovima a kde ekipa sa centralizovanim.[/quote]
Pa ne bih bas rekao. Prije bih rekao da nije bilo (dobrih) open source distribuiranih SCM-ova pa su ljudi koristili cvs … poslije inercijom presli na svn …
Sad vjerovatno jesu produktivniji na onom na kojem jesu, a koliko bi bili produktivni (i za koliko vremena bi dostigli tu produktivnost) da predju na distribuirani SCM je diskutabilno.
Definitvno glavna prednost dist. scmova je to sto mozes kad hoces uraditi “commit” bez da te neko kritikuje sto se ne moze kompajlirati a to se desava cak i u malim timovima i na malim projektima.
Vec neko vrijeme po Adisovom “naputku” sam probao koristiti mercurial. Posto dosad nisam radio na nekom vecem projektu mozda nisam kompetentan pretjerano ali moram reci da jednostavnost mercuriala je ono zbog ceg mi se svidio. Svi vjecito govore da sve sto se radi treba se drzati KISS metodologije, ako mercurial nije to, ne znam sta jest. U usporedbi sa svnom kojeg koristim za OpenOffice stranicu, mercurial je 10 puta ljepsi, laksi i manje zbunjujuci.
Džaba se trudite, za par godina više neće biti ni jednog klasičnog “centraliziranog” VCS alata.
Mozda tacno, ali “centraliziran” pristup ce biti tu jaaakooo dugo. Toliko projekata zuri da ih pocne koristiti (jesam rekao, buzzword), a zadrzavaju se na starom nacinu rada. Kernel-way nije za sve projekte.
Na CVS-u ne koristiš brancheve, merge, i pogađaš uz pomoć kockica koji commit je uzrokovao bug/regression?
Hm… cemu sluze revizije? Ako je ovo argument “za” distribuirane scm-ove, koliko je relevantan? Merger moze napraviti istu gresku i opet roviti po revizijama (hint. Linusova “greska” za merganje bugovitog IDE koda; ili je ono bio pata…)
Prije bih rekao da nije bilo (dobrih) open source distribuiranih SCM-ova pa su ljudi koristili cvs
Koliko se sjecam, u cvs doba pojam “distribuirani” je jos uvijek bio nesto u sferi SF-a (i onog idiota iz bitkeeper-a).
Definitvno glavna prednost dist. scmova je to sto mozes kad hoces uraditi “commit” bez da te neko kritikuje sto se ne moze kompajlirati a to se desava cak i u malim timovima i na malim projektima.
Valjda za to postoje branch-evi
Pa postoje ali ih ljudi koriste svake prestupne godine 
Uostalom bezveze je sto centralni server mora znati da je hamo napravio branch … dakle danasnji centralizovani scmovi ne olaksavaju branching nego ga otezavaju …
Steta sto si izostavio narednih par recenica u citatu… 
(pretpostavljam da ti se “omaklo”).
Mislim da se nije ništa omaklo, link na čitav članak je priložen, a u nastavku kaže još i
Što samo potvrđuje moju poentu da je SVN vjerovatno posljednji centralizirani SCM u open source svijetu. Tvoja poenta je?
SVN je totalni ćorsokak, trenutno svi popularniji DVCS alati imaju 100% funkcionalnost kao SVN, iako je SVN imao prednost od 5 godina.
Lično mislim da je SVN projekat apsolutno uspio. Ostvarili su svoj zacrtani cilj, poboljšali su i u uspješno zamijenili legacy sistem (CVS). Slično će sada osjetiti na svojoj koži 
U krajnoj liniji, meni je apsolutno svejedno kakav ko softver koristi i da li je otvoren za (potencijalno) zanimljivije i bolje alternative. Najviše što želim postići jeste pokazati te alternative, a na vama je da odlučite šta hoćete ili nećete koristiti.
Tvoja poenta je?
Da ce on tu biti jos jako dugo.
Malo si koji projekat moze priustiti kernelov nacin developmenta (osim ako developeri ne odu na 6-to mjesecno “savjetovanje” kod Linusa), dok s druge strane koriste alate koji su specificno napravljeni za to. To je kao… koristenje haskella na imperativan nacin: moguce, ali totalno lame.
Npr. bilo je prica da se gnome prebaci na git (zbog translatora i dokumentacije), ali kada su vidjeli da bi tone brancheva bilo vise problem nego rjesenje i kako bi uvodjenje nekog reda u njihovo merganje vjerovatno zahtijevalo osobu (ili osobe) koje bi samo to radile, malo su se prizemljili.
SVN je totalni ćorsokak, trenutno svi popularniji DVCS alati imaju 100% funkcionalnost kao SVN
…ali taj SVN nikako da crkne :P. Damnit!!!
U krajnoj liniji, meni je apsolutno svejedno kakav ko softver koristi
Malo diskusije valjda ne skodi
Ponavljam, nema razloga da DVCS ne podržava centralizirani model (mercurial primjer), ili za malo veće/komplikovanije stvari pogledati kako to radi Sun (oni koriste Mercurial pri razvoju JDK-a, OpenSolaris-a i NetBeans-a), imaju par “centralnih repozitorija” i u pozadini onoliko repozitorija koliko je potrebno da se posao dovrši
(znači, ništa crno-bijelo, već sivo; hibridni pristup)
“Tona brancheva” jeste čisto stvar terminologije. Svaki put kada lokalno radiš izmjene na nekom softveru ti kreiraš branch, i svaki put kada snimaš izmjene nazad na server radiš merge. To vrijedi i za CVS/SVN i za Mercurial/Git. U čemu je razlika? Svi DVCS alati drže čitavu kopiju repozitorija lokalno, te su za njih svi repozotoriji jednako važni, dok CVS/SVN kanonskim smatra samo udaljeni repozitorij (aka “server”).
SVN je tek u verziji 1.5 dobio podršku za merge tracking, dok je to po prirodi sastavni dio svakog DVCS-a. U slučaju merge konflikta, DVCS alati mogu pokušati automatski merge resolution (3-way merge, codeville merge), ili ako to ne uspije prepustiti odluku korisniku (npr. pokrenuti kdiff3).
