Subversion upgrade

22.10.2012 14:43 | Přečteno: 1500× | Linux | poslední úprava: 22.10.2012 20:19

Tak se mi konečně podařilo provést upgrade na nový Subversion server.

Protože vývoj v naší firmě probíhá centralizovaně, bylo před pár lety rozhodnuto přejít ze všech lokálních SCM na jedno společné, a tím se stalo Subversion. Sice v tom bylo dost politiky, na druhou stranu musím uznat, že ze všech navrhovaných řešení bylo vzheldem k sesbíraným požadavkům nejvhodnější.

Tak někdo zbastlil virtuální server, nalil tam Collabnet 1.5 a nějak to jelo (=na hovno). Pak jsem dostal Subversion na starosti já. Postavil se nový server na RHEL5, nasadil se vyladěný Apache s mod_svn. S přibývajícími daty začala rychlost klesat (ne moc, ale uzeři si všimli) a já začal uvařovat o proxy cache, např. ngix, popř. přejít na DSCM, jenže...

Při sledování změn na poli SCM mě potěšila jedna věc - vývojáři SVN neusnuli na vavřínech, ale kouknuli k sousedům (Git) a tak má Subversion ve verzi 1.7 rychlejší protokol a Working Copy nemá .svn balast v každém adresáři, alle pouze na nejvyšší úrovni jako Git. Rychlost práce je někde jinde (porovnávám se SVN <=1.6).

A navíc vzhledem k centralizované povaze vývoje a úspěchu v tom, že vývojáři plus mínus pochopili alespoň Subversion, jsem myšlenku přechodu na DSCM zahodil.

Takže nadešel čas pro nový server. Na základě pozorování má nové virtuální železo 4 vCPU (rozložení zátěže při ranní a odpolední špičce) a 16GB RAM (mod_svn 1.7 podporuje cachování obsahu). Operační systém je RHEL6.3 64-bit. Přesun proběhl bez vážnějších komplikací (menší zádrhel na FW a jeden hook). První komentáře pozitivní, server se fláká i při největší zátěži (ale lepší, než se zase za dva roky dohadovat, že je potřeba víc RAM).

Jediný problém se vyskytl ve CM skriptech, které přes svn diff --summarize porovnávají změny v repositářích - u klienta došlo ke změně kódování URI (tj. chová se jako webový prohlížeč), takže oblíbené # překódovává na %23 apod. Ale to je jen maličkost...

Vzhledem k novinkám, co mají přijít v1.8 si osobně myslím, že Subversion překonalo vlastní smrt a že má nezastupitelnou roli tam, kde je DSCM zbytečný overkill...

       

Komentáře

[depka]

kolik to vlastne pouziva programatoru?

[Ruža Becelin]

Asi 150, viz dole.

[danaketh]

Kolik těch uživatelů máte, že pro to máš takovej stroj? Buď je SVN větší sajrajt než jsem myslel, nebo děláš ve firmě, která má stovky tisíc vývojářů. Ze zkušeností se SVN ale tipuju to první.

[Michal Fecko]

+1 GIT server pre 50 uzivatelov obstara HP Microserver NL40

[Ruža Becelin]

TO nerekne nic bez objemu repositaru

Jinak N40L je pekna hracka, mel jsem na ni zalusk, ale asi pujdu do TX100S3p

[Ruža Becelin]

150 programatoru, 25GB repositaru, spousta kodu vyvijeneho pod "centralnim bodem", co vyzaduje checkout 5GB dat.

JInak to zvladl i 1 vCPU a 3G RAM, ale ve spickach to bylo znat.

[danaketh]

Takže SVN je větší sajrajt než jsem myslel. Ale z vlastní zkušenosti vím, že donutit i pár programátorů pohnout se kupředu k něčemu lepšímu, bejvá skoro nemožný, natož jich donutit 150. Naše repa maj přes 100GB a máme to na VPSce s 1 vCPU a 2GB RAM. Ale dělá na tom cca 50 lidí ve špičce.

[Josef Kufner]

Tak nejlepší způsob jak upgradovat SVN je „git svn clone“.

[podlesh]

Je potřeba si uvědomit, že pro mnoho vývojářů je zavedení nového VCS jen manažerská buzerace. Z tohoto důvodu je Subversion ideální, protože se dá začít používat jako CVS a postupně objevovat nové zajímavé věci. Naopak zavedení gitu pro 150 vývojářů znamená získat tak 20-40 smrtelných nepřátel.

[danaketh]

Vývojář, kterému vyhovuje SVN nebo CVS (bože) musí bejt hrozný prase. Osobně neznám nikoho kdo by měl SVN rád. Používaj ho proto, že maj línýho nebo neschopnýho (což je většinou totéž) admina.

[Ruža Becelin]

Hele, ja chapu, ze kdo nepouziva DSCM je podle tebe untermensch, ale nemuzes si jit filtrovat emoce nekam jinam?

[mirec]

Alebo ako väčšina "itčkárov" sú leniví sa naučiť niečo nové keď sa ledva naučili niečo staré.

[Ruža Becelin]

To ale neni jenom o tom - ti lide jsou placeni za to, ze umeji programovat, pro ne je SCM pouze prostredek. Pokud budes delat sofera a vymeni ti auto, tak budes predpokladat, ze se ovlada +- stejne, ne, ze ti vymeni pul ovlæadacich prvku...

[smazáno]

Ja jsem teda placen i za to ze umim s gitem a radu dalsich veci . V dost nabidkach programtorske prace dneska vidis git explicitne zminen. Pokud ma programator problem pochopit git, tak nejspis nebude za moc stat ani jako programator.

[pavlix]

Pokud ma programator problem pochopit git, tak nejspis nebude za moc stat ani jako programator.

Tak pod to bych se podepsal. Zvlášť vzhledem k tomu, jak je Git navržen.

[xkucf03]

Takové řeči ve mne evokuje pocit, že Git je zřejmě náročný na pochopení a zvládnou ho tedy jen nadprůměrně inteligentní/nadaní lidé, jako např. programátoři.

[pavlix]

Podle mě ho zvládnou i podprůměrně inteligentní programátoři :).

Jde o to, že každý, kdo má něco společného s programováním by si měl osvojitungování spojových seznamů a stromů. Takže zatímco běžnému člověku je dobré nejdřív seznamy a stromy vysvětlit, programátor už má toto za sebou.

[Michal Kubeček]

Vůbec nemusí být prase. Pokud na projektu nepracuje moc lidí nebo si navzájem moc nepřekážejí, může pro ně být Subversion naprosto dostatečným řešením. Paradoxně s ní má pak problémy spíš někdo zvenku, kdo není s projektem natolik sžitý a potřebuje třeba dohledat opravu konkrétní chyby nebo z nějakých důvodů dlouhodobě udržovat vlastní větev (např. distribuční patche).

[smazáno]

Ja ocenim git pres svn i na projektech na kterych delam sam

[Ruža Becelin]

Souhlasim, navic, jak jsem psal, zavedenim GITu bychom neziskali nic extra - lidi prijdou rano, pripoji se na VDI, udelaji svoji praci, commitnou.

[Luboš Doležel (Doli)]

Člověk by u programátorů tak nějak čekal větší pružnost a otevřenost novým věcem.

[xkucf03]

A co třeba takový Bazaar, Mercurial nebo Fossil?

[podlesh]

Zkušenosti nemám, ale co jsem slyšel tak mercurial je (díky "heavy" větvím) mnohem stravitelnější.

[stativ]

„heavy branch“ je jen jiný výraz pro – uživatel se nenaučil používat příkaz branch.

Z osobní zkušenosti hlavní důvod, proč může být přechod na mercurial snazší je ten, že základní množina příkazů je velmi podobná Subversion, přičemž další funkcionalitu je možné se naučit, až když je to potřeba.

[pavlix]

základní množina příkazů je velmi podobná Subversion

To je i v Gitu. A ve většině ostatních. Kvůli decentralizaci je Mercurial v základu podobnější Gitu než Subversion.

Jo, pokud někomu přijde nestravitelné, že Git umí rychle a dobře pracovat s větvemi, tak to je potom těžké. Ale možná by stálo za to napsat vývojářům Gitu, jestli by ho nemohli zase trochu zkriplit, aby byl stravitelnější :).

[stativ]

To je i v Gitu. A ve většině ostatních.

Ne tak úplně, jsou tu věci jako staging area apod, které u gitu člověk musí znát předtím, než s ním může začít fungovat.

Kvůli decentralizaci je Mercurial v základu podobnější Gitu než Subversion.

V tomhle ohledu samozřejmě ano, ale z pohledu, jestli je Subversion podobnější Git nebo Mercurial, tak je to rozhodně Mercurial.

Jo, pokud někomu přijde nestravitelné, že Git umí rychle a dobře pracovat s větvemi, tak to je potom těžké. Ale možná by stálo za to napsat vývojářům Gitu, jestli by ho nemohli zase trochu zkriplit, aby byl stravitelnější :).

O větve nejde – ty mají Mercurial i Git prakticky identické, navíc po přechodu na některý z DVCS si dost lidí ze všeho nejvíce pochvaluje právě větve.

[pavlix]

Ne tak úplně, jsou tu věci jako staging area apod, které u gitu člověk musí znát předtím, než s ním může začít fungovat.

Ze začátku vůbec nemusí.

Nicméně později se to stane natolik podstatnou výhodou, že se snažím lidem opravdu index představit hned na začátku.

O větve nejde – ty mají Mercurial i Git prakticky identické

To jsem si právě myslel.

navíc po přechodu na některý z DVCS si dost lidí ze všeho nejvíce pochvaluje právě větve.

To co já teďka dělám s Gitem... rychlý vývoj bez ladu a skladu, následný několikanásobný přepis historie, následné rozeskládání patchů do několika větví, vyřazování patchů, které už jsou vyzkoušené... :).

[Josef Kufner]

Ono buzerace to je jen pro ty, kteří to neumí/nemůžou efektivně používat. A zrovna SVN efektivně používat ani moc nelze. Oproti tomu Git už dosáhl takové úrovně, že dokáže práci ušetřit a přitom nepřekážet. Zrovna nedávno mi git bisect ušetřil několikahodinové hledání chyby. To by se těm vývojářům muselo šikovně předkousat a přechod udělat tak bezbolestný, jak to jen jde.

[AraxoN]

Ako dlhoročný bývalý používateľ CVS a SVN musím povedať, že dobre chápem ľudí, ktorí pri SVN ostali. Na Git som prechádzal viackrát a vždy som bol z neho totálne dopletený a nakoniec sa vrátil späť ku stabilnému SVN. Nakoniec mi pomohla kniha ProGit, ktorú v češtine vydal CZ NIC. Teraz už na Git nedám dopustiť a používateľov SVN (či nebodaj CVS) ľutujem a súcitím s nimi. Git je super, ale nedá sa na neho prejsť len tak, že si proste poviem "teraz mám pol hodiny čas, tak idem prejsť na Git". Takto to nefunguje, alebo aspoň u mňa nefungovalo.

Takže gratulujem k tomu, že SVN sa zlepšilo a funguje ku spokojnosti. Ale odporúčam si pod stromček zaobstarať knihu ProGit, len tak - pre dlhé zimné večery.

[mirec]

No neviem, ja som na git prešiel len tak, teda najskôr z CVS na SVN a potom z SVN na GIT (najskôr git-svn, potom som hádam všetko premigroval na git). V každom prípade neviem, či je dobré tak obsiahlu knihu dávať niekomu naštudovať, z mojich skúseností je väčšina programátorov ehm ... dosť lenivá a určite sa vo voľnom čase nebudú učiť VCS (dám za to ruku do dverí). Preto radšej namiesto veľkých firiem pracujem v malom kolektíve kde mám okrem seba max. tak 5 lenivých ľudí. Keby ich bolo 150 tak asi otrieskam hlavu o stenu a idem niekam .. to je jedno kam.

[Aleš Kapica]

Já ji tedy k ruce mám - nechal si ji pořídit kolega a je to mé oblíbené záchodové čtení.

I když většinu toho co se tam člověk dočte možná nikdy nepoužije, ví kam se může alespoň v případě potřeby podívat.

[Ruža Becelin]

Diky. Ja vim, ze jsem ten neschopny a liny, protoze provozuji ten Subversion server, ale to je corporate policy, kterou ja respoktuji. Vedle toho mame par malych Git repositaru s Gitolite a podle potreby na mensi externi projekty muzeme nasadit i Bazaar a Mercurial.

ProGit mam doma, fajn knizka - git vyzaduje trochu jine mysleni, ale da se pochopit (i untermenschem jako ja)

Pro ty, co se do me opreli - uvedomte si, ze IT neni vzdycky ten, kdo rozhoduje, co se nasadi - samotny upgrade serveru vyzaduje cely projekt, dokumentaci, distribuci informaci atd.

Muzete si myslet, proc teda neodejdu jinam, kdyz nemuzu ani svobodne nasadit Git - no protoze prostedi firmy a kolegove mi vyhovuji, nechtel bych menit a tohle nevidim jako duvod.

Vetsi IT obvykle funguji jako poskytovatele sluzeb - a tem co nas plati, je jedno, jestli dole bezi Linux, Solaris, Windows nebo OpenVMS, jestli mame Intel nebo Alphy, jestli mam Git nebo Subversion. Pro ne je dulezite, zr TO funguje.

[danaketh]

Že to provozuješ z tebe nedělá líného a neschopného automaticky. To jen já mám takovou zkušenost. Ty jsi třeba schopný a pracovitý ale jak sám říkáš - je to corporate policy a s tím ty uděláš prd a tak se můžeš leda snažit aby to SVN k něčemu fungovalo.

A odcházet z firmy jen proto, že používaj SVN (zvlášť když ti všechno ostatní vyhovuje) by byla IMO pitomost.

[Ruža Becelin]

Jo, o tom presne mluvim

[pavlix]

Git je super, ale nedá sa na neho prejsť len tak, že si proste poviem "teraz mám pol hodiny čas, tak idem prejsť na Git".

To máš naprostou pravdu, já k tomu potřeboval nejmíň půl dne.

[Zdeněk Burda]

Když je něco dlouho používané, funguje to a používá to docela dost lidí, tak není snadné přejít na cokoliv jiného.

[pavlix]

Logicky.