Názory k článku
GIT: distribuovaná správa revizí

Tentokrát nemáš lepší důvod k prudění, než ten, že neumíš přejmenovat soubor? ;-)

hm, ale takový urejpaný komentář je taky prudění:-)

On ho někdy neuměl? (Nepočítám-li verze 0.x.)

asi pred 1-2 lety jsem si prohlizel nejake srovnani VCS a tam psali ze ho neumi.

Jo, tak ted to umi, ikdyz dam rm, nejake zmeny, add uplne jinde, pozna to a urci podobnost, ktera je videt v diffstatu...

Pokrok je posilat patche emailem at si maintaner sam vyresi konflikty u sebe pri comittu :-) Takze GIT je vlastne lepsi diff plus par mv/cp pro udrzeni vice branchu.

Pochopitelne maintainerovi nic nebrani aplikovat pouze nekonfliktni changesety (ostatne presne takhle to funguje v realnem svete - vyvojar ma obvykle u sebe dalsi vetev nebo repository "pro upstream", "for-Linus", apod., ktera obsahuje aktualni stav upstreamu + lokalni zmeny urcene pro upstream). Konflikty resi vyvojar, ne upstream maintainer.

Hlavne git (nebo jakykoli distribuovany VCS) prinasi jednu podstatnou vyhodu - muzete snadno commitovat samostatne zmeny i uprostred rozdelane prace (zmeny typu: upravuji neco velkeho, ale pak si vsimnu jednoradkove logicke chyby - tuto muzu opravit jako samostatny commit/changeset, aby byla jako takova samostatne popsana a samostatne aplikovatelna do jinych vetvi). Cili commit (changeset) je logicky ohraniceny celek, ne "vse co jsem udelal za dnesek", jako v CVS.

-Yenya

Nechápu, jak se v tomhle liší GIT třeba od SVN. (P.S. nevím, co všichni máte s CVS, to už je dávno mrtvé...)

V SVN má taky každý svůj samostatný repozitář, kde si může řádit, jak se mu zlíbí a do upstreamu protlačit až patche, které považuje za finální? To mi asi něco uniklo.

Nemá.

(Existuje ale taková polodistribuovaná nadstavba SVK, která to umí)

Ano muzete mit vlastni branch a radit jak chcete. Nebo mi neco uniklo? Pouze protlacit patch do finalni verze musite sam, vcetne reseni konfliktu, misto maintaneru, ktery to u gitu udela za vas. Ale i v SVN neni problem, aby vasi privatni vetev spojil nekdo jiny.

Udělat vlastní branch je jedna věc a mít X vlastních nepublikovaných branchů u sebe a řádit i v mainu je trochu něco jiného.

Možná se budete divit, ale pro své soukromé účely jsem se vrátil k CVS. Vyhovuje mi ze všeho nejvíc. Pokud si spravuji své kódy sám, mám prostě v jednom adresáři repository, nad kterým můžu, ale _nemusím_ mít CVS server. Nemusím rozcházet pro mě zbytečný server, data čtu v případě mě pouhým nasměrováním na adresář. SVN je těžkopádnější, a není k dispozici pro takovou řadu platforem, jako CVS. CVS repository je lidsky čitelné a spravovatelné, když by bylo nejhůř, u SVN ne. Navíc výhody SVN (které mi stejně přijde jen jako CVS 2.0) oproti CVS nejsou natolik podstatné, aby stály pro mě za řeč.

Díky tomu není problém mít u sebe několik CVS repository (třeba i na flashce), a mít jedno hlavní a pak třeba lokální na projekt, čímž se přesně dostávám k distribuovanému způsobu práce s CVS - něco jako tu bylo chváleno u GITu. Lokální změny každou chvíli commituji do dočasného CVS repository (v podstatě lepší záloha a možnost libovolného vracení se zpět včetně všech detailů co jsem kdy udělal), odladěnou část projektu pak přesunu do hlavního repository, kde mám funkční verze a hlavní milníky. Stejným způsobem může vyvíjet skupina lidí - a pomocí CVS mít velmi dobrý "distribuovaný" vývoj. Klidně mohu mít speciální dočasné repository pro každý projekt. U SVN to hodně dře.

Presne pro tyto ucely pouzivam SVN. Vyvoj mam v trunk, experimenty delam v branches a kdyz se mi neco hodne moc povede, tak to dam do tagu :-D. A server taky nemam... repozitar mam v jednom adresari v home. A domnivam se ze tezko najdete system, kde SVN nepujde rozchodit (Linux, Windows, Solaris, OpenSolaris a *BSD jsou v pohode).

Mám CVS repository jako součást projektu. Tedy projekt je adresář, pod který jsou podadresáře cvs, src, bin, atd.. Když chci pokračovat na projektu jinde, zabalím celý adresář a mám to se vším všude včetně cvs repository a můžu bez jakýchkoli potíží pokračovat jinde na jiném počítači včetně práce s CVS repository.

SVN nefunguje na Windows 9x/ME a nikdy už fungovat nebude.

SVN nefunguje na Windows 9x/ME a nikdy už fungovat nebude. To je skutecne zasadni nedostatek, na S/360 to take nefunguje? :)

Časté a podstatně sofistikovanější řešení je nainstalovat CVS. Tedy ono to není zase tak moc přímočaré. Je nutné mít nejen klienta, ale i server. Nějak řešit práva, bezpečnost apod. Důsledkem je, že CVS nacházíme jen tam kde to úsilí za to stojí.

Pro danou úlohu (jednoduché správa verzí třeba konfiguráku) je pořád možné použít RCS, která přesně tyhle problémy nemá a je skoro všude.

Ale jinak je git fajn, nehádám se.

Především není pravda,že je nutné řešit server, práva apod. CVS zvládá i lokální repozitář bez nutnosti spouštět démona. CVSROOT může být klidně v domovském adresáři. Nevidím důvod vracet se k RCS.

Uz iba ze by CVS pouzivalo RCS. CVS riesi v podstate iba hromadnu pracu na RCS subormi.

Ano, to je pravda. A vzhledem k tomu, že člověk obyčejně pracuje v jednom projektu s více soubory, nevidím důvod používat přímo RCS.

Pro někoho je důvod že vim má pro RCS docela dobrý plugin.

Az bude mit GIT takovou podporu v SW jako ma CVS, budu o tom uvazovat, ale do te doby pojedeme na CVS. Vim o jeho problemech, ale pri prizpusobeniprace jeho vlastnostem, je dobry nastroj, kde ma problem hlavne spravce, vyvojar obvykle ne.
SW myslim hlavne ruzne profi baliky pro navrhy, ktere maji podporu pro par proprietarnich protokolu a pak jeste CVS, nutit vyvojare, aby mel vedle dalsi nastroj aby mohl spravovat verze, je utopie.

uplny suhlas.

Bohuzel taky musim souhlasit. Dalsim duvodem je kompletni zmena prace tymu. Takze se zase musite prizpusobit novym podminkam:). Prace s GIT nebo Mercurial je mnohem slozitejsi, nez s CVS/SVN, ale taky mate mnohem vyssi moznosti! Slucovani dvou vetvi projektu je v Mercurial nebo Git velmi jednoduche i v pripade konfliktu, kdy je videt stav zdrojaku obou vetvi plus jak to vypadalo pri rozdeleni vetvi(base)!
Jak delat merge v CVS jsem se marne pokousel docela dlouho. Muze to byt tim, ze Nikdo u nas neudelal upgrade na novou verzi CVS uz nekolik let, ale aspon to funguje a mame historii nekolik let ... a nejak s tim zijeme a asi budeme zit i dal. Nekdy je slozite presvedcit nektere kolegy, aby investovali cas do uceni se Gitu nebo Mercurial, pro ne je jednodussi porad dokola delat bugfixy do 2 vetvi a HEAD ...

:-) Ten zaver ma trochu pobavil. Merge v CVS do viacerych branchov ide urobit bez problemov rovnako ako asi vo vacsine podobnych systemov. Kolegovia pouzivali TortoiseCVS klienta a mergovali krizom krazom do 4-5 verzii sucasne.

Jo, ale clovek pak blbe otaguje CVSko a pak resi dva dny proc mu sakra nejde mergovat ...

U CVS staci blbe otagovat nebo zapomenout otagovat a z jednoducheho mergovani je pak hnedle nocni mura a prace na pul dne.

GIT je k nezaplacení pro malé projektíky typu školní úlohy nebo osobní skripty. Nepotřebuje žádný server ani složité nastavování, jede prostě v aktuálním adresáři. To je sice mizivé využití jeho možností, ale u mě nejčastější.

To přeci můžete udělat s SVN taky. Sice si drží repozitář v jiném adresáři než aktuálním (nevím jestli to jde ještě nějak jinak), ale jde o pouhý adresář se soubory na disku. Žádný server také nepotřebujete.
Doporučuji zkusit ;)

Díky za radu. Prostuduji, vyzkouším.

Zrovna jsem v práci a tady se k tomu nedostanu. Nepamatuji si už jak jsem vytvářel repository (zřejmě standardním způsobem s využitím utility svnadmin). Přístup k repository je pak řešen pouze uvedením protokolu file:///

Tadyhle je tuším příklad
http://www.abbeyworkshop.com/howto/misc/svn01/
Jen se tam hovoří o tom, že není povoleno vytvářet repository na síťovém disku, což myslím není už úplně pravda, ale nikdy jsem nic takového nezkoušel.

Pro běžnou práci je pak dobré využít pluginy pro různá IDE nebo něco jako TortoiseSVN pokud IDE podporu nemá (nebo žádné nepoužíváte)

TortoiseSVN je super, ale jen pro Windows. Jinak používám SmartSVN, to je taky bezva a už jsem si na něj tak zvykl, že ho používám i v těch Widlích. (k dokonalisti mu chybí snad jen to, aby bylo open source).

Tak ten neznám. Osobně nepoužívám ani ten Tortoise, jen se používal u nás v práci. Nemám ani ty Widle ;). Pracoval jsem buď z příkazové řádky a nebo pak pluginy v NetBeans nebo Eclipse, což byla potom pohoda.

Na sitovem disku ho nelze pres file:// pouzit pro vice vyvojaru. Pokud je to soukromny repozitar do ktereho pristupuje vzdy jenom jeden clovek najednou, tak nevidim duvod proc by se to nemelo chovat uplne stejne jako soubor na lokalnim disku.

Nechápete podstatu. GIT byl vytvořen pro řešení velice specifických potřeb vývoje kernelu, které CVS a podobné uspokojit nedokázalo. Pokud budete mít podobné potřeby na vysoce distribuovanou správu verzí mezi velkým množstvím vývojářů a stovkami větví, pak budete moc rád GIT používat, ať už má podporu v SW nebo ne, protože bez GITu si hodíte mašli i s podporou v SW (nebo zaplatíte balík za komerční revizní systém s podobnými schopnostmi). Samozřejmě se dá GIT použít i v jiných scénářích, ale nikdo vás nenutí ho používat pokud vám jiný systém poslouží lépe.

Doporučuji přechod alespoň na SVN, se kterým má GIT dobrou spolupráci (příkaz git-svn). Pak se může každý vývojář rozhodnout, jestli bude dělat nativně na SVN, nebo bude komunikovat zprostředkovaně přes GIT a využívat tak jeho featury (lokální branche, rebase, stash...). Zbavíte se alespoň spousty neduhů v CVS.

Skoda jen, ze podpora svn a cvs neni uplna, spousta veci chybi a nelze je pres git-svn (cvs) udelat.

Myslim ze o zakladni tezi clanku (ze je treba pouzivat changeset-based VCS) neni sporu. Ted je otazka jaky VCS pouzit. Ja jsem nedavno zkusil Mercurial: zda se ze to funguje a je to dobre dokumentovane. Muze nekdo znaly obou systemu popsat, proc bych mel chtit pouzivat Git a ne Mercurial? Git znam v podstate jen teoreticky (prakticky jsem si vyzkousel akorat reseni par chyb pres git bisect).

-Yenya

Nepoznám GIT. Mercurial sme skušali u nás nasadiť, ale mal nejaké pre nás dosť podstatné nedostatky (nesledujem jeho vývoj, ale myslím, že niektoré tak ľahko neodstránia):
- nemožno sa prihlasovať na SVN-WEBDAV pomocou klúčov. (nezvládal to klient, internetový prehliadač áno)
- na https SVN-WEBDAV sa nedá pristupovať cez http proxy. (nevie použiť CONNECT)
+ nejaké drobnosti, ktoré sa dali viac, či menej úspešne obísť.

Na co se Git nebo Hg potrebuje pripojovat na _SVN_-webdav? Ja si prave myslim ze krasa Gitu i Hg (i TLA/Arch) je v tom, ze repository je proste adresar, ktery zpristupnite _jakymkoli_ protokolem.

-Yenya

Historicky mel Mercurial (tez zvany Hg) mozna lepsi dokumentaci a intuitivnejsi ovladani, v tomhle za posledni pulrok az rok ale udelal Git hodne velky pokrok. Ja jsem zase prilis nepouzival Mercurial, takze rozdily znam jen teoreticky - Mercurial je portabilnejsi na non-POSIX systemy (Windows), v tom ale Git take ucinil vyrazny pokrok; Mercurial je pravdepodobne rychlejsi v cold cache situaci, Git je rychlejsi pri hot cache. Mercurial je psany v Pythonu, Git je psany v C (a trose shellu a Perlu). Bez nejakych tvrdych dat mam dojem, ze Git je pouzivan vice (krom kernelu projekty jako X.org, Ruby on Rails, Wine...). A Git ma hezci homepage! ;-))

Tezko se srovnavaji, protoze Git a Mercurial vznikly prakticky v tom samem okamziku (IIRC temer na den!) a od te doby jsou z nich do urcite miry rivalove, takze jejich moznosti jsou dosti vyrovnane; kazdy ze systemu ma trochu jinou filosofii a kazdemu asi bude vyhovovat jina.

Jinak je jeste zahodno zminit Bazaar, se kterym Git a Hg tvori takovou "velkou trojku" v soucasnosti siroce pouzivanych DVCS.

V Mercurialu momentálně běží vývoj OpenSolaris, Javy (přinejmenším OpenJDK) a Netbeans. :-) Ale kdo ví, jestli to není aspoň zčásti natruc Gitu. ;-)

O OpenSolarisu vim, co se tyce OpenJDK a Netbeans, je to pro mne novinka - diky! Vypada to, ze se Mercurial celkem v Sunu chytlo. ;-)

Mně se stejně víc líbí Git, ale taky bych se s ním už asi konečně měl naučit zacházet. :-) BTW, Pragmatic Programmers chystají knihu Pragmatic Version Controlwith Git, ale to asi víš. :-) (http://www.pragprog.com/titles/tsgit)

Třetí do party (a můj favorit) je Bazaar (bzr).

Je v pythonu a důraz klade na intuitivnost - ovládání je dost kompatibilní se SVN, dokumentace je bezva. Používají ho v Canonicalu - Ubuntu (launchpad.net).

Pokud vím, tak všechny tři systému jsou plus mínus ekvivalentní, záleží na chuti. Git by měl být oproti Bazaaru asi rychlejší.

Ja trosku mercurial pouzival (drive nez git) ale ne dostatecne abych vynasel nejake soudy. Treba e2fsprogs preslo z hg na git. Par veci na toto tema lze nejit v Tytsovo blogu:

http://tytso.livejournal.com/29467.html

(pokud se pamatuji tak tech clanku tam mel vice).

Na mne to v soucasnosti dela dojem ze git prevazuje. Pohled do devel mailing listu gitu ukazujem, ze vyvoj je hodne zivy. Dokumentace je slusna (kazdy prikaz ma man stranku, je tutorial apod.).

Takovy zakladni prehled co GIT umi v podobe prezentace (mozna je to prehlednejsi nez tedle serialek):

http://kzak.fedorapeople.org/git-presentation.pdf

Krom toho, ze se mi zda, ze mercurial je optimalizovany pro prenos po siti (mel by mit mensi objem prenesenych dat), lisi se ve valne vetsine ve funkcnosti.

Obcas se mi prihodi, ze musim pracovat s v4l stromem a je to neco jako presednout z bmw do favorita. Mozna s tim jenom neumim, ale chybi mi veci typu amend (prihozeni k poslednimu komitu), stash (zahodit zmeny do kontajneru bokem, udelat cokoliv, naaplikovat zpet), diff HEAD (po addu, ktery prihodi zmeny do indexu a dal se difuje oproti tomu).
* neumi to s arch, svn, cvs repositari, ikdyz git podpora taky neni prilis valna (hlavne svn properties a podobne speciality), ale pro zakladni zachazeni to staci. hg export neni nic moc vzhledem ke git format-patch.
* hg mozna dela cisteni nejak implicitne, v gitu je to v nocyh verzich volano z pull, ale je mozne volat git gc (vycisteni, mnohonasobne zrychleni -- dojde k reindexaci) a prune (nedosazitelnost) explicitne.
* describe (ukaz verzi, nad kterou tento komit je) a blame (na ktery radek kdo kdy sahl) se hodi casto, pokud clovek vyviji neco out-of-kernel a potrebuje zjistit, co kdy pribylo a jak se to zmenilo.
* nejsem si jisty, jestli hg umi rebase (stahnu si master a vsechny moje veci nahodim nad to + mi to samo mergne, popr. vyhodi konflikt, ktery se da jednoduse rucne opravit), show (ukaz ten a ten komit), hard/soft reset, send-mail;

Navic se na git da napasovat cogito, ktere dela barevne diffy a podobny lepsi vystup pro oci. Je toho spousta, clovek se to uci roky ;).

cogito je už překonané aktuálními verzemi gitu samotného a nadále neudržované. Barevné diffy git umí: git diff --color

To me tesi, co jsem ale prave zkusil, tak nejak zapominaji spoustet less s -r, bo mi to vyplivne escape sekvence misto barev (mozna to ale bude nejaky lokalni problem).

Nemám s GITem zatím zkušenosti,
ale Linus ho velmi propaguje, viz
http://www.youtube.com/watch?v=4XpnKHJAok8

Dopuručili byste GIT člověku nepracujícímu dopusud se software na správu verzí?
Nebo raději Subversion?

Mercurial, protoze k nemu existuje rozumny manual (a na rozdil od SVN je distribuovany). Ale, jak pisu vyse, git moc neznam - treba k nemu taky existuje rozumny manual (nebo bude existovat rozumny serial clanku na rootu :-).

-Yenya

http://svnbook.red-bean.com/

Jestli mate hodinu casu, muzu doporucit:
http://youtube.com/watch?v=8dhZ9BXQgc4
Randal Schwartz, git

Jestli na tom budete delat sam, tak doporucuju SVN, jestli ve vice lidech, tak je asi dobre se poradit co od toho ocekavate.

zkuste se podivat je jeste po bazaar vcs http://bazaar-vcs.org/ mam s nim vcelku dobre zkusenosti.

Aby sme sa vyhli nedorozumeniam, tak git povazujem za naozaj vyborny VCS. Zopar projektikov v nom mam, a hoci nevyuzivam ani 1/10 jeho moznosti je to super.

Na druhej strane vidim problem skor v tom, ze 80% developerov ma problem pochopit ako PORIADNE pouzivat obycajny centralizovany VCS (ci uz CVS, alebo SVN) a dat im do ruky Git alebo Mercurial...To si clovek koleduje o problemy. Slovom PORIADNE myslim to, ze budu vediet spravne mergovat, budu sa drzat dohodnutych pravidiel branchovania a podobne.

Vsetko zalezi s kym pracujete, ak mate v time ludi ktori vyrastli na Visualku a nebodaj VSS (pre neznalych - VSS = Visual Source Safe) tak mate problem. Ak mate v time aspon par ludi, ktori co-to vedia o open-source, linuxoch a najma maju chut sa ucit nove veci, tak hor sa do toho.

Mal som pocit ze som presne na tuto temu cital akysi blog nedavno, no nasiel som uz iba toto:
http://labs.trolltech.com/blogs/2008/03/30/sourcecode-

Na druhej strane vidim problem skor v tom, ze 80% developerov ma problem pochopit ako PORIADNE pouzivat obycajny centralizovany VCS (ci uz CVS, alebo SVN) a dat im do ruky Git alebo Mercurial...To si clovek koleduje o problemy. Slovom PORIADNE myslim to, ze budu vediet spravne mergovat, budu sa drzat dohodnutych pravidiel branchovania a podobne.

Dohodnutá pravidla branchování jsou nutná právě proto, že používáte centralizovaný systém. V distribuovaném systému si každý může dělat své vlastní branche, jak ho napadne, a jen některé z nich (sestavené ze samých krásných čistých commitů) publikuje veřejně.

Já jsem se naučil pracovat s Gitem dříve než s CVS. Připadá mi, že v Gitu všechno dává rozumný smysl. Oproti tomu CVS mi přijde jako něco tak příšerně složitého, že nechápu, jak se to dá rozumně používat (totéž s SVN). Linus to říká správně, že CVS vám ohýbá myšlení.

Dohodnutá pravidla branchování jsou nutná právě proto, že používáte centralizovaný systém. V distribuovaném systému si každý může dělat své vlastní branche, jak ho napadne, a jen některé z nich (sestavené ze samých krásných čistých commitů) publikuje veřejně.

V tomto samozrejme suhlasim, ale ja som sa o mergovani zmienoval preto ze to je standardny problem centralizovanych systemov. V Gite su zas ine "problemy" (uvodzovky preto, ze to nie je skutocny problem, ale javi sa to tak). Vacsina ludi sa najskor stretne s centralizovanym systemom (nehovorim ze to je lepsie, ale taka je skutocnost) a teda im bude ideovo blizsi. V Gite nie je problem s mergovanim, ale zas pochopenie bezne pouzivanej funkcionality (praca s indexom, diffovanie oproti lokalnym zmenam a zmenam v branchi a podobne) su komplikovanejsie (rozumej vacsina ludi to tak rychlo nepochopi).

Já bych viděl problém jinde. Zatímco při použití např. kombinace CVS+Cervisia člověk v podstatě při každodenní práci nemusí na příkazovou řádku sáhnout, možnosti GUI nástrojů pro GIT (gitk a qgit) jsou zatím dost omezené - v zásadě se omezují na prohlížení grafu commitů a pár jednoduchých operací (make a new branch here). Věci jako interaktivní rebase nebo rebase+pull (aby graf byl "hezčí") je třeba řešit na řádce. Pokud se povede udělat univerzálnější GUI pro GIT (s podporou těchto a podobných operací a se snadným sledováním historie změn v souboru - námitku, že GIT není souborově orientovaný, neberu), byl by tento systém pro obyčejného vývojáře daleko přijatelnější a srozumitelnější. Problém s podporou v IDE typu Eclipse je samozřejmě také významný, ale rozumné samostatné GUI vidím jako důležitější.

opraveny link:
http://labs.trolltech.com/blogs/2008/03/30/sourcecode-collaboration/

Na druhej strane vidim problem skor v tom, ze 80% developerov ma problem pochopit ako PORIADNE pouzivat obycajny centralizovany VCS (ci uz CVS, alebo SVN) a dat im do ruky Git alebo Mercurial...To si clovek koleduje o problemy.

Developer co neni schopen jednou za par let se podivat co se okolo deje a co existuje za nastroje a pripadne se nektery naucit pouzivat je mrtvy developer...

Moje zkusenost s lidmi je, ze tem co nepotrebuji nejake slozite operace, ale proste jen chteji udelat patch a poslat ho se snadneji pracuje s GITem nez CVS. Tech zakladnich prikazu je par a IMHO je to daleko primocarejsi. Pochopitelne pokud chcete delat branche, mergovat, mazat stare veci apod. tak je vhodne si neco prostudovat.

V soucasne dobe jit a ucit se SVN (protoze opravuje par nedostatku CVS) je hloupost. Me pripada lepsi udelat poradny krok dopredu nez jen krucek do boku..

ja mam podobne zkusenosti. Presli jsme s CVS na SVN ale ukazalo se ze kdybychom presli hned na neco poradneho (hg, bazaar) usetrili bychom cas. Hg i bazaar jsou vyborne produkty a bezi bezproblemu i na widlich.

Taky se mi zda bazaar jednodusi na kazdodeni pouzivani oproti CVS, kdo umi s CVS nebude mit s hg ani s bazaar zadne problemy. Navic bazaar nevyzaduje zadny specialni server oproti cvs a svn, sftp mu staci.

Ono je to spis o tom ze se lidi nechteji ucit nic noveho a proto porad pouzivaji CVS. Dneska bych uz rozhodne CVS/SVN nikomu nedoporucoval. Jsou uz i lepsi nastroje a musim rict ze sprava vetvi/merge v CVS je opravdu hardcore.

Aaa, tak som konecne nasiel ten link co som hladal v mojom povodnom prispevku:

http://blog.red-bean.com/sussman/?p=79

Su tam zhrnute dovody preco distribuovane VCS nie su (a tak skoro ani nebudu) vyuzivane bezne

V podstate s tym co tam je napisane 100% suhlasim, ak aj mate iny nazor doporucujem precitat aspon prvych par odstavcov, v ktorych sa venuje celkovo roznym typom vyvojarov.

No, praveze developer nechce stravit ucenim se noveho VCS vic nez je nutne a kdyz to zabere vic nez 10 min, tak to odmitne. Me dalo hodne prace prosadit ve firme alespon SVN a to pritom staci skutecne pochytit jen 2 operace.

Na druhou stranu, prijde mi vtipne, jak se tvrdi (ted mluvim o SVN), ze pokrivuje mysleni, a pak reknete, ze se s GITem snadneji udela patch a posle se. Pritom vam nedochazi, ze neco takhle komplikovaneho vubec neni potreba delat a drtiva vetsina projektu a vyvojaru tohle nepotrebuje.

Nikomu GIT nevymlouvam, at si kazdy pouziva co chce, ale obecne tvrdit, ze centralizovane systemy jsou slozitejsi na pouziti je dost prehnane. Stejne tak rikat neni jedno krok kupredu a druhe do boku, jsou to proste ruzne zpusoby jak resit VCS.

sorry ale odkdy coder rozhoduje o tom co bude a nebude pouzivat. Budto bude delat to co od nej project manager ocekava a bude za to placen nebo pujde na dlazbu. Rika se tomu trh pracovnich sil.

No, na vyssi odborne managerske se to mozna tak povida, ale realita byva ne uplne ucebnicova.
Dalsi vec je, ze ja byl v te dobe radovy vyvojar, ovsem jediny, ktery znal neco jineho nez ftp.

Jo jo, v některých firmách se dosud nepoužívá žádný VCS, natož aby někdo používal něco sofistikovanějšího než CVS. Navíc tam "projektového manažera" dělá člověk, který je ve firmě nejdéle, je nejstarší nebo má nejlepší vztahy se šéfem, ale chybí mu potřebný rozhled a teoretické základy, takže ty projekty se dělají de facto na koleně. Taková je skutečně realita některých menších firem.

Jakou pilu budu mit si rozhoduju sam, vedouci projektu se zajima o narezane metry a ne o to co pouzivam a tak by to melo byt

O nastrojich by mel rozhodovat tym a pokud nadrizeny urcuje technologie a chce byt nutne in, protoze nekdo jiny to pouziva, by taky mohl narazit na odpoved, budeme mit 3 tydny spozdeni, potrebovali jsme vic casu na zvyknuti si na novou technologii.

Ma git a mercurial implementovane rozhrani CVS? Pokud by to existovalo, tak se da uvazovat o nasazeni gitu na "server" a vyvojari budou porad pouzivat cvs klienty a jeho limitovanou funkcionalitu a na git by kazdy presel az by se na to citil.

Opravdu je to VELKA zmena. Zazivam to kazdy den, kdy musim preskakovat z Hg na CVS a obracene, protoze jeden projekt jsem si mohl rozhodnout, ze to bude verzovane v Hg ...

Alespon u nas si o tom coder ani team (pokud definujte team jako bandu coderu) nerozhoduje. Ve fabrice si taky delnik nerozhoduje o tom jaky soustruh bude pouzivat. Nema na to ani znalosti, ani postaveni.

Normalni koder je nesamostatny jedinec nad kterym se musi neustale mavat klackem aby neprasil, psal unit testy, dokumentaci, psal poradny commit message, nesledoval youtube v pracovni dobe, nekradl DVDcka atd. Coder neni schopen samostatne prace. Kdyz se vypracuje tak ze samostatne prace schopen je, tak prestane delat codera a zacne delat odpovednejsi praci.

Ehm. Zdá se, že máte zkušenosti jenom z jednoho typu firem (ala třeba Unicorn). Jsou i jiné, říkejte jim třeba garážovky pokud je chcete urazit, kde je menší skupina a funguje to trochu jinak (i hlava týmu píše kód, často ten důležitý). Ten model není moc škálovatelný a hůř se to prodává třeba bankám na bodyshop, ale buďte si jist že produkovaný kód je kvalitnější.

Tady se sám musím opravit - ten kód je často kvalitnější, protože to programují lidi co to většinou umí a baví. Vždy kvalitnější není, vzpomněl jsem si právě na jeden odstrašující případ.

kvalita kodu zavisi na tech kdo projekt vedou a delaji code review. Kdyz to coder zprasi, musi se mu to vratit a nekomitnout to. Taky se musi dbat na dodrzovani codestyle.

Jak jste spravne poznamenal flakat to muzou v libovolne velkych firmach.

No jestli se takhle divate na programatory, tak si nic jineho nezaslouzite. Delam ve velke americke firme jako programator, a muj sef me povazuje za lidskou bytost a ne psa. To znamena je pristupny mym technickym nazorum. A to jsem temer naprosty zacatecnik (delam 2 roky mainframe assembler), a predtim jsem nikde neprogramoval (profesionalne). Za to jsem mu vdecny tim, ze se opravdu snazim veci zlepsovat a delat poradne.

Nevim, co si predstavujete pod "zodpovednejsi praci". V kodovani, co delam, je zodpovednosti celkem dost.

coder je nejmene kvalifikovana prace. Sehnat codera je ten nejmensi problem, zajemcu jsou mraky a delaji to obvykle lidi co jsou budto bez zkusenosti nebo jsou lini. Na kvalite codera moc nezalezi, od toho je tu jeho sef, ktery musi byt dost znaly a ohlidat co ten clovek dela a zda neprasi. Proste koder je pesak a komodita.

Vyse nez koder stoji kdokoliv, clovek delajici dokumentaci, tester, prodejce, ten kdo zajistuje komunikaci se zakaznikem, software architekt, support. Jako koder mate prakticky nulovy vliv na to jak bude projekt vypadat a je to tak dobre. Kodera moc dlouho delat nevydrzite, maximalne tak par let pak s tim budto svihnete nebo postoupite na vyssi posty.

Povinosti sefa je naslouchat namitkam k projektu od svych podrizenych, pokud budou opravnene, tak neni duvod aby tito kvalitni lide delali dale kodera a prejdou na vyssi, odpovednejsi a lepe placene pozice. Inzeryra taky nenechate kopat krumpacem.

Taky zalezi na tom co vlastne koduje. Pokud je to LAMP koder tak tech je dneska na trhu tolik ze je muzete doslova kupovat po tunach z Ruska, Ciny, Indie, Singapuru, Jizni ameriky a Afriky. Vetsina lidi je totiz lina se ucit cokoliv jineho nez LAMP a pokud umite jen LAMP tak vas bereme jako programatorsky odpad, ktereho muzeme mit za par stovek mesicne od nasich dodavatelu LAMP coderu kolik jen budeme chtit. Pokud ovsem umite J2EE a Oracle, tak to uz je jina, jeste sice porad coder, ale uz vam rikame PANE a plat podle toho taky vypada.

V současné době, pokud vím, je více nabídek práce než zájemců. S indickými developery přeju hodně štěstí. :-)

V cechach ano. Ale cechy prakticky nezamestnavame - obecne totiz maji velice mizerny pomer vykon/cena, flakaji se jak jen je mozno a nemaji zadny zajem o danou praci. Jsou ochotni povetsinou jen dochazet do zamestnani za coz pozaduji plat a uplanuji ruzna prava (napriklad pravo zdarma si soukrome telefonovat).

Nekteri indicti developeri jsou nicmoc, ale nekteri jsou svetova spicka. Mezi indama jsou velky rozdily, chce si je to prebrat.

Teď jsi mě rozesmál. Když srovnám "Normalni koder je nesamostatny jedinec nad kterym se musi neustale mavat klackem aby neprasil, psal unit testy, dokumentaci, psal poradny commit message, nesledoval youtube v pracovni dobe, nekradl DVDcka atd." s "Ale cechy prakticky nezamestnavame - obecne totiz maji velice mizerny pomer vykon/cena, flakaji se jak jen je mozno a nemaji zadny zajem o danou praci.", vychází mi, že Čech je přesný prototyp Tvého kodéra (koneckonců, ty budeš asi Belgičan, viď).

Je jenom s podivem, že o české IT zaměstnance je takový zájem. Příteli, svůj mindrák by sis měl léčit jinak.

Typicky unicornista po absolutoritu skoleni "Ego III" :)

To si myslite ze se na celem svete flakaji a kradou jenom Cesi? Kazdy narod podvadi v praci jinak, kuprikladu Rusove radi kradou zdrojaky a data, ktere pak prodavaji, indove se neobtezuji vubec chodit do praci (kdyz nepotrebuji penize) a cesi ty typicky velmi dbale dochazi do prace, ale zase nedelaji nebo si tam delaji soukrome ksefty.

Cesi podvadi vic nez amici, ale hlavne nejsou moc ochotni delat. Podivejte se treba na efektivitu prace zahranicnich a ceskych firem. Ten komunismus v cechach znacne zdegradoval mysleni lidi. Amik treba chape ze kdyz bude dobre pracovat a bude mit vysledky tak ze mu vedeni velmi rado zvedne plat a povysi ho na odpovednejsi misto protoze si radi podrzi schopne lidi. Cech tohleto nechape a tak pracuje nejhur jak je jen mozne aby ho nevyhodili a mel klid. Je fakt ze problem vetsiny ceskych firem je nekvalitni management, spatny management pohrbi jakykoliv projekt.

Já myslím, že hlavní problém je v tom managementu a know-how. Češi nemají tak nízkou produktivitu proto, že (například) udělají míň úderů kladivem než západní pracovníci, ale proto, že ve firmách často pravá ruka neví, co dělá levá. Vím o takových případech z IT i z fabrik. Co se týče toho povyšování a ocenění tvrdé práce, není to často tak jednoduché a nemusíme chodit pro příklady do našich končin - Dilbert určitě není až tak vytržený z americké reality. A právě na blogu Dilberta se někteří Američané ke své "pracovní kázni" vyjádřili myslím dost jednoznačně.

Naprosto souhlasim. Podle me je nizka produktivita Cechu (jako zamestnancu) mytus, ziveny zejmena ekonomy a jejich spatnou definici produktivity (jejich definice zavisi na vysi mzdy, tedy nema co delat s realnou produktivitou jak by ji clovek intuitivne chapal).

Tento nazor mohu podlozit vlastni zkusenosti.

Studoval jsem v zahranici (ne cele studium - SocratesErasmus) a ted uz dva roky ziji v zahranici. V CR jsem pracoval dva roky po studiu a behem studia jsem vystridal nekolik kratkodobych zamestnani. Timto se nechci chlubit, ale jen rict, ze mam s cim srovnavat!

JSME konkurenceschopni a porovnatelni se zahranicim, MOC se podcenujeme a NEVERIME si. Vidim to tady u vice krajanu. NEUMIME jednat o svych platech tak efektivne. To je asi i problem proc jsou v CR platy tak nizke. Vicemene je v CR trend zvysovat plat, az kdyz zamestnanec chce odejit a ne kdyz je produktivni a treba vic jak rok maka jak sroubek.

TO POWER LENIN: Jste ubohy. Jak dlouho vam vydrzi podrizeny, nez ma chut vzit vas lati po hlave? CCA 10 minut NEZ PRESTANE VAS PODRIZENY V PRACI PRACOVAT A ZACNE SE PODLE VAS FLAKAT, PODLE ME PROSTE DELA JEN SVOU PRACI A NA ZBYTEK KASLE, PROTOZE PAN REDITEL ZEMEKOULE MU STEJNE VSECHNO ZADUPE DO ZEME, TAKZE NEMA CENU SE SNAZIT.
Jestli vam vubec nekdo takovou praci sveril(vest lidi).

To jste napsal velmi hezky cesi jsou zbabeli a boji se riskovat. Chteji mit sve 'jistoty' ktere dostanou at delaji ci ne. V zadnem pripade se nechteji ucit nove veci a jejich prvni reakci je - to jsem jeste nedelal do toho nejdu.

Kdyz mi zamestnanec pri pohovoru oznami ze neni ochoten se ucit zadne nove veci, tak ho ani nevezmu. To same kdyz je ochoten ucit se nove veci jen proto aby nebyl vyhozen. Ja chci chytry a aktivni lidi. Pokud jste schopny tak vas velmi radi dobre zaplatime, protoze mate pro nas velkou cenu a neradi bychom vas ztratili.

Je to zname pravidlo 80:20, 80% lidi nechci, radsi si vezmu tech 20% a poradne jim zaplatim. K cemu zamestnavat blbce? Ty naopak posleme ke konkurenci a to klidne vcetne doporucovaciho dopisu.

O schopnosti jednani Cechu o platu to moc neni, v prvni rade totiz musite mit lidi z CEHO platit. Proto jsou v cechach platy tak nizke. Nizka produktivita, trh maly, zakaznici chudi.

Cesi jsou hovada, typicke ceske hovado se vubec nezajima pri prijimacim pohovoru o to CO se bude delat a ZDA TO UMI ale KOLIK za to bude kdyz mne vezmou. Pocita s tim ze bude prijat kdyz udela dobry dojem a tak se snazi a mlzi jak jen je to mozne a div se neplazi predemnou pozemi. Taky pocita s tim ze kdyz nejak uhraje ten pohovor a bude prijat tak ze si to misto uz udrzi, protoze ty svoje mizerny vysledky uz prece nejak okeca, ne? Kdyz ho prijmeme tak mu pak naroste hrebinek, je uz pan king a sam si chce urcovat co a jak bude delat.

Pokud makate jak sroub a vasi nadrizeni to neoceni tak proc uz davno misto breceni nejdete proste delat jinam? Brecet umi kazdej zbabelec. Jdete za sefem a reknete mu to narovinu a kdyz rekne ze vas proste z jakychkoliv duvodu platit vic nemuze, tak hned podejte vypoved. Rika se tomu trh prace. Pokud jste schopny tak vas kazdy *rad* zamestna. 80% lidi ma strasny vitr ze zmeny zamestnani. Proc? Protoze jsou neschopni, vi to a o neschopne lidi se nikdo nerve.

Kdyz jste neschopnej tak holt musite drzet hubu a krok a hojit se tim ze budete v pracovni dobe cumet na porno a myslet si jak se svym bossem vyjebavate a trast se strachy ze vam na to prijde a vykopne vas. Psovi psi zivot.

Zda se mi, ze si trochu protirecite:

Proc by ho melo zajimat, co bude delat, kdyz stejne ocekavate, ze se nauci, co po nem budete chtit? Me je napriklad (vesmes) uplne jedno jakou praci delam (co se programovani tyka), prave proto, ze jsem ochotny se naucit cokoliv.

Proc od nej ocekavate, ze bude dobry, kdyz nebude mit zadne slovo rozhodovat, co a jak chce udelat? Ja bych takovou praci nechtel delat ani za dvojnasobek toho, co mam ted.

Kdyz ma clovek o praci zajem tak se pochopitelne zajima co vsechno ta firma kam nastupuje dela a na jakych projektech pracuje, ne? Clovek ktery tvrdi ze je mu to uplne jedno na cem dela, jen kdyz dostane zaplaceno, tak ten na mne moc velky dojem jako dlouhodobe perspektivni pracovnik nedela. Jak si vybirate mezi nabidkama pracovnich mist? Proctete si je a jdete tam kde delaji neco co se vam libi a co umite ne?

Kazdy mame treba sva oblibena jidla, taky nam neni jedno co jime. To neni chyba ze mame radsi neco oproti necemu, takova je proste nase povaha. Povetsinou si nastupujici lidi muzou vybrat na jakem projektu chteji zacit delat, pokud zadny projekt netrpi nedostatkem pracovnich sil. Ocekavame sice ze se nasi perspektivni pracovnici nauci to co je pro praci potrebne, ale to jeste neznamena ze technologii X bude mit stejne rad jako technologii Y. Kdyz je tu moznost, tak je mozne lidi preskupovat mezi projekty nebo i mezi pozicemi tak jak jim to vyhovuje.

Treba nekdo rad pracuje pro armadu, protoze pro armadu taky dela taky nekdo z jeho rodiny, tak proc ho nepriradit k projektu ktery delame pro namorniky? Bude se mu to libit, protoze jeho bracha u nich je.

Hierarchie je pro rizeni projektu naprosto nezbytna a ano na nekterych pozicich mate prakticky nulovou moznost rozhodovat o prubehu projektu. Jinak to proste nejde. Na nejvysim rozhodovacim poste je zakaznik, ten nas plati a ten rozhoduje co a pripadne jak se bude delat.

Ja sice chapu ze vybyste rad delal vec zpusobem X, ale zakaznik to chce zpusobem Y, zakaznik nas plati a tak mi mu to udelame zpusobem Y. Tak proste funguje komercni IT spolecnost. Vy byste zustal u IT firmy, ktera vase zakazky nedela tak jak vy chcete ale tak jak si dana firma mysli ze je to pro ni nejlepsi?

Pokud chcete mit rozhodovaci pravomoce tak pokud jste kvalifikovany nastupte na pozici, ktera ty vetsi rozhodovaci pravomoce ma. To si predstavujete ze najimame porad jenom codery? Jasne ze ne. Chcete ridit malou skupinku koderu a trochu rozhodovat o dalsim prubehu praci? Tak se jednoduse hlaste na odpovidajici misto.

Kodera clovek dlouho delat nevydrzi, je to nevdecna a malo placena prace. Takze pokud nastoupite jako koder, tam vam doporucujeme aby jste se zacal ucit napriklad od sefa jak se kvalitne ridi sw projekt aby jste az vas to kodovani prestane bavit mohl na tuto pozici postoupit. Podle mne clovek by mel delat kodera tak maximalne 4 roky a pak jit dal.

Zamestnavatele si vybiram podle firemni kultury. Prekvapive se mi pak i lepe pracuje, dele tam vydrzim a i plat roste :Oo Technologie je vedlejsi, v IT segmentu vsechno rychle zastarava a za 2-3 roky se bude delat v uplne necem jinym.

Zakaznik by podle meho nazoru mel byt partner a ne general, ktery vi vse nejlepe. Jedine tak imo vznikaji nejlepsi komercni projekty. Nastesti si, stejne jako zamestnance, muzeme vybirat i ty zakazniky.

Jestli o tom, jake cvs se pouzije, rozhoduje Project Manager, tak je cosi spatne. Projekt manazer se prece stara o cely projekt. O technickych otazkach by mel rozhodovat nejaky clovek odpovedny za technickou cast (tj. analytik, software architect, hlavni programator, nebo co ja vim jak se tomu rika, zalezi na firme, typu projektu).
Rozumime si?

Zrejme od pocatku delate ve firmach s miliardovymi obraty a nikdy jste neprosel SOHO segmentem.

Odpor vyvojaru pouzivat SCM (ze ktereho je mj. poznat, kdo co udelal/zmenil, jak moc pracuje,...) by vakuum mohlo zavidet.

Sorry ale bez SCM se prakticky neda rozumne pracovat. Co treba udelate, kduz si ponicite soubor v editoru a zasejvujete ho? Zalohy? Ale ta muze byt stara kuprikladu 24h, to vyhodite cely den prace kvuli trivialni chybe? Jak chcete delat code review kdyz si nemuzete vytahnout diffy?

Neni to o obratu, je to o procesu vyvoje a efektivite.

a je zajimave, ze linux byl vyvijeny vic nez deset let bez SCM... a jaky vyrostl....

Mne to nerikejte, byl jsem na te strane, co vedeni presvedcovala o nutnosti zavedeni SCM podlozeno naprostym bordelem v ruznych verzich ruznych modulu u ruznych klientu - neexistovala autoritativni verze oproti ktere by se testovalo.
Vedeni schvalilo, ale zbytek vyvojaru zacal hazet ruzne klacky pod nohy - od ruznych "nefukncnosti", po commitovani kazdeho souboru extra,... - bud v tom byla jejich hloupost (pochybuji) nebo umysl zachovat chaoticky stav (muj tip).
A protoze horely druhe deadliny, protoze prvni se vzdy domlouvaly v ramci ziskani zakazky na nepouzitelne kratke casy, tak se to neresilo. Jiz tam nejsem, firma po dvou letech zkrachovala.

Tohle je ale chyba primeho nadrizeneho coderu ze jim dovoli tohleto commitovat. Ma jim to vratit, domluvit se s nima na group meetingu a v pripade nutnosti pouzit donucovaci prostredky - snizeni/zvyseni platu nebo padak.

Pokud dojde k nazoru ze ti lidi umyslne kurvi projekt tak neni problem je vsechny vykopnout na dlazbu. Ono v praxi staci vyhodit jednoho ci dva a zbytek se smiri s tvrdou realitou kapitalismu.

Musim rict ze mnohem radeji lidi povysuji nez vyhazuji. Vsem rikam ze penize jsou ten nejmensi problem. Zaplatit zamestnance muzeme opravdu kralovsky, financnich zdroju mame mraky, ale nemuzeme platit flakace - to fakt nejde, ty se musi vyhodit protoze kazi zbytku teamu pracovni moralku.

sorry ale odkdy coder rozhoduje o tom co bude a nebude pouzivat

Odjakživa, kód je pro kodéry, ne pro manažery. Jen občas se najde nějaké manažerské čuně či freecoolin který si myslí, že o tom má rozhodovat on.

"revizí" - zase nevhodný překlad z angličtiny. V češtině je běžnější a správnější říkat "systémy pro správu verzí" Slovo verze i lépe vystihuje i význam - nejedná se o žádnou revidovanou záležitost, ale prostě verzi souboru. Na úvod nebude špatné ujasnit si, proč vlastně používat nějaký nástroj na správu změn, a nebo, chcete-li, na správu obsahu (SCM - source code management). Správa obsahu je CMS a je to úplně jiná kategorie softwaru.

Souhlas.. nechtene kreativni byl v tomdle pripade root.cz. Ja tudle kapitolu pojmenoval "GIT: uvod". Ale coz, ... :-)

Nevidím jedinný rozumný důvod, proč by se dvě různá anglická slova měla zobrazovat do jednoho slova českého.. Vycházím z návodu k SVN.. V nadpise je Version Control with Subversion, ale jednotlivým stavům úložiště s časovými razítky se pak říká revision.. Správný překlad by měl tohle rozlišovat, takže dávám za pravdu autorovi článku..

"dvě různá anglická slova měla zobrazovat do jednoho slova českého" To není nic neobvyklého.

"V nadpise je Version Control with Subversion, ale jednotlivým stavům úložiště s časovými razítky se pak říká revision.. Správný překlad by měl tohle rozlišovat, takže dávám za pravdu autorovi článku.." Jenže v nadpise zdejšího článku je slovo "revizí" kdežto v textu např. "Asi téměř každý, kdo se vydal na nejistou cestu úpravy nějakého textu, měl chuť mít v záloze pro případ neúspěchu předešlou verzi."

:-)

Říkat "systémy pro správu verzí", je zcela běžné. Tyto systémy spravují jednotlivé verze souborů, takže není potřeba rozlišovat dva pojmy. Navíc slovo verze do češtiny zapadá lépe než revize, je už více přijaté a nepůsobí jako cizí prvek. Takže jsem pro to, aby se říkalo verzí.

BTW: tohle je stejně takový jazykový koutek a s tématem to moc nesouvisí. Přemýšlel jsem tedy trochu o distribuovaných systémech pro správu verzí a došel jsem k tomu, že je to hezká ale někdy zbytečně složitá hračka. Při komerčním vývoji aplikace většinou bohatě stačí centralizovaný systém (Subversion), protože celý vývoj směřuje k jednomu cíli - vydání jedné funkční verze aplikace (a časem další) - takže je potřeba často odevzdávat do úložiště a držet se pokud možno na aktuální nejvyšší verzi (všichni vývojáři). Prostě aby se to moc nerozjelo a neměli jsme v tom bordel :-) To bychom pak nestíhali termíny.

Zatímco u open sourcu se dá očekávat, že si zdrojáky bude chtít stáhnout i někdo, kdo s vývojovým týmem nemá nic společného (a nemá právo zápisu), a bude si tam chtít taky něco šmudlat. V tom případě se hodí, když má vlastní úložiště u sebe, protože jinak by přišel o výhody verzování. Takže přínos to je (zatímco fakt, že můžu letět v letadle a tam si offline programovat a verzovat, je spíš taková perlička na dortu).

Mate nekdo zkusenosti s darcs a muzete ho treba i portovnat s Mercurial a GIT? Diky :)

Darcs jsem nejakou dobu pouzival pro par mensich projektu, ale pak jsem presel na git, protoze jsem mel problemy s rychlosti nekterych operaci. Darcs mi prisel velmi prijemny a intuitivni, ale kdyz jsem patral po nejakych zmenach a pouzil "annotate" (vypise ktere radky souboru se zmenily v ktere verzi) a darcs se na cca 10 minut odmlcel (bylo to nad cca 7000 souborama o celkove velikosti kolem 15 MB) zacal jsem byt trochu nervozni. Kdyz jsem se pak do podobne situace dostal podruhe a narazil na pomalost darcs i v nekolika dalsich pripadech, premigroval jsem do git (da se na to stahnout skriptik) a od te doby jsem nemel problem, protoze git je opravdu rychlej.

Diky, nasel jsem napr. jeden banchmark ktery potvrzuje tvoje zkusenosti:

http://git.or.cz/gitwiki/GitBenchmarks#head-5657b8361895b5a02c0de39337c410e4d8dcdbce

;)

Co se z open softu blizi k Telelogic Synergy? Videl uz nekdo neco podobneho?

ma GIT nejaky gui?

ide mi hlavne o 'version tree', nieco na sposob clearcase,.. to je asi jedina vec, ktora sa textom neda nahradit

cosi taketo by som snad este z textu precital:
http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_EndUser/books/ClrC_UG/sgi_html/figures/Fig1-11.gif

ale ked tam su tam tisice verzii a stovky zaznamoch o mergoch, tak z textu ziskat nejaky prehlad stoji za prt :-P

jasan, gitk je v pohode - viz http://lwn.net/Articles/140350/

mimo gitk, tez:
git-forest: http://jengelh.hopto.org/images/git-forest.png
qgit: http://sourceforge.net/project/screenshots.php?group_id=139897

Jak moc se lisi uziti distribuovaneho systemu nad pouzitim SCM, kde kazdy ma vlastni repositar a posila zmeny/patche maintainerovi, ktery je zaradi do "autoritativniho" repositare na serveru?

Jak se resi cislovani verzi, kdyz repositare nevi jaka je kde jinde - jak se pozna, ktera verze je nejnovejsi, nejaktualnejsi - at uz pohledem na patch, tak software jako takove.

Konkrétně na příkladu GITu - když má každý svůj repozitář a přijaté změny může okamžitě vidět, když dá git fetch nebo git pull z originu do svého lokálního repozitáře. Nejnovější verze je vždy v HEADu větve main v originu (pokud vývoj probíhá ve více větvích, tak a číslování verzí se dělá explicitně pomocí tagů - GIT nemá implicitní čísla verzí (jenom SHA digesty), ale je možné HEAD v mainu podle rozhodnutí maintainera příslušně otagovat - třeba i po každém git merge, git am apod. Výhoda je v tom, že vývojář může v podstatě libovolně dlouho pracovat nad svým lokálním repozitářem a git fetch + git rebase origin mu pomáhá zajistit inkrementální přizpůsobení jeho patchů aktuálnímu stavu v originu, takže se mu patche nerozjedou oproti upstreamu natolik, aby to vedlo k těžko řešitelným konfliktům, když je se svou prací hotov.

Pokud vývoj probíhá ve více větvích, tak aktuální je vždy HEAD dané větve v hlavním repozitáři - originu.