HOVD 2008 - Kedvenc verziókezelő rendszer

Egyéb

bazaar
7% (43 szavazat)
codeville
0% (0 szavazat)
cvs
17% (110 szavazat)
darcs
1% (5 szavazat)
git
14% (95 szavazat)
gnu arch
2% (11 szavazat)
mercurial
2% (14 szavazat)
monotone
1% (4 szavazat)
subversion
57% (374 szavazat)
svk
0% (3 szavazat)
Összes szavazat: 659

( hrgy84 | 2008. 12. 01., h – 09:23 )

Git-re szavaztam, de +1 az svn-nek. Egyforman kezdem kedvelni oket, es nem tudok donteni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( gabor v | 2008. 12. 01., h – 09:46 )

Oszinten szolva nehez megerteni, hogy mi viszi ra az embereket a Subversion hasznalatara, talan azt latjak, hogy mindenki ezt hasznalja, akkor biztos jo, mast meg nem lattak meg soha....

Ha a git es a Subversion kozt kell valasztani, akkor van par nyomos erv az svn mellett:

Az svn Winblowson nagyreszt a TortoiseSVN-nek koszonheti a sikeret. Hol van barmi hasonlo git-hez?

Az Agile emberek nem szeretik branchelni a kodot. Viszont szeretik a kozponti repository-t, amire konnyen raizgul egy teszt automatizacio. Vallalati kornyezetben tehat a git egy erdekes technologia, mig az svn egy egyszeru megoldas.

Ha a git es a Subversion kozt kell valasztani, akkor van par nyomos erv az svn mellett:

Nem ezek kozul kell valasztani, vannak meg lehetosegek.

Az svn Winblowson nagyreszt a TortoiseSVN-nek koszonheti a sikeret. Hol van barmi hasonlo git-hez?

TortoiseBzr nem jo? Oszinten szolva en sohasem lattam....

Az Agile emberek nem szeretik branchelni a kodot. Viszont szeretik a kozponti repository-t, amire konnyen raizgul egy teszt automatizacio.

Senki sem tiltja meg, hogy legyen egy kozponti branch, azon futhatnak a kozponti tesztek is. De ettol meg a fejleszto laptopjan is lehet egy sajat branch, ha neki ugy tetszik. En szeretek sajat branchet hasznalni, mert abba az osszes apro valtozast be lehet kommittalni, es nincs olyan kovetelmeny, hogy mukodjon is a kod. Majd ha mukodik akkor megy a kozponti branchbe.

Senki sem tiltja meg, hogy legyen egy kozponti branch, azon futhatnak a kozponti tesztek is. De ettol meg a fejleszto laptopjan is lehet egy sajat branch, ha neki ugy tetszik. En szeretek sajat branchet hasznalni, mert abba az osszes apro valtozast be lehet kommittalni, es nincs olyan kovetelmeny, hogy mukodjon is a kod. Majd ha mukodik akkor megy a kozponti branchbe.

Én rutinszerűen használok SVN-ben is privát branchet. Mivel fejlesztés közben úgyis kell internet hozzáférés (WLAN vagy 3G, ha úton vagyok), nem zavar túlzottan, hogy fel kell tölteni a távoli szerverre a fájlokat.

Mindezek mellett nagyon szimpatikus pl. az Android CM rendszere, és ha még lesz hozzá egy-két dolog (pl. rendes Eclipse integráció + Hudson plugin), akkor más projektekbe is jó lehet.

Üdv,
Gergely

svn mkdir REPO_URL/users/useredneve

svn cp REPO_URL/trunk REPO_URL/users/useredneve/branchodneve

Mivel a VCS-ek egyik fő szerepe az együttműködés elősegítése, ezért általánosságban a "privát branch" nem azt jelenti, hogy csak te férsz hozzá, hanem azt, hogy a te személyedhez van rendelve, és ha valaki frissíti a fő branchot, akkor nem kerül be a privát branchokon lévő kód, kivéve, ha külön kéred.

Az adott VCS-től függ, hogy erre milyen technikai lehetőségek vannak. DVCS-ben tényleg tudsz olyat csinálni, hogy senki más ne lássa a privát branchodat. Ez azonban ritkán fontos use case a fejlesztés szempontjából.

Üdv,
Gergely

Nekem még sosem volt szükségem saját branchre. Kb. 30-an nyüstöljük u.a. a kódot, ami ráadásul nem túl jól strukturált, így igen gyakran matatunk azonos fájlban és azonos függvényben. Napi 1-3 update+commit/koponya mellett sem kell senkinek saját branch.

Megy a folyamatos integráció. Néha engem is meglep, de nem igen történik olyan, hogy valaki valami borzalmat rak fel, és ezért megállna az élet.

Bármennyire is hihetetlen, nem a merge-ölés viszi el az időnket, pár másodperc alatt megvagyunk vele. (Hála az svn-be integrálódó KDiff3-nak.)

Mi a kísérleti kódot egyszerűen #if-elni szoktuk. A flaget be- és kikapcsolva is fordítjuk, futtatjuk, aztán látjuk, hogy mit tett tönkre.

A gyakori commit miatt külön backupra sincs igazán szükség. De ha évente 1-szer mégis kell, akkor egyszerű fájlszintű (pl. working copy) másolással megoldjuk.

Egy százezer soros komplex kód teljes újraírásánál persze fájdalmas lehet a rengeteg flagelés, ilyenkor jól jöhet a branch. De ez már egy másik dolog, amin még a git sem tud segíteni.

Mit próbáljak ki? A 100000 sor újraírását, a git-et és/vagy a privát branchet?

A 100000 sort inkább nem, ugye megértitek :-)

A git-et majd akkor, ha el tudom fogadtatni Win alatti egérfarokrángatókkal meg rengeteg (kb. 100) managerrel.

A privát branchet látom más helyeken épp eleget. Van, hogy indokolt a használata, hiszen kísérleti kóddal kár teleszemetelni mindent. Ez sokban függ a kód és a változtatás jellegétől is. Nálunk általában nem szerencsés a branch, mert pl. valaminek az újraírásakor gyakran amúgy is meg kell maradnia a régi megoldásnak a régebbi termékeinkhez. Új fejlesztéskor meg legalább rögtön a helyére integrálódik minden. Ráadásul sok új funkció fejlesztése folyik egyszerre, amik gyakran hatnak egymásra, így nagyon fontos a mihamarabbi integráció. Ez utóbbiban sokat tud segiteni egy jó verziókezelő (git esetleg 1.5.x-es svn), de minek, ha könnyen megkerülhető amúgy is a probléma?

A git importalas nelkul is el tudja az svn-t kezelni, lehetseges az svn fatol fuggetlen is fejleszteni es a vegen kommittolni. Persze idonkent mergelni kell az eredeti repobol, de hat ez amugy is igy van. Probald ki, bajod nem lehet belole, ha valami kulon branchen teszed, akkor meg meg kart sem okozol. git svn --help.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nezd, nem ismered az ottani rendszert, nem tudhatod az ottani folyamatok menetet. Valoszinu hogy ok azert tettek a voksukat a subversion mellett, mert nekik az tokeletesen megfelel. Mivel regota hasznaljak, valoszinuleg beleintegralodott a munkafolyamataikba. Nem biztos, hogy egy jol mukodo rendszert erdemes atgondolas nelkul megbolygatni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Tökéletesen megfelel? Jól működő rendszer?

Ezek a való világban inkább "a legkevésbé rossz", illetve "úgy ahogy, de legalább működik" szoktak lenni.

De a branchektől függetlenül még mindig ott van a sebességbeli fölény, az index, a sokkal fejlettebb blame, bisect, stb.

Hat nem tudom, lehet hogy bennem van a hiba, de nekem a subversion egyaltalan nem volt rossz, nem volt olyan dolog benne, amire igenyem lett volna, megsem tudtam megvalositani. Arrol nem beszelve, hogy problemam szinte sosem volt vele, ellentetben a git-tel, amivel szenvedek eleg sokat.
Persze ez egy egyoldalu nezopont, de a tema termeszetenel fogva mas tapasztalatait nem tudom neked elmondani, csak a sajatomat.

S hogy miert probaltam ki mas verziokezelot, ha a svn annyira jo? Megmondom oszinten: kivancsisagbol. Kivancsi voltam, vajon csakugyan olyan jok-e a mostani megoldasok, mint amennyire hirdetik. Meg kell mondjam, nagyon vegyes az osszkep. Nem olyan rossz, de osszessegebe veve csalodtam az uj cuccokban. Ez lehet megintcsak az en hibam. Talan tul tokeletlen vagyok ezekhez a tokeletes rendszerekhez.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Talán mert a lehetőségeid (illetve azok hiánya) határozták meg az igényeidet?

Voltak branchek, de nem volt merge, nem lehetett a working copy-ban lévő változásoknak csak egy részét commitolni (illetve csak file szinten lehetett válogatni), nem lehetett review-olható history-t csinálni (vagy óriási commitok, vagy egy csomó szemét, későbbi hibajavításokkal, visszajátszott commitokkal, stb.). Ezeket leszámítva a Subversion végülis alapvetően jó, sőt, annak idején CVS-ről érkezve egyenesen megváltás volt. Bár a BerkeleyDB egyszer beintett, de szerencsénk (értsd: backup) volt.

Mint ahogy Subversionről érkezve a git is megváltás volt. Régen sose volt explicit igényem bisect-re, rebase-re, stash-re, blame -w és/vagy -C-re, mert sose gondoltam rá, hogy olyat lehetne. Most úgy gondolom, hogy amiben ezek nincsenek meg, az egyszerűen alkalmatlan verziókezelésre (legalábbis abban az értelemben, amit így 2008 vége felé értünk ez alatt).
Tökéletes? Dehogyis, rengeteget lehetne még csiszolni rajta.

Kíváncsi vagyok, hogy mi lesz és mit hoz majd a következő (;

Az SVN-nek nagy előnye:
* Nagyon jó multiplatform támogatás
* Jó GUI eszközök "menedzsereknek is"
* Nagyon jó integráció gyakorlatilag az összes fontos IDE-hez.
* A fejlesztők jó eséllyel ismerik, tehát nem kell őket betanítani. (Már kis projektekben is jelentős megtakarítás, nagy projektben pedig óriási költség egy új verziókezelő bevezetése)

SVN hátrányai:
* Rossz merge tracking
* Rossz rename / refactoring support

Ezeknek a hátrányoknak a hatásait jól megválasztott felhasználási mintákkal és egy tapasztalt CM felelőssel lehet annyira csökkenteni, hogy a napi használatot ne befolyásolja.

Egy átlagos fejlesztőkből álló projektnek én az SVN-t ajánlanám. Speciális környezetben természetesen elosztott VCS-ek is jól működhetnek, lásd Linux kernel, Android, Ubuntu vagy OpenEmbedded. Ezek azonban nem átlagos "van 3-6 hónapunk kifejleszteni egy weboldalt / alkalmazást" projektek, ahol egy létező csapattal kell megoldanod a feladatot, és korlátos időt fordíthatsz továbbképzésre.

Üdv,
Gergely

A Subversion talan olyasmi, mint prog. nyelvek kozt a PHP. Kicsi, egyszeru, konnyu a hasznalata. Sokkal konnyebben tanitasz be vkit, aki meg sosem hasznalt semmilyen VCS-t subversionre, mint pl. git-re vagy akarmi masra.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( uid_15426 | 2008. 12. 01., h – 22:53 )

Perforce. Nagyvallalati kornyezetben meg sem kozeliti semmi. Sajnalom, hogy kimaradt.

while (!sleep) sheep++;