Az utóbbi időben próbálok ismerkedni a különböző verziókezelő eszközökkel (pl. itt: http://hup.hu/node/90320 ), de némi olvasgatás és több verziókezelő kipróbálása után arra kellett rájönnöm, hogy a lényeg nem annyira magukban a verziókezelő eszközökben van, hanem az általuk és a felhasználó által megvalósított verziókezelési módszerekben/elvekben/stb.
Ilysemi pl. az is, hogy elég sok irodalom van pl. a projektek könyvtárstruktúráinak kialakításáról, verziószámozásról, stb. Ezek is érdekes dolgok, de többnyire általánosak. Amik jelenleg még jobban foglalkoztatnak, azok az "egyel alacsonyabbszintű" dolgok, amik már nem függetlenek a verziókezelő eszköztől.
Az egyik ilyen dolog a változtatások kezelése. Changesets (workflow tracking) vs. single file tracking (nem tudom magyarul mi a korrekt elnevezés rájuk). Nagyon leegyszerűsítve Git vs. SVN (vagy méginkább: CVS. Nyilván, nem lehet éles határt húzni a verziókezelők közé csak ennek alapján, mert valamilyen szinten mindegyikből kierőszakolható mindegyik módszer, de remélem azért érthető a megkülönböztetés)
Ezzel kapcsolatban a következő kérdések jutottak eszembe:
1.: Azt vettem észre, hogy ez a tulajdonság erősen "korrelál" azzal, hogy az adott verziókezelő elosztott vagy sem.
Az egyetlen kivétel talán csak az SVK nevű kezdeményezés ( http://en.wikipedia.org/wiki/SVK ). A kérdésem az, hogy az elosztott/nem elosztott működésből szükségszerűen adódik-e valami olyan következmény, ami az egyik vagy másik változtatáskezelési módszert megköveteli?
2.: Az elosztott működés bizonyos előnyeit (gyorsaság, adatbiztonság, stb.) teljesen érthetőnek tartom, de az már nem ennyire egyértelmű számomra, miért jó, hogy az elosztott rendszerek mind(?) changeset-oriented változtatáskezelést alkalmaznak. Kijelenthető-e, hogy a changeset-oriented módszer valamilyen módon általános előnyökkel bír, ill. emiatt egy meghatározó fejlődési iránynak tekinthető-e?
3.: Egy fejlesztési projektnél mik azok a szempontok (vannak-e ilyenek egyáltalán) amik alapján el lehet dönteni, hogy az adott projekt számára a changeset-oriented vagy a single file tracking módszer alkalmazása a célszerű?
4.: Mi a helyzet akkor, ha nem csak szöveges forrásfájlokat kell kezelni?
5.: Általában, előnyök, hátrányok?
Hozzászólások
Munkám során központosított, hobbiprojekteimnél pedig elosztott SCM-et használok. Semmilyen előnyt nem tudnék felhozni a központosított mellett a kezelhetőség szempontjából. Sokkal nehézkesebb. Több műveletet kell végrehajtani egy comit-hoz, nehezebb visszakövetni a változásokat, merge sokkal körülményesebb, lassabban reagál a rendszer, minden művelethez kommunikálni kell a távoli adatbázissal. Viszont gondolom információbiztonság szempontjából jobb a cégnek, ha nincs az egész archívum a fejlesztők gépén.
Az, hogy "nehezebb visszakövetni a változásokat", az miben nyilvánul meg?
Ha X fájlban változtattam, akkor X különböző fájlnak kell megnéznem a módosítását külön-külön, amihez X alkalommal le kell tölteni a központi archívumból a referencia verziót.
Értem. Szóval, te úgy érzed egyszerűbbnek, hogy a változtatást követed nyomon és nem a fájlokat.
Tudsz esetleg olyan esetet mondani, amikor mégis jobb lett volna valamiért a fájlt követni?
A másik oldalról: ha esetleg kifejezetten egy fájl történetére volt szükség, akkor annak a kezelése mindig problémamentes volt az elosztott rendszerrel?
Hát, elosztott rendszerrel még nem volt rá példa, hogy fájl történetére lett volna szükségem, de úgy nézem git-tel pl. nem probléma ezt lekérdezni.
Na, itt pl. pont a gitről írják azt, hogy ilyesmiben azért vannak problémái, ha jól értem.
"Currently Git does not support it very well. There is '--follow'
option for git-log, but it is more of a hack to have something
similar to what for example Subversion provides, than a full
solution. It works for simple histories, and might fail for more
complicated ones; it is not however fundamental limitation. On
can always use "git log --
"...
On the other hand single file history should be for developers
second-class citizen in VCS supporting changesets; full history
is _more_ than sum of single-file histories. "
Egyébként nem nagyon tudom magamban hova tenni ennek a szükségességét. Az én dolgaim pl. erősen fájl-orientáltak, egy-egy feature nem nagyon lépi át az őt megvalósító fájl határait. Ezért gondolom azt, hogy fontos lehet a fájlok önálló követése.
Úgy látom az átnevezett/áthelyezett fájlokról van szó. Ezekkel nincs tapasztalatom, de úgy tűnik a --follow működik.
Changesets vs single file témához egy kis kiegészítés:
Nálunk általában úgy néz ki a munkafolyamat, hogy redmine-ban van egy feladat és ahhoz kapcsolódóan születnek a commitok ennek megfelelően "refs #123: xyz" és/vagy "closes #123: xyz" jellegű logokkal (redmine figyeli a refs/closes #nnn stringeket a commit log mellett). Ilyenkor hozzákötődik egy redmine feladathoz. Van, hogy 1-1 feladathoz csak 1-2 commit születik (tipikusan hibajavítások), de olyan is van, hogy 10-15. (Több nem nagyon, mert ott már általában részfeladatokra bontás van). Ha vissza kell keresni valamit, sokszor inkább úgy néz ki, hogy megnézzük a feladathoz kapcsolódó revíziókat, emiatt inkább commit-csoportok a fontosabbak nálunk. És egyértelműen több fájl egy csoportban való kezelése a fontosabb nekünk.
4: nálunk ugyanúgy megy SVN-be bele.
----------------
Lvl86 Troll
"...emiatt inkább commit-csoportok a fontosabbak nálunk. És egyértelműen több fájl egy csoportban való kezelése a fontosabb nekünk."
Ezt értem a leírásod alapján. De én inkább olyan elveket, döntési szempontokat keresek most, amik miatt ez kialakult. Ez a ti esetetekben hogy volt? Vagy csak "így sikerült"?
Szerk.: ha jól értem akkor alapvetően a feladat-központúság volt az egyik ilyen szempont.
Ez tűnt eddig a leghasználhatóbbnak.
----------------
Lvl86 Troll
10 év kliens-szerver tapasztalat alapján: CVS
+1
Milyen indokok alapján választanál cvs-t svn helyett?
- nincs köze a bug-, és corruptware singleuser bdb-hez (igen tudom van fsfs is)
- fileonkénti verziókezelés
- checkoutolt verzió nem duplán foglalja a helyet teljesen feleslegesen, mint svn-nél az .svn könyvtárak miatt
$ cd libs
$ du -hs . .svn
686M .
344M .svn
Ellenben CVS-ben tok jol lehet mergelni, meg atnevezni dolgokat - mindketto egyszeru es problemamentes. Akarcsak a branch kezelese.
</sarcasm>
A gányolást és töketlenkedést jobb meghagyni a sourceforge.net projektjeinek.
Miert lenne a file atnevezes, vagy a brancheles (es annak parjakent, a merge) ganyolas?
Pont ezért váltottunk CVS-ről SVN-re. (addig mindenféle módosítás számokat irogattunk
az egyes file-okba, hogy vissza lehessen követni a changeset-eket.)
A git ebben is verhetetlen:
---
pontscho / fresh!mindworkz
"- nincs köze a bug-, és corruptware singleuser bdb-hez (igen tudom van fsfs is)"
Az svn-nek az fsfs a defaultja. Ma mar szerintem nagyon kevesen hasznalnak bdb backendet svn-hez.
--
Nem értem, az svnben van fájlonkénti verziókezelés vagy nem értem, hogy mit értesz ezalatt.
Minden további nélkül lehetnek különböző verziójú fájljaid a könyvtárban.
Tapasztalataim szerint a CVS alkalmatlan verziókezelésre.
Ebben egyetértünk, nem véletlenül menekülnek a projectek tőle.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Érdekes egy bogár lehetsz te.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
Ezeket érdemes elolvasni:
http://joelonsoftware.com/items/2010/03/17.html
http://hginit.com/top/00.html
Köszönöm, egyelőre az elsőt olvastam el.
"With distributed version control, the distributed part is actually not the most interesting part. The interesting part is that these systems think in terms of changes, not in terms of versions. That’s a very zen-like thing to say, I know. Traditional version control thinks: OK, I have version 1. And now I have version 2. And now I have version 3. And distributed version control thinks, I had nothing. And then I got these changes. And then I got these other changes."
Na, pontosan ezen pörgök most én is. Viszont a 3. kérdésemre nem ad választ (meg a többire sem nagyon). Az, hogy "SVN is baaad, mkayyy?" lehet, hogy igaz, de nem látom ebből megindokolva, hogy miért. Az indoklás pedig lehetne egyfajta válasz a 2. kérdésemre.
Szerk.:
Elolvastam a másodikat is. Sajnos nem válaszolja meg egyik kérdésemet sem. :( Tulajdonképpen az egyetlen újdonság számomra a következő volt:
By contrast, while we were working separately in Mercurial, Mercurial was busy keeping a series of changesets. And so, when we want to merge our code together, Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.
Ez segített megérteni, hogy changeset-oriented esetben miért működik jól a merge. De ettől még a kérdéseim nyitva maradtak.
"A kérdésem az, hogy az elosztott/nem elosztott működésből szükségszerűen adódik-e valami olyan következmény, ami az egyik vagy másik változtatáskezelési módszert megköveteli?"
Nem. Éppen te mutattál rá az SVK-val.
"miért jó, hogy az elosztott rendszerek mind(?) changeset-oriented változtatáskezelést alkalmaznak."
Miért ne? Mindkét tulajdonság jó külön-külön is.
"Kijelenthető-e, hogy a changeset-oriented módszer valamilyen módon általános előnyökkel bír, ill. emiatt egy meghatározó fejlődési iránynak tekinthető-e?"
Szerintem elég egyértelműen igen.
"Egy fejlesztési projektnél mik azok a szempontok (vannak-e ilyenek egyáltalán) amik alapján el lehet dönteni, hogy az adott projekt számára a changeset-oriented vagy a single file tracking módszer alkalmazása a célszerű?"
Ha csak kevés, egymással folyamatosan kommunikáló ember dolgozik egy programon, és annak is főleg jól elkülönített részein, akkor a merge triviális, és ezért a cvs/svn ma is megfelelően ellátja a a dolgokat. Viszont mihelyt sok ember dolgozik szétszórtan a nagyvilágban valami bonyolultabb dolgon, akkor a merge halálos lehet a cvs/svn-nel.
"Mi a helyzet akkor, ha nem csak szöveges forrásfájlokat kell kezelni?"
Semmi. Nem sok értelme van bináris fájlokat diff-elni, ezért tudtommal mindegyik ugyanúgy egyben eltárolja az ilyen fájlokat.
"Általában, előnyök, hátrányok?"
A cvs/svn-nek szerintem csak annyi előnye lehet, hogy ha már ismered, használod és tényleg megfelel az adott feladatra, akkor nem kell plusz energiákat pazarolnod a git/hg-re való átállásra.
egy igen jo osszefoglalo talalhato itt
___
info
A témát olvasva vetődött fel bennem a kérdés, hogy van-e hibrid megoldás? I.e. olyan, ami changeseteket is tárol, plusz még a fájlokat is verziózza. Szerintem kis overhead lenne, és így mindkét módszer előnyei megmaradnának.
Konkretan mi a file verziozas elonye?
Jobb verziokezelo rendszerekben (pl git :P) az esetek jelentos tobbsegeben vissza lehet kovetni egy file historyjat is, anelkul hogy kifejzetten az verziozva lenne. Ha valakinek eppen ez kell..
De igy sok ev tavlatabol, sok rendszert kiprobalva (cvs->svn->larch/tla->bzr->git; kozben mercurial es darcs probakeppen), arra jutottam, hogy a file szintu verziozas butasag es felesleges. Boven eleg, ha vissza tudom kovetni hogy adott file mely commitok alkalmaval modosult.
Igen, tulajdonképpen nekem arra tűnik csak hasznosnak, hogy egy fájl egymás utáni verziói közt tudok diffelni, erre meg az is jó, amit írtál. Viszont kényelmesebb lehet ezt úgy megtenni mondjuk, hogy diff 1.1 1.2 vagy diff 1.3 1.4, mert ez rövid és látszik, hogy egymást utáni verziókról van szó, mintsem diff 23252 23287, mert ez már nem annyira szemléletes, pedig lehet, hogy ez is egymás utáni verziót jelent egy adott fájlon.
"diff 23252 23287, mert ez már nem annyira szemléletes, pedig lehet, hogy ez is egymás utáni verziót jelent egy adott fájlon."
diff 23286 23287, vagy pl. gites jelöléssel: diff 23287^ 23287
Valoban, file verziozas nelkul picit tobbet kell esetleg gepelni. Ellenben "git log -- filenev" -bol secperc alatt kinezi az ember, hogy mi kell. Arrol nem beszelve, hogy a legtobb GUI/Editor interface/stb alapbol tamogatja, hogy diffet csinalj a file akarmelyik ket verzioja kozott, szepen osszekattogtatva is akar.
Normalis tagelesnel lehet a v1.1..v1.2 roviditeseket is alkalmazni (ha a tag elnevezesi konvencio az, hogy v${MAJOR}.${MINOR}. Persze, ez az egesz repot verziozza, de ez hasonlit a legjobban arra, amit szeretnel. Illetve van meg egy: a HEAD-hoz kepest meg lehet adni a revizio tavolsagot numerikusan (hirtelen nem tudom, hogyan).
--