Řada projektů opouští populární verzovací systém Subversion a přechází na jiný. Jaké jsou důvody?
K používání Subversion (SVN) mě přiměl kdosi v počátcích vývoje Texy. Do té doby jsem „verzoval“ archivováním složky s kódem do RARu před každým větším zásahem. A něco sofistikovanějšího by bodlo. Veřejnému repositáři jsem odolával, protože mi připadalo, jako by mi někdo koukal při programování pod prsty. Zkusil jsem proto lokální SVN server s už tehdy skvělým GUI TortoiseSVN a rychle si na nový styl práce zvykl.
Teprve mnohem později jsem začal používat veřejné SVN. Pokud si odmyslím nezpochybnitelné komunitní výhody, jako je spolupráce více vývojářů a přidaný rozměr pro chápání kódu (čas), nepřineslo to z hlediska jednotlivce nic pozitivního. Nešlo pracovat offline, dříve okamžité operace trvaly dlouhé sekundy. Jakákoliv chyba byla navždy zvěčněna v historii repositáře. Zjistil jsem, že během vývoje dílčích částí zase verzuji RARem a Subversion mi přestal pomáhat.
Oči mi otevřel až Karmi, když mi ukázal, že kromě centralizovaných repositářů, jako je SVN, existují i distribuované (DVCS), které všechny zmíněné problémy řeší. Jsou umístěny lokálně s celou historií, takže nepotřebují internet a reagují bleskově. Lze v nich zkušebně rozvíjet několik vývojových cest. Ty slepé smažete, správnou pustíte na „centrální“ repositář. Úžasné! A tím výčet výhod nekončí.
Přejít na distribuovaný verzovací systém mi vyplynulo jako nutnost.
Jaký distribuovaný systém zvolit?
Karmi propaguje Git, který současné úložiště mých projektů Google Code nepodporuje. Nabízí však alternativu v podobě systému Mercurial (HG). Kromě těchto dvou je ještě slyšet o Bazaar. Který z nich zvolit? Jak se liší?
Pustil jsem se do důkladné rešerše a zjistil, že dobrat se odpovědi není vůbec snadné. Protože Subversion ve prospěch distribuovaných systémů opouští čím dál více projektů (jen PHP nyní slavně přešlo na SVN, hehehe), narazil jsem na tyto analýzy:
Z obou je cítit bezradnost a ačkoliv volba padla na Mercurial, důvody nesouvisí s objektivní kvalitou systémů. Navíc za poslední půl rok se hodně změnilo a zmíněná absence GUI pro Windows v případě Gitu je dnes naopak jeho předností (tj. už má skvělé GUI).
Z dalších úvah jsem vyřadil nejmladší a nejméně populární Bazaar a podíval se zblízka na Git s Mercurialem.
Git
- obrovský a komplexní projekt (možná až zmatený a nesrozumitelný)
- umožňuje zasahovat do historie, mazat slepé větve
- domovem je mu Linux, na Windows to není úplně ono
- napsaný v C a shell skriptech
- import i export SVN včetně historie
- hosting: Github.com (mnohem lepší než Google Code)
- GUI nástroj: TortoiseGit (vypadá přesně jako TortoiseSVN) a GIT Cheetah
- dokumentace (český překlad, začátečníkům nesrozumitelná)
- cheat sheet
Mercurial
- malý a chytrý (ovládáním podobný SVN)
- nelze zasahovat do historie
- výborně funguje na všech platformách
- napsaný především v Pythonu
- import SVN včetně historie
- hosting: Bitbucket.org (mnohem lepší než Google Code)
- GUI nástroj: TortoiseHg (jen se vzdáleně blíží TortoiseSVN)
- dokumentace (anglická, ale čtivá a srozumitelná)
- cheat sheet
Na rozpacích
Od začátku mi byl sympatičtější Mercurial, protože mám raději malé, šikovné a promyšlené věci, než molochy (nejen ve frameworcích). Lépe funguje na Windows (import SVN repositáře je 70× rychlejší než na Git). Podporuje jej Google Code.
Jenže svět je složitější. Příklad: Mercurial má srozumitelnější příkazovou řádku, podobnou té v SVN. Jenže stejně ho budu ovládat pomocí GUI. Tam naopak (dnes) vede TortoiseGit, který jako by z oka vypadl TortoiseSVN, zatímco TortoiseHg je hodně jiný a slabší. Ale tím, že je jiný, umožňuje commitovat tzv. hunks. Což se mi skutečně často hodí. Nicméně s distribuovaným repositářem přichází jiný styl práce – budu i poté potřeboval hunks?
Mercurial čísluje revize, Git používá 40 místný hash. Preferuju samozřejmě číslo, ale není to jen pozůstatek SVN uvažování?
A tak by se dalo pokračovat dále. Nejsem zatím schopen říct, který ze systémů více vyhovuje mým potřebám. Jediná možnost je oběma věnovat několik dní času a zkusit s nimi pracovat. Co však můžu říct s naprostou jistotou je, že SVN chci opustit.
Komentáře
Radek Hulán #1
SVN má pořád jednu významnou výhodu (a proto od něj osobně neustupuji) – je podporován v obrovské spoustě IDE, v mém případě UEStudio, a přímo z editoru se dá dělat checkout, import, export.
Nejsou poté potřeba externí aplikace jako je TortoiseSVN a je to fakt dost pohodlné.
Lubomír #2
Co se týče commitování jenom části souboru, tak to git jako takový umí (
git add -i), ale jestli se to dá udělat přes TortoiseGit netuším.Richard Bukovansky #3
Je to pozustatek. Git se nezajima o verzi jednotlivych souboru, ale celeho stromu. Ono i ten Mercurial pouziva hashe stromu, akorat k tomu pridava to cislo verze souboru. Je lepsi si zvyknout na hash celeho stromu, nez na nejakou napul cestu → pokud si vzpominam, kdyz jsem se pokousel Mercurial pouzivat, nez jsem definitivne presel na Git, tak stejne dochazelo v Mercurialu k precislovani revizi souboru, kdyz se pullne nejaky strom, a pak je to cislovani revizi uz mimo.
Ono stejne, clovek nakonec dojde k tomu, ze neresi hashe, revize, ale branch, ve kterem neco vzniklo, a commit popisy. Na hashe dochazi vetsinou az pri bisectu…
Pro Git na Windows doporucuji ale pouzit msysgit nez Git pod Cygwinem, je to relativne rychlejsi a podle mne se s tim i lepe pracuje.
Ad import SVN: Clovek to stejne udela jednou a pak je od toho pokoj, ale spise bych doporucil zacit tak, ze aktualni strom ze SVN proste dam jako prvni commit do Gitu, nez to importovat.
David Grudl #4
#1 Radku Huláne, zase Tortoise nástroje se integrují přímo do exploreru, takže IDE používající nativní Windows prvky (např. PHPEd) získávají podporu automaticky, včetně zelených/červených piktogramů u souborů. V jiných editorech to samozřejmě může být jinak.
#2 Lubomíre, nepřišel jsem na to, jak toho docílit. Přitom TortoiseHg to umí pohodlně, ale samo o sobě pohodlné není ☹
#3 Richarde Bukovansky, ta změna workflow je docela těžká. Teď řeknu: tahle vlastnost je od revize XY, pokud používáš XY-1, nebude fungovat. Hash je vedle toho lidsky neuchopitelný.
(teď si uvědomuju, že si nejspíš nerozumíme, já se nebavím o číslování verzí souborů, ale stromu, což Git neumí – či umí?)
ad import: jasně, dělá se to jednou, ale je to pěkný příklad problematické migrace Linux → Windows. Navíc mi to nějak divně rozjeb*** revize, budu to muset ještě prozoumat.
xpj #5
Já nevím. Před časem jsem potřeboval udělat malý patch do jednoho subprojektu NetBeans a začal zjišťovat, jak to udělám. Bohužel, zjistil jsem, že používají Mercurial a že si opravdu musím stáhnout úplně celý strom i s historií.
Asi si dokážete představit, že stahovat zdrojáky NetBeans není nic příjemného, nakonec to bylo víc než 1Gb dat.
Se SVN bych si stáhnul jen ten jeden subprojekt…
Xificurk #6
#4 Davide Grudle, Od číslování revizí jsou v gitu tagy. Nemá cenu např. kvůli opravě překlepu v nějakém komentáři měnit číslo revize (hash se samozřejmě změní), nový tag je dobré přihodit „jednou za čas“. A lidské chápání toho, že od revize XYZ něco funguje, je zachováno.
V SVN se tohle většinou řeší tak, že se s opravou toho překlepu počká na nějakou větší úpravu a k tomu commitu se to přilepí, což je imho špatné myšlení a jeden z důvodů, proč SVN opustit.
Jakub Bouček #7
Jsem z článku na rozpacích. SVN jsem začal používat před několika měsíci a byl to takový posun vpřed, že jsem ještě nestrávil všechny jeho klady a teď mi tady děláš chutě na DVCS. Po tomto představení musím říci, že kdyby Mercurial měl Tortoise podobně brilatní jako SVN nebo GIT, tak podle tvého popisu neváhám ani minutu. A Git vypadá dobře v rámci výbavy a GUI, ale pokud má problémy mezi platformami, tak to mi zavání ukvapenou implemetnací jinak dobrého návrhu, což se může časem vymstít (a ano, chybí tam přesně ten svěží dojem preciznosti). Nechám to pár měsíců uležet a pak uvidím, jak který projekt vyspěl.
#4 Davide Grudle, Tortoise je úžasné rozšíření exploreru, a je zpracované velmi citlivě, že opravdu velmi dobře funguje i v jinak nepoužitelných dialogových oknech např. Javových aplikací. Na druhou stranu, itegrace SVN (a dalších) například do textového editoru je ještě o pár levelů lepší záležitost.
David Grudl #8
#5 xpji, u Git lze stáhnout i malou část historie, v případě Mercurial nevím. Ale obecně kvůli udělání patche není potřeba repositář stahovat, dá se pracovat i se vzdáleným serverem.
#6 Xificurku, zcela souhlasím, že „přilepit k většímu commitu“ je špatné, ale nesouvisí to se SVN. Nikdo přece nikoho nenutí mít všechny commity stejně důležité. V podstatě je mi jedno, jestli budu číslovat commity nebo po pár commitech tagy, klíčové je, že se to čísluje samo. A nepřišel jsem na to, jak to v Gitu zajistit. Víš jak na to?
#7 Jakube Boučku, není kam spěchat ;)
Messa #9
Git se mi líbí pro komunitní vývoj, typicky open-source aplikací (jako je i Texy). Vlastně se mi zdá, že důležitou vlastností projektu je, aby měl nějakého hlavního správce, co se o ten hlavní git repozitář bude starat. Také se projevil jako zajímavá možnost verzování adresáře /etc a záloh databáze 🙂
Ale… V práci používáme SVN, nedokážu si dost dobře představit, jak by vypadal workflow s Gitem – to by se buď jelo „centralizovaně“ (pushovalo do jednoho repozitáře, to je prý špatně a bez rozdílu oproti SVN), nebo by musel být určen jeden člen týmu jako začleňovač? Nebo snad fetchovat ode všech kolegů najednou? Zkoušel jsem Git pro osobní věci (poznámky, soukromé projekty) a SVN se mi také zde jeví pohodlnější. Tak nevím, pokud se nedočkám zde v komentářích, asi počkám na Karmiho, až to někde bude vysvětlovat 🙂
Pavol #10
Aký bol dôvod zavrhnutia Bazaaru?
Borek #11
Perfektní, ve stejnou dobu řešíme stejný problém a máme z gitu a hg dost podobný pocit. Jen se lišíme názorem na Subversion.
Pokud máš kontektivitu, je podle mě zcela rozdíl mezi výkonem svn a DVCS malý. DVCS je objektivně třeba 1000× rychlejší, ale v reálu je mi jedno, jestli na commit čekám desetinu nebo dvě sekundy. Stejně si rád dám maličkou pauzu po dokončeném úkolu.
Offline je killer feature DVCS, bez debat Možnost pracovat lokálně je naprosto bombastická a já doufám, že aspoň lokální cache se v svn objeví.
Možnost měnit historii je podivná vlastnost, neovlivní to hashe novějších revizí? Myslel jsem, že každý hash je hashem i předchozího hashe.. (uff :) )
Co se týče hunks, dovolil bych si říct, že pokud je často potřebuješ, není něco úplně v pořádku. Já bych je sice taky občas v svn ocenil, ale je to spíš výjimka než pravidlo (třeba když mergnu kód od někoho jiného nebo se prostě nechám unést a nepracuji po logických celcích).
Ovšem zcela zásadní „vlastnost“ svn: když lidem řekneš „moje repo je na google code“, všichni budou vědět, jak získat poslední verzi, jak získat nějakou konkrétní tagnutou verzi apod. Když jsi ale přešel na git, tví „uživatelé“ budou muset hledat pluginy do svých IDE, budou muset instalovat další Tortoise (takže v menu průzkumníka budou mít zas o něco větší bordel), budou se muset učit, jak se s gitem pracuje, prostě stráví čas s něčím, co je velkým hitem zatím jen v relativně úzké skupině lidí. Osobně tomu asi ještě tak rok dva dám, nástroje musí vyzrát, lidi si na DVCS musí zvyknout a osobně bych to asi nelámal přes koleno. Pokud ti DVCS fakt pomáhá o tolik víc než svn, vždycky můžeš jako „reálné“ repo používat git a na SVN dávat jen verze určené pro veřejnost.
Borek #12
#10 Pavole, U mě malá komunita a primitivní Tortoise. Jinak technologicky se mi líbí asi nejvíc ze všech.
Juraj Michálek #13
Distribuovaný source control? Čo tak Darcs :) https://darcs.net/
David Grudl #14
#9 Messo, co je na centralizovaném workflow špatné? Nedovedu si představit, jak to dělat jinak.
#11 Borku, commit asi jako jediný mi časově nevadí, ale takový blame nebo vyhledávání v historii, to je děs. Nicméně doba trvání operací je ten nejmenší problém. Vadí mi workflow a styl práce, viz článek.
Souhlasím, proto jsem také zmínil „mazání slepých větví“ jako jediné mi pochopitelné využití.
Není něco v pořádku, cítím to delší dobu a proto chci přejít od SVN. Běžná situace, kdy má člověk něco rozdělaného a musí „přepnout kontext“ a vyřešit něco akutního. V SVN-workflow se mi hunks hodí, ale tak nějak doufám, že v novém workflow je potřebovat nebudu.
Tady ti moc nerozumím. Na Google Code můžeš mít repo od Mercurial, stejně si ale myslím, že Github nebo Bitbucket je přívětivější (ale tam jsi asi nemířil…). Zkrátka nemyslím si, že repo je něco pro veřejnost. Pro veřejnost je archív ZIP.
Borek #15
#14 Davide Grudle, Blbě jsem se vyjádřil, měl jsem na mysli jakýkoliv svn hosting, GCode jsem zmínil jen proto, žes tam dřív měl své projekty. Jinak si vlastně říkám, co jako „veřejnost“ od cizích repozitářů očekávám, a je to asi kouknutí, jestli se na projektu něco děje skrze seznam posledních commitů. A to umí každý hosting, co znám, bitbucket a github dokonce líp než GCode, takže asi fakt není co řešit.
Jinak mně „přepnutí kontextu“ nenastává moc často – dokonce bych řekl zcela výjimečně. Commituju každých pár minut, takže většinou můžu dodělat to, na čem právě dělám.
Messa #16
#14 Davide Grudle, V oficiální dokumentaci není používání sdíleného repozitáře doporučované, právě pro jednoduchost výměny patchů a pullování z veřejných repozitářů. Mě se to ovšem s tou jednoduchostí zdá většinou trochu obráceně…
Freemanix #17
Pánové, až se tu stydím přiznat, že jedeme stále postaru v CVS. Pomalu jsem chtěl přejít na to SVN … 🙂. Nemusíte mi tu vysvětlovat rozdíly, omezení v CVS jsem si plně vědom.
Nicméně, velice jsem si oblíbil separátní aplikaci WinCVS. Člověk chvíli vyvíjí, pak si dá pauzu, přepne se do WinCVS, projde v klidu změny, zda je vše, jak má být a commituje.
S Windows Explorerem nepracuji, nesnáším ho, na to mám TotalCommander. Nevíte proto o nějaké takové nadstavbě jako je WinCVS? Asi setrvačnost, ale u mne je to důležitá vlastnost při výběru lepšího systému verzování.
SneakerXZ #18
Osobně jsem se rozhodoval zhruba před půl rokem taky mezi Git a Mercurial. Šlo mi hlavně o mé malé projekty a to co v budoucnu na nich použiju.
Nakonec jsem zvolil Mercurial. Důvodu bylo několik a pokusím se je sepsat.
V ostatních aspektech jsou víceméně na stejno. Jediná věc, která mi na Mercurial chyběla byla nějaká lepší podpora pro branche nebo pro různé experimetální větve. Každopádně nakonec mi to nechybí jelikož mi na jednom fóru bylo doporučeno, ať si prostě svůj repozitář naklonuju a ať si hraju na klonu, což nakonec je ještě lepší. :)
Pěkné srovnání je i zde – https://web.archive.org/…erthanx.com/ až na bod s GitHub. Mercurial má BitBucket, což je to samé víceméně.
David Grudl #19
#17 Freemanixi, já pracuju s Far Managerem a tam mi Tortoise nástroje fungují skvěle, v Total Commanderu to bude ještě lepší.
David Grudl #20
#18 SneakerXZi, BitBucket mi dokonce připadá ještě o fous lepší. Jinak také mám pocit, že klon je srozumitelnější než větev.
SneakerXZ #21
Ještě bych doporučil kouknout na nástroj CuteHg něco jako TortoiseHg.
jasir #22
Komitovat jednotlivé řádky TortoiseGit neumí, ale umí to msysgit. Není sice moc hezký, ale funkční je výborně. Kombinuji s TortoiseSVN.
Mám to všechno v PhpEdu na klávesových zkratkách (diff, revert, commit, log, rename, delete + msysgit) a opravdu spokojenost (pravda. po trochu komplikovanější instalaci).
Dušan Janošík #23
Když už to tady řešíte, přihodím jednu otázku. Máte někdo zkušenosti s integrací systému Git (Git Extensions) nebo Mercurial (HgSccPackage, VisualHG) do Visual Studia? Jak jsou na tom ve srovnání s VisualSVN nebo AnkhSVN?
SneakerXZ #24
#23 Dušane Janošíku, Používám VisualHG. Úroveň VisualHG je stejná jako TortoiseHG. Taky VisualHG potřebuje mít nainstalovaný a používá jeho nástroje. Každopádně na vyřešení merge, udělaní diff, commit a synchronizaci repozitářů bohatě stačí. Samozřejmě toho umí víc – to samé co TortoiseHG.
LLook #25
#17 Freemanixi, Total Commander dokáže do vysoké míry přejímat chování Windows Exploreru. Třeba rozšíření kontextového menu se snad ani nedají zakázat a odtud se právě Tortoise ovládá.
Pokud jde o ikonky SVN (fajfky a vykřičníky u složek a souborů), tak to musíš v TC v Konfigurace → Možnosti → Ikony zaškrtnout „Zobrazovat překryvné ikony“.
Pak máš stejný komfort, jako v Exploreru. Žádného samostatného správce typu WinCVS ale myslím Tortoise nenabízí. To je slabina.
David Grudl #26
#21 SneakerXZi, to vypadá perfektně, na obrázcích, ale rozchodit se mi to nepodařilo ☹
Jakub Kulhan #27
Odkazovat na překlad GitMagic jako na dokumentaci… Ajaj, co jsem to jen vyvedl. GitMagic je jedním z mnoha tutoriálů na Git. V naší kotlině toho moc o Gitu není, tak jsem se ho rozhodl přeložit. Ale odkazovat na něj jako na nějakou „dokumentaci“, to prosím né. Tak špatnou reklamu Gitu dělat nechci.
#11 Borku,
Mění. Do historie sahat jen ve svém vlastním klonu, kde to nikomu a ničemu dalšímu nevadí – jak se commity dostanou někam na veřejnost a člověk by soustavně poupravoval historii, je velice pravděpodobné, že by ho za to lidé ukamenovali.
#20 Davide Grudle,
Pracoval jsem chvíli s Mercurialem a to, že pro zkušební „větve“ se vytváří nový klon mě neuvěřitelně štvalo. V čem je to srozumitelnější? (Nebrat jako nějaký útok, pouze se zajímám, jak to vidí ostatní.)
David Grudl #28
#27 Jakube Kulhane, Jakube, ten GitMagic víc odpovídá formě dokumentace, jakou odkazuju u Mercurialu a jakou bych odkazoval u SVN. Navíc je výborně přeložená. Ale bohužel, kromě první kapitoly je to napsané tak, že kdo Gitu nerozumí, ten ani neporozumí. Přesto jde o mnohem srozumitelnější materiál než je Git manuál.
Pro začátečníka je srozumitelnější chápat různé větve jako různé adresáře, než jeden adresář, kde se děje jakási magie. Jako pokročilý uživatel budeš mít zase jiné nároky.
ady #29
Ja jsem si prosel postupne CVS, PVCS, SVN a ted jedu mesic na gitu (menilo se to v zavislosti na zamestnavateli ci projektu). A musim rict, ze postupne se nechut meni ve vetsi a vetsi nadseni.
Prvni prekazkou byla zmena mysleni v pristupu k cislovani a filozofii systemu. Prvni den, kdyz jsem s gitem zacinal jsem si checkoutnul (naklonoval :) centralni repository a jal se vytvaret slozku branches, do kterych jse mis chtel cpat jednotlive branche (pozustatek ze SVN). Po chvilce jsem zjistil, ze branche se proste meni v hlavnim diru behem okamziku. Zjistit rozdil mezi dvema commity je trivialni veci, protoze ma kazdy commit jednoznacny hash. To same revertovani, pridavani commitu do jineho branche (cherry-pick), moznost update u sebe a nasledne prepnuti do jakehokoliv branche se zachovanim lokalnich zmen pro pozdejsi editaci (stash), je toho fakt hodne a nejlepsi na tom je ze ty operace jsou oproti CVS/SVN bleskove.
V praci fungujeme tak, ze na DEV serveru je master, na kazdem developerovi pak je, kde bude mit svuj local repos (defaultne je v home na DEV serveru) a verze releasu delame jako jednotlive branche. Je opravdu rychlovka vypropagovat nejaky fix na live branch ci test machine, popripade updatnout na novy branch ci udelat revert.
Ze zacatku me fakt mrzela nepritomnost nejakeho normalniho GUI (jedeme komplet na Linuxu / vetsinou Ubuntu), Netbeans tusim nema zatim nic a pro Eclipse jsou k dispozici dva vicemene nepouzitelne pluginy na vaznou praci. Po par dnech na prikazove radce uz ale GUI vicemene nepotrebuji a mozna by me i zpomalovalo.
jasir #30
Pro zájemce zde „rychlokurz“ gitu na windows, v tomto případě msysgit. https://web.archive.org/…de/tour.html
S obrázky… 🙂
Richard Bukovansky #31
#4 Davide Grudle,
Ano je. Je to priserny kopanec do pozadi (mozna i do hlavy), ale jak se do toho clovek dostane, tak je to parada a nechce se mu zpet. :)
Ano, je, ale ze zacatku to ber proste jakoze hash = revize stromu v silenem tvaru. Ale spis je to o tom, ze se proste koduje, komituje, koduje, komituje, koduje, komituje, pripravi se release a upstream strom se otaguje. Prichozi patche pak musi chodit pripraveny tak, ze patchuji za/na ten tag a nebo si fetchujes neci klon/fork tveho stromu a rozhodujes se sam, co si k sobe pustis. Ja to takhle moc neumim popsat, v tomhle jsem lepsi, kdyz to vysvetluji tzv. per huba a muzu u toho kreslit. ;)
Budes-li mit zajem, tak se muzeme na expresnim rychlokurzu do Gitu domluvit. Rad pomuzu.
Aha, to neumi. Ono taky proc? Na hash se taky da pohlizet na GUID/UUID stromu v danem okamziku, coz zajistuje prave tu moznost toho D ve zkratce. ;)
On je dost problem v tom, ze Git technologicky jako takovy je silne zalozen na tom, co umi Unix systemove. Jako pametove presuny, velmi rychle operace s I/O apod. Coz bohuzel neni tak jednoduche preportovat na Windowsy.
Jak jsem jiz pravil, ty importy do Gitu jsou fajn, ale podle zkoumani, co jsem delal, je pri prechodu na DVCS nejlepsi zacit historii od zacatku. Udelal to tak Linus s kernelem, tak proc bys nemohl s Nette/Texy/etc. Historii v SVN dej na web v read-only formatu, a pokud se tim nekdo bude chtit hrabat, tak at ma moznost.
Ad GUI: Doporucuji se taky mrknout na QGit. Jako graficky prohlizec historie nema chybu.
Ad branche v Gitu: Jenze pak stejne ve finale musi clovek pochopit to, ze Git ma jenom jeden working directory, kde se deje magie. Navic nemusim pak premyslet… Kurnik, v kterem adresari mam vlastne tu zmenu udelanou? S Gitem pdu proste do adresare s danym a nemusim se starat. Navic to setri misto…
Ono, nekdo chytry kdysi pravil: DVCS nemuzete pouzivat, dokud nepochopite, jak presne funguje.
Pro zacatecnika blbe, ale hodne pravdive…
#9 Messo,
Predcimz Linus varuje. Na to neni Git ani jiny verzovaci system stavene a delane.
To je spatne a opravdu na takovou vec nepotrebujete Git, to si uzijte se CVS ci SVN. Tyto systemy jsou na tohle lepe pripraveny.
Vzdy doporucuji podporit firemni strukturu Gitem ala struktura vyvojaru Linux kernelu, tedy 1–3 hlavni stromy, stromy spravcu nejakych systemu, stromy spravcu subsystemu, pak stromy vyvojaru. Pak mit strom pro vydani, ktery prebira z tech hlavnich stromu. Njo a ve vysledku to pak je tok patchu Vyvojar → Spravce subsystemu → Spravce celku → Spravce hlavniho stromu → Release strom. Pokud se v kazdem bode zkontroluje kod (code review, unit testing, dalsi manualni testovani), pak se do hlavniho stromu nemuze dostat neco, co by zpusobilo nejake velke nekalosti, coz se s centralizovanymi VCS deje bezne…
Vypada to mozna slozite, ale pokud se takovy proces zavede, tak kvalita kodu jde rapidne nahoru… Pac, pokud budeme brat jako stezejni hlavni stromy, malokdy se tam dostane nejaka kravina… ;)
Hm, jak to tak po sobe ctu…
Rekognoskuju teren… Byl by zajem o skoleni Pouziti Gitu/DVCS ve firemnim prostredi a jak se toho nebat? :)
Honza Sterba #32
Pár poznámek od člověka který již nějakou dobu každý den musí používat svn, hg i git.
Borek #33
#20 Davide Grudle, Když máš projekt otevřený v IDE, tak je switch v svn daleko pohodlnější než clone v hg (tam totiž musíš re-importovat projekt do IDE). Tahle filosofie klonování je asi to hlavní, co mě od hg odrazuje, ale snad už teď nějak rozumně podporujou i „inline“ větve.
Vojtěch Kusý #34
Vyzkoušel jsem Bazaar, Mercurial a Git. Všechny jsou oproti SVN při „lokální práci“ neuvěřitelně rychlé a úsporné (initial commit do lokálního „repozitáře“ trvá i při XXmb a tisících souborů maximálně pár sekund, velikost zanedbatelná …).
Při používání v příkazovém řádku mi nejvíce seděl Bazaar, má syntaxi ještě o něco lépe použitelnou než Mercurial. Git jsem zavrhnul skoro hned, právě kvůli jeho robustnosti a složitosti. Nakonec jsem zůstal u Mercurialu, z těch tří má nejlepší integraci do Eclipse/Zend Studia (zaintegrovat jdou ale všechny tři), které používám k práci, a jeho už dotažený do stabilní konečné podoby. Bazaar stále prochází poměrně bouřlivým vývojem a TortoiseBzr, Eclipse Plugin apod … jsou také zatím víceméně „ve vývoji“.
Zatím jsem se v používání verzování, ale moc daleko nedostal, resp. dostal jsem se max. k mergování větví. Používám spíš základní funkce, na poli „advanced features“ jako skriptování apod. nemůžu hodnotit…
David Grudl #35
Možná bych měl ještě dodat, že Nette Framework dva dny běží na Gitu (https://github.com/nette/nette). Přechod se samozřejmě neobejde bez vyřešení nějakých dětských nemocí, ale jinak jsem velmi spokojen.
Matěj Koubík #36
#15 Borku, Já (v hg) řeším přepínání kontextu branchováním – současný stav commitnu, přepnu se o revizi zpátky a vytvořím novou větev pro druhý kontext. Mám tak 2 „heady“ pro 2 různé kontexty, mezi kterými se můžu přepínat a commitovat k nim. Když oba kontexty (featury) dokončím, mergenu je. Teď se snažím zvyknout si na to, vytvářet automaticky větve pro každou větší novou featuru a tu po dokončení mergeovat do hlavní větve. Menší featury (2–3 commity) jsou přímo v hlavní větvi. Navíc bugfixy dávám v historii přímo za revizi, která to rozbila a opět mergeuji. To je přístup, z kterého bych se v SVN asi zbláznil, ale v DVCS je to elegantní.
Borek #37
#36 Matěji Koubíku, Proč by ses z toho v svn zbláznil? Tohle workflow používám taky a zcela bez problémů.
Roman Ožana #38
Změna je život. Každopádně GitHub vypadá velmi zajímavě, všiml jsme si toho, že jeho popularita úspěšně roste.
Možná, že se někomu bude hodit tohle. https://nbgit.org/ – plugin pro NetBeans, podporující GIT.
Karel Minařík #39
#37 Borku, Borku, ale… :) To je pořád dokola :) To že ty to děláš „bez problémů“ apod. apod. apod., znamená jen to, že ty to děláš „bez problémů“. Není to přenosné dál a není to argument pro to, že to všichni ostatní také mají dělat přesně stejně a „bez problémů“ :)
Přesně to workflow, které popisuje David Grudl a Matěj Koubík, je jedna z největších výhod Gitu a ostatních DVCS. Málokdo na světě zpochybňuje to, že oproti Subversion (typicky) jsou podobné operace a) pohodlnější, b) rychlejší.
Karel Minařík #40
#9 Messo,
Sepsal jsem odpověď na otázky, ale blog mi poradil, že „Nechci ti do toho kecat Karele, ale tak strašně dlouhé komentáře fakt nikdo nečte…“ :)
Takže jsem chtě nechtě musel komentář přeložit do článku Tož Git dorazil i k nám
Prosím především čtěte pro vyvrácení obecně oblíbeného omylu, že „centralizované workflow“ je něco, co se s Gitem nehodí, nesmí nebo nemá.
Aleš Roubíček #41
#40 Karle Minaříku, Pěkná reakce :) Jen doplním, že s Tortoise nástroji je vytvoření repository v Gitu i v SVN na dvě kliknutí :) Jo a tohle
scp -r .git user@example.com:/home/user/interesting/project.gitagit remote add origin user@example.com:/home/user/interesting/project.gitmi zrovna dvakrát intuitivní nepřijde ;)OT: nechceš si hodit Ephemeru do svého FriendFeedu? :) Rád bych jí tam viděl.
Karel Minařík #42
#41 Aleši Roubíčku, Jasně, dvě kliknutí, a proti tomu DIY shell script
create_remote karmiapod apod apod, tuhle debatu jsme už přece vedli :D Ale chápu samozřejmě dobře, že to může přijít neintuitivní (nicméně jen se pomocíscp– tzn. copy over SSH – přenese .git adresář s repo „někam“ a pak se pomocígit remote addpřidá). (Já zapomněl, že nějaký FriendFeed mám, dám to tam :)Dundee #43
Github se mi libí. Nenašel jsem ale možnost vytváření překladů. Přitom se ale zdá, že github umí dělat grafy přeloženosti projektu, tak nevím.
Borek #44
#39 Karle Minaříku, Sorry, ale #36 je FUD, nic víc („to je přístup, z kterého bych se v SVN asi zbláznil“ – tenhle workflow se v svn bez problémů používá, feature branches jsou naprosto normální věc). Nevidím žádný důvod se tohoto FUDu zastávat, zvlášť s použitím kvaziargumentace („málokdo na světě zpochybňuje, že…“).
Hele, nic proti DVCS a gitu, jejich výhody uznávám, ale podle mě není žádný důvod se do svn urážlivě navážet, viz např. „oni jsou asi ti vaši uživatelé zvyklí na tu idiotsky lineární historii v SVN“ a podobně. I pokud věříš tomu, že git je ve všech ohledech lepší než svn (což si třeba osobně nemyslím), lze to snad říct normálně, s použitím argumentů (a ne kvaziargumentů) a bez urážek druhé technologie.
karmi #45
#43 Dundee, Jak přesně to myslíš s „možností vytváření překladů“? (Github má „languages“ graf, ale to se týká programovacích jazyků .)
Mj. má Github i moc zajímavý tzv. „impact“ graf, který hezky ukazuje, kdo přesně kolik v repositáři udělal. (Samozřejmě pro SVN import to může být nepřesné, i když se nastaví mapování SVN user => Git commiter.)
Dundee #46
#45 karmi, Aha. Já myslel, že se jedná o graf, jak je která jazyková varianta hotová.
Vytváření překladů (gettext) přímo v projektovém úložišti je skvělá věc. Výborně to má vyřešené třeba Launchpad.
karmi #47
#44 Borku, Hm. Z mého pohledu je #36 Matěj Koubík přiznaný subjektivní komentář – říká doslova „[já] bych se z toho zbláznil“. Já taky :) FUD (fear, uncertainty and doubt) by byl např.: „ …SVN s branchemi vůbec neumí pracovat a nejde to používat“. To ale (tady) nikdo neříká.
Názor, že práce s branchemi a mergování je v Gitu a spol. obecně jednodušší než v SVN je názor obecně sdílený, uvádí se jako jedna z hlavních výhod, na prvních místech. Že branchování a mergování má v SVN svá slabá místa, přiznávají i autoři SVN z CollabNet … Nikdo přitom neříká, že Git nemá zase svoje slabá místa.
karmi #48
#46 Dundee, Tak toho jsem si na LaunchPadu nevšimnul, díky! – to je pěkná vlastnost, zvláště pro Ubuntu a spol., kde je lokalizace zásadní a využívaná.
Almad #49
Ha, konečně někdo kdo to propaguje a člověk už se nebude muset babrat s těma svn projektama ,)
David: Ad to vzestupné verzování v gitu, používáme kombo „tag jednou za čas“ + git describe, přičemž „počet commitů od posledního tagu“ přidáme jako další číslo verze. Pro průběžné buildění balíků a nasazování to funguje fajnově.
Jinak teda v práci jedu na gitu, pro sebe na mercurialu…jsem o něco spokojenější s hg, git měl rozhodně brutálnější učící křivku, ale vyjde to asi ± na stejno, jenom mám pocit že u hg méně píšu a vůbec UI je takové hezčí.
Almad #50
Ah, ještě bych málem zapomněl, Python píšu v netbeans a ti mají výbornou podporu hg (neb se v sunu používá jako default), takže to může být taky důvod, proč mám pocit, že mi vyhovuje víc.
Ale možná to spíš budou hg pluginy.
nes_ro #51
Pro mně jako uživatele je to velmi příjemná změna oproti google code. Všiml jsem si toho teď přes RSS a je to mnohem přehlednější. Byl to určitě krok správným směrem. 🙂
retro #52
#29 ady,
Sakra a co https://web.archive.org/…clipsePlugin nebo https://nbgit.org/ (oboje mi příjde docela na slušný úrovni) ?
Štefan Húska #53
V práci aj súkromne už viac než rok jedine GIT. Mal som možnosť vidieť školenie od Karmiho a GIT ma dokonale uchvátil. Ani prechod zo SVN našich Ruby on Rails projektov nebol tak bolestivý. Jednoducho sme SVN importovali do GITu aj s celou históriou a hotovo :)
Tento článek byl uzavřen. Už není možné k němu přidávat komentáře.