Apache Subversion 1.8

Szerszám

Az Apache Software Foundation bejelentette az Apache Subversion verziókezelő rendszer 1.8-as kiadását. Részletek a bejelentésben és a kiadási megjegyzésekben.

( syntern | 2013. 06. 19., sze – 18:06 )

Cool, már az 1.7-el sem volt sok panaszom, de az 1.8 kifejezetten jó iránynak tűnik. Már csak egy szebb webes frontend kellene hozzá... (csak a felhasználói élmény kedvéért).

( transitive | 2013. 06. 20., cs – 08:38 )

Használ még ma vki svn-t vagy már mindenki beállt a sorba és gitet használ?

(én amúgy szeretem az svn-t)

Imho meg mindig sokan hasznaljak. En is szerettem anno, 1.7 mar jo iranyba mozditotta es kicsit behozta a lemaradasat a tobbi rendszertol. Nagyon sok mindenre es konnyen hasznalhato rendszer meg ha meg is vannak a maga gyengesegei. Bar teny hogy divat lett szidni, amit akar lehet is ha valaki tudja mirol beszel de a legtobben csak hivokent mantraznak egy valahol hallott/olvasott szozatot hogy mennyivel szarabb mint az amit aktualisn hasznalnak de leginkabb meg csak tanulnak.
Btw mi is mar HG-t hasznalunk (elejen hasznaltunk Git-et is de nem valt be).

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

Gittel sok gebasz lehet plane ha tenyleg tobben dolgoztok adott projecten es szerettek branchelni es reviewzni brancheket, de az alapjat nem nagy wasistdas elsajatitani.
HG egy amolyan konnyen tanulhato es hasznalhato GIT ujragondolas. Megtanulni az alapjait SVN utan sztem kb fel ora.

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

Azt figyeltem meg, hogy az örökölt projekteket, ha azok svn -ben vannak, nem igyekeznek fénysebességgel gitre migrálni, de az újakat nagyrészt abban inditják.
Én a magam részéről napi szinten ~2,5 éve gitet használok (újabban pár spéci eszközzel mint a repo vagy a gerrit), igy összehasonlitási alapom nincs, de ha elveszteném pl. a DVCS -ből fakadó ficsőröket, biztos hogy sikitanék.

--
http://developersideas.blogspot.hu/
http://neurogadget.com/

Tiszta, rendezett origin repó, ami nem tartalmaz topic brancheket, csak letisztázott mastert, amin csak a megválogatott, letisztázott commitok vannak (ettől függetlenül a senior / release engineer nyugodtan kreálhat release brancheket stb).
Nem számit hogy kinek mennyire van összeszemetelve a helyi repója, nyugodtan fejlesztgetheti az akár tucatnyi helyi branchét, senkit sem fog zavarni.
Be lehet iktatni egy köztes repót review -ra, tesztelésre (pl. a gerrit személyében). Ide nyugodtan fel lehet lövöldözni a mindenféle félkész-nembiztoshogyjó-nembiztoshogykell commitjait, amiből gondos válogatás után átcsúszhatnak originbe a tényleg kellő commitok.
Ha a develnek több gépe is van, akkor nyugodtan küldözgetheti köztük a commitokat, vagy fenntarthat teljesen egyedi brancheket, mert mondjuk otthon mással szokott foglalkozni mint bent.
És ezt lehetne mélyiteni bármeddig.

--
http://developersideas.blogspot.hu/
http://neurogadget.com/

Ok, köszi, Nevergone-nak is.

Utánaolvasva találtam egy jó kis blogbejegyzést; írja, hogy érdemes megkülönböztetni nyilvános és a privát branch-eket; hasznos lehet másnak is.

Viszont látok elosztott jellegből adódó hátrányokat is. Pl. nincs lock (bár ritkán kell). A fontosabb, ha egy branch-be bekerült valami szemét, amit mások már átvettek, azt nem nagyon lehet törölni. Rebase-zel lehet trükközni, de nem tudom, mit fog szólni a rendszer a többieknél.

Szerk: nyilván ésszel kell használni, akkor nem kerül bele szemét, főleg aki a mastert piszkálja; ez meg mindegyik verziókezelő használatának alapfeltétele. :)

Nalam a master az mindig production branch. Mivel alapvetoen opensource cuccokat fejlesztek, a githubon a user a master branchet latja meg eloszor, klonozaskor azt kapja meg elsonek, tehat kiemelten fontos, hogy azon olyan kod legyen, ami stabil es szenne van tesztelve. Minden fejlesztes egy kulon (esetenkent publikus, de sokszor nem) develop branchen zajlik, ebbol mergelek a masterre.

Kicsit bovebben itt irok a metodusrol, amit kovetek. Persze, ez se szentiras, el lehet terni tole, de ez nekem bevalt.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Sima conflict meg nem is akkora szopas, tree-conflicttal viszont mar el lehet jatszadozni.
Amivel nekem a legtobb problemam volt az a brancheles. Alap egyszeru branchnel nincs gondja, de ha csinaltal egy branchet egy branchbol es az osbranchet visszamergelted akkor halotta valt a gyermekbranched is es kvazi ujra letre kellett hoznod a trunkbol es patch-el befrissiteni

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

Én korábban nagyon kedveltem a hg branchelési modelljét, mert jól stage-elhető volt, hogy honnan hova merge-elt valaki. Azóta eltelt kis idő, láttam néhány érdekes repo-kialakítást. A legjobb módszernek most azt tartom, ha olyan struktúrát alakít ki valaki, ahol nincs szükség branchelésre. Egy csomó előnye van:
- nincs semmi szívás a brancheléssel illetve a merge-ökkel (ezen a ponton kb. meg is szűnnek a lényeges külünbségek a verziókezelők között, mindegyik pont ugyanolyan alkalmas erre)
- könnyebb azonosítani és menet közben refactorolni az újrahasznosítható kódokat
- runtime flag alapján lehet ki/be-kapcsolni az új kódot, csökken a változtatás kockázata
- webes alkalmazásnál könnyen lehet éles felhasználókon A/B tesztelni a párhuzamos kódbázist

En gitben kifejezetten sok branchet hasznalok, foleg olyan projekten, amit egyedul tolok. Nem mindig szeretem ugyanazt a feature-t tolni, neha kell a valtas, ilyenkor elviszem az aktualisat egy mukodo allapotba, becommitolom, es valtok. Igy nem annyira monoton.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Brancheles nelkul nem tudom elkepezlni hogy mukodhetne barmilyen nagyobb project.
A legfontosabb ok egyszeruen a szeparalas. Muszaj kulon tartani a meg be nem fejezett es tobb szmpontbol el nem fogadott kodokat az eles vonaltol.
Az amit te mondasz hogy kodbol kapcsolgatod ki es be a kulonbozo fejleszteseket meg a legtobb esetben uj featureknel sem mukodne nem hogy feature modositasnal netan refaktoralasnal, egyszeruen annyi hibalehetoseget vinne a renszerbe es annyir karbantarthatatlanna tenne az egeszet hogy eszembe se jutna megtenni. Pedig most meg kis csapattal dolgozom. De ha barmilyen agilis metodikaban dolgozol mar bukik az ugy brancheles nelkul. Megadjak neked hogy a kovetkezo sprintben x featuret kell lefejlesztened de a sprint vegen dontik el melyikek lesznek elesitve, es mindekozben az eles rendszert is javitanod kell szukseg eseten. Ilyenkor van az hogy kell egy sprint branch es minden featurenek egy branch.

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

Dolgozik nalunk egy fejleszto, aki pont igy csinalja, hogy kodbol kapcsolgatja a dolgokat ki s be, hat van is problema neha azokkal a cuccokkal. Es ez csak az egyik. Mondjuk, orokolt kod, szoval ez talan mentseg, de mas cuccoknal is igy csinalja, szoval... szerintem ez igy gaz... pedig nalunk semmifele agilitas nincs.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Termeszetesen, mint minden mast is. De ez tenyleg brual extrem pelda.
HA azt mondom hogy egy atlag projetnel aminek a fejlesztesek mondjuk belovik 4 hetes sprintekre es dolgozik rajta vagy 10 fejleszto akkor van egy sprint branched es maximum kb 5 feature branched 4 hetente.
Anno vezettem nagy fejelszto csapatot ami 5 kissebb fejleszto csapatbol allt, akkor SVN-t hasznaltunk es tenyleg elertuk a hatarait. De a legtobb problemat ott sem az SVN okozta hanem a felso management. Azzal egyszeruen egy tool es egy fejleszto sem tud mit kezdeni amikor a felsovezetes nem tudja eldonteni mit akar es sorozatosan felbehagyatja a fejleszteseket mert eppen talalt egy fontosabb featuret amit azonnal el kell kezdeni ugyanakkor nem szeretne kidobni a regi felbehagyottakat. Ekkor jon az hogy egy ideig probalja az ember karbantartani a sok regi branchet, majd mikor amr tenyleg senki nem birja akkor kiborul a bili es lehet torolgetni oket. Egyebkent az altalad linkeltnek en csak az ellenkezojet lattam eddig. Valamiert a legtobb fejleszto idegenkedik a branchek hasznalatatol es ugy erzi az ot rendkivuli modon belassitja, ezert siman beletolja a fo fejlesztesi agba a teszteletlen es nem elfogadott dolgait.
Tenyleg siman lehetne tartani kiseloadast a best-practice-k mellett a worst-practice -ekrol is.

------------------
http://www.youtube.com/watch?v=xnJwT_30p6k

? ennek mi köze bármihez is?

Ha cégvezető vagy / otthonra magadnak lövöd be, akkor az egyéb ficsőrlista mellett számításba veszed azt is, hogy mennyibe lesz a dolgozók képzése / saját idődből mennyit fog ellopni.
Szigorúan az általános szálnál maradva, hogy miért egy program tulajdonsága a kezelhetősége, és a negatív szokásokra való rávezetőképessége.

Puppy linux felhasználó

Nullarol kepezni mindig draga, a meglevo tudas az, ami szamit.

Nalunk peldaul mindegy volt, hogy mit vezetunk be, gitet vagy svn-t, mert a cegnel semmit nem ismertek, nem is hasznaltak. Datumozott mappakban voltak a kodok. Az elozo rendszergazda vegigverte az SVN-t, mert ez volt az egyetlen, amihez ertett, es tudott segiteni az elsajatitasaban, de ha a Githez ertett volna, akkor az lett volna bevezetve. Ezzel egyutt 3 ev utan en mutattam meg par fejlesztonek, hogy lehet az svn-ben egyaltalan brancheket csinalni, allitom, hogy az up/ci/co svn parancsokon kivul semmi egyebet nem hasznaltak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Simán lehet rossz példákat felhozni mindenre, de ahol ez össze van rakva, ott remekül működik.

Pl. a Google-nél nem kevés nagy projekt van, és branchelés nélkül, (szerver- és kliens oldalon is külön megvalósított) feature flagekkel működnek.
(emlékszem egy publikus Google blog posztra ezzel kapcsolatban, de most hirtelen nem jön elő)

Másik példa: a Flickr néhány éve ugyanezt írta magukról.

Harmadik példa a Facebooktól. A "Decouple pushes from feature activation" rész remekül megvilágítja a mögötte álló előnyöket, és hogy miért jobb ez mint a branchelés.

Az Androidot biztos, hogy nagyon erősen topic-branch alapon fejlesztik, hiszen tőlük származik a gerrit és a repo nevű git wrapper script is, ami a gerrit -es workflow támogatására készült. Ha egy projektet repo -val szedsz le, akkor abban a repóban nem is lesz lokális master, kizárólag tracker brancheket lehet csinálni, amelyek tipikusan az origin/mastert követik. Furán hangozhat, de nincs vele különösebb baj.

--
http://developersideas.blogspot.hu/
http://neurogadget.com/

A Google elég nagy cég, minden csapat elég nagy mozgásteret kap ahhoz, hogy hogyan és mit csinál. Az Android eredetileg a Google-ön kívül indult, szerintem csak megörökölték a struktúrát és nem kényszerítettek rájuk semmi változtatást.

Nem azt mondom, hogy nem lehet brancheket használni vagy hogy nincs értelme, hanem csak annyit, hogy tökéletesen meg lehet lenni anélkül is, és van helye és előnye egy más struktúrának is. A Google egy csomó projektje vagy az említett további példák is ezt támasztják alá. Ettől még használj boldogan branchinget, csak tudd, hogy nincs egyetlen, kizárólagosan kimondható, über-választás, hanem van több alternatíva, attól függően, hogy mi az adott környezetben az igény.

Én azt szoktam mondani, hogy ahol nincs túl sok kapacitás a fejlesztők képzésére (tanulják a git rejtelmeit) vagy nem akarnak túl nagy autonómiát adni a fejlesztőnek, oda az SVN teljesen megfelelő. Egyszerű, mint a faék, Visual Studiohoz van plugin, aki nem TFS-párti, annak az SVN egy kézenfekvő megoldás.

Fuszenecker_Róbert