ClearCase szerű verziókövető

Programozás - kezdő

Elsősorban azokat kérdezem, akik használtak már Rational ClearCase-t, hogy melyik opensource verziókövető áll ehhez a legközelebb?
Olyen dolgokra gondoltam, hogy: CC-szerű branch kezelés, minden elem külön verzióval, és lehessen view-okat deklarálni benne.
Kérlek csak olyan írjon, aki tudja mire gondolok ezek alatt.

  • 2590 megtekintés

( xbit | 2010. 03. 29., h – 19:45 )

en hasznalok CC-t, tudom mirol beszelsz, eppen ezert kerdem, miert szeretnel ilyet? szerintem a CC felett elegge eljart az ido, feleslegesen bonyolult es okat lehet benne hibazni...
zsolt

( kisg v | 2010. 03. 29., h – 20:32 )

Szia,

Szintén használtam ClearCase-t, voltam CM Team vezető 4 országban 5 telephelyen folyó replikált CC-t használó projektben, úgyhogy tudom miről beszélsz.

Konkrétan miért igényled ezeket a funkciókat?

A mai elterjedt open-source SCM-ek mind a changeset alapú működést próbálják követni, ha használtál UCM-et, akkor onnan ismerős lehet a fogalom.

A viewk definiálása helyett open-source SCM-ekben branchokat csinálunk. Gyakorlatilag minden elterjedt SCM-ben (Subversion, Git ... stb.) nagyon olcsó művelet a branchok készítése az egész forrásfára.
A mergelés sem probléma (az elosztott verziókövetők mint Git, Mercurial vagy Bazaar ebben általában jobbak, cserébe SVN-nek jobb az IDE integrációja mindenféle Merge GUI-val), tehát nem jelent gondot az, hogy összeállíts egy olyan branchot, amit ClearCase-ben View-kkal tudtál egyszerűen elérni.

Hasonló a helyzet a labelezéssel: ClearCase egy nagyobb projekten akár egy órát ellabelezgetett anno, pl. SVN-ben konstans idejű művelet, ha már becsekkelt revíziót labelezel (taggelsz), és a working copy labelezése se tart sokáig (hálózati kapcsolattól függ, nekem <1 perc szokott lenni).

Az egyetlen dolog ami szerintem hasznos volt CC-ben, az a dinamikus viewk, de az is inkább dokumentumtároláshoz / kezeléshez volt jó, mintsem a fejlesztéshez, legalábbis a mi projektméretünkben (mobiltelefon fejlesztés).

Üdv,
Gergely

Haliho

Ami az SVN-ben igazán zavar az az "együttverziózódás". Sokkal logikusabbnak tűnik, hogy minden file-on külön verzió van értelmezve, így ha egyik file-ból kell kettővel régebbi, akkor elég $version-2 -t nézni rajta. SVN-ben hogyan kezelődnek a branch-ek (nemigazán használtam ezt a funkcióját még)? Külön?
Azért kérdezem, mert kényelmes volt egyszer ráhuzni egy label-t az egész vobra, aztán onnan külön branch - mondjuk maintenance céllal - és az előremerge-elés (egy branch-ból a main latest-re) is egész könnyű és logikus folyamat CC-ben. Dinamikus view-okat CC-ben sem használok, mert ubuntu alá az nem működik benne, az nem kell.

"A herceg én vagyok."

A SVN-ben fajlonkent van ertelmezve a verziozodas, de nyilvan az svn ls -r123 az 123-as verzioban ervenyes listat adja, nem csak azt a 2-3 fajlt, ami akkoriban letezett. Ettol meg a fajlok kulon-kulon verziozodnak.

A brancheles/tageles svn-nel gyakorlatilag copy muvelet, a tags/branches mappaba csinalsz egy masolatot a trunkrol svn cp-vel, utana a tag is kulon branch. De ez a git-nel is igy van.

Ha ram hallgatsz, kiprobalod a gitet es vagy a mercurial-t. Sokkal jobb az SVN-nel, mert a brancheles/tageles majdnem atomi muvelet, egy pillanat alatt megvan. Git-nel (ezt ismerem) a mergeles egesz jo, de lehetoseg van nagyon sok extra muveletre, egy konkret changeset applikalasara/eldobasara, kommitok osszeolvasztasara, stb.
Cserebe minden nagyobb valtozas utan kell nyomni egy push-t, amivel szinkronizalsz a halozaton levo repo-val (gyak. biztonsagi masolat).
-- 


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

A SVN-ben fajlonkent van ertelmezve a verziozodas, de nyilvan az svn ls -r123 az 123-as verzioban ervenyes listat adja, nem csak azt a 2-3 fajlt, ami akkoriban letezett. Ettol meg a fajlok kulon-kulon verziozodnak.
Ez pont fordítva van. Minden commit egy revision lesz, és amikor elkéred az svn ls -r 123 FileNeve -vel, akkor megnézi, hogy az adott fájlra melyik volt az aktuális revízió (pl. 106) és azt adja vissza. Ha kérsz egy svn log-ot egy fájlra, akkor ott is a revizió listán megy végig, és csak azok szerepelnek, amelyekben volt módosítás az adott fájlon.

Sokkal jobb az SVN-nel, mert a brancheles/tageles majdnem atomi muvelet, egy pillanat alatt megvan.
A branch / tag SVN-ben is atomi művelet, ha már becsekkelt revíziót másolsz. Ha working copyból, akkor értelemszerűen O(working copyban committolatlan változások mérete) a költség.

A Git / egyéb elosztott verziókezelők jók, ha (1) nem gond ha sokszor parancssorba kell nyúlni és nincs rendes IDE integráció, (2) ha forráskódot / szöveget akarsz verziózni.
Dokumentumok tárolására az SVN sokkal jobb:
- Windows userek kezébe is oda lehet adni
- Ha nagyon nem akarnak verziózást (csak az IT), akkor még mindig ott a WebDAV + autoversioning
- Nem kell letölteni 800 reviziót a méretes doksikból, igy a working copy mérete jóval kisebb.

SVN esetén ClearCase felől érkezve a felhasználói élmény jobban fog hasonlítani (központi repo, lehet lock - modify - unlock módban használni, ... stb.)

Azt nem tudjuk, hogy ez egy személyes projekt, vagy pl. ClearCase licencköltségen szeretne egy cég spórolni. Ha személyes, akkor persze lehet kisérletezni mindennel, de ha céges, akkor egy CC-re beállt kultúrájú csapatot egyből elosztott verziókezelőre átrakni minimum kockázatos. Ha megvan az SVN átállás, a hardcore fejlesztők nyomhatják git-svn-nel és egyéb jópofa megoldásokkal, de az átlag fejlesztő sokkal hamarabb lesz produktív SVN-en.

Üdv,
Gergely

"Ami az SVN-ben igazán zavar az az "együttverziózódás". Sokkal logikusabbnak tűnik, hogy minden file-on külön verzió van értelmezve, így ha egyik file-ból kell kettővel régebbi, akkor elég $version-2 -t nézni rajta."

A való világban egy projekt több file-ból áll, és ezek file-ok összefüggenek, ezért ez a minden file-nak külön verziója van több, mint logikátlan.

Ami az SVN-ben igazán zavar az az "együttverziózódás". Sokkal logikusabbnak tűnik, hogy minden file-on külön verzió van értelmezve, így ha egyik file-ból kell kettővel régebbi, akkor elég $version-2 -t nézni rajta.

Ezt megteheted SVN-ben is: svn update -r <revizioszam> Fileneve

Ez az aktuális working copydban átállítja. Ha állandóra kell, akkor pedig csinálsz egy branchot a working copydból:
svn cp /workingcopyd/patha https://server/repo/users/useredneve/privatebranch
svn switch https://server/repo/users/useredneve/privatebranch

Elvileg lehet csak egyes részeit switchelni a working copynak különböző branchokra, de nekem ez még sosem kellett.

SVN-ben hogyan kezelődnek a branch-ek (nemigazán használtam ezt a funkcióját még)? Külön?

SVN-ben a branchok és tagek ugyanúgy könyvtárak. Ez elég speciális megoldás, más verziókezelőt nem nagyon ismerek ami így csinálná.

Van egy speciális művelet, a copy, ami verziózottan másol. Ezzel csinálod a branchokat és a tageket is.

Emiatt van egy konvenció, hogy hogyan nevezik el a könyvtárakat:

/trunk -> ez a main branch (trunk HEAD = main LATEST)
/branches -> ide tesszük a branchokat
/tags -> ide tesszük a tageket
/users/$user -> ez az én saját konvencióm, ide kerülnek az egyes fejlesztők privát branchai / tagjei, ha szükségük van rá. Pl. tudsz úgy backupot csinálni a working copyd aktuális állapotáról, ahogy fentebb mutattam.

Branch gyártás:
svn cp http://server/repo/trunk http://server/repo/branches/1.0-stable

Az igy lemásolt könyvtár tudni fogja, hogy eredetileg /trunk volt, és hányas revízióból lett másolva. Ezt az infót az SVN használja pl. mergelésnél akár előre mergelsz a trunk-ra, akár vissza a stable-re.

Tag (=Label) gyártás ugyanígy megy, csak azt létrehozás után nem módosítjuk. (Ezt lehet mindenféle szerveroldali hookkal is biztosítani, ha muszáj, de nem szokott rá szükség lenni.

A Subclipse nevű Eclipse pluginben a Merge GUI-nak van olyan módja, ahol a fontosabb feladatok (feature branch újraintegrálás trunkra, feature branch frissítés trunkról ... stb.) külön támogatva vannak. Nyilván ugyanezeket a parancsokat ki lehet adni CLI-ben is, de sokszor a GUI kényelmesebb.

Érdemes átfutni a hivatalos Subversion könyvet: http://svnbook.red-bean.com
Szerintem nagyon jól le vannak benne írva a dolgok. Pl. vendor branchok kezelése ... stb.

Üdv,
Gergely

( ha1dfo | 2010. 03. 30., k – 12:53 )

Köszönöm szépen a hozzászólásokat, most már nagyjából fogalmam van a dolgokról, hogy tudjak mérlegelni.
Ahol dolgozom, ott kb 100an használunk 2 VOB-ot, linuxot és javas applikaciot fejlesztünk. Ott az SVN-re áttállás emlegetése a legcsúnyább rémképeket hozza elő valamiért az emberekből, főleg azokból akik már használták. Szóval itt fel sem merül ez a kérdés. Megaztán kifizeti a cég a licenceket, az se para nekem :-).
A kérdést leginkább a saját kisebb projektjeim miatt tettem fel, pár megás forrás, 2-3 fejlesztő, szóval lesz mivel kísérletezni.
Mivel nem a hagyományos hardcore unixos vim+gdb kombóval fejlesztő vagyok, ezért mindenképp olyanra van szükség, amihez van használható eclipse plugin. Nem nagyon kívánok vesződni vele túl sokat még parancssorban is (+1 az SVNhez).

"A herceg én vagyok."

Naja, lassan...
Egyelőre nincs Java-ban megfelelő merge implementáció, ezért egyáltalán nincsenek olyan advanced git feature-ök, amik arra épülnek, pl. rebase. De egyébként el lehet lenni vele, mert a legtöbb alap dolgot már régóta tudja. Viszont a klikkolva diff nézéshez illetve a diff nézetben a két verzió egymás mellett ábrázolásához valahogy nem bírok hozzászokni.

SVN-hez két Eclipse plugin is van: Subclipse és Subversive. Mindkettő stabil, szerintem ízlés kérdése, hogy ki melyiket kedveli. Nekem a Subclipse jött be jobban.

Cégnél: Ha annak idején (2005-6) már lett volna rendesen replikálható SVN, mint most az 1.6-ban, biztos hogy nem ClearCase alapon csináltuk volna meg. Egy ilyen átállásnál persze mindig az emberi tényező a legfontosabb.
A probléma az volt, hogy egyes telephelyeknek elég rossz volt a sávszélességük, ezért az 1 db központi SVN szerver nem igazán működött volna.
Külön vicces volt ClearCase-nél is, hogy amig nem volt náluk helyi replica, kb. 10-15 óra volt egy view legyártása.

Nem állítom, hogy az SVN tökéletes, én pl. mergeléskor a directory conflictok feloldásánál szoktam emlegetni a fejlesztőket mindenféle kontextusban, de az átlag fejlesztő számára nagyon egyszerű. Kb. azt a szerepet tölti be, mint a CVS 10 éve: Vannak szebbek-jobbak nála, de annyira nem lősz mellé, ha ezt választod.

Üdv,
Gergely

Szvsz SVN-t érdemes használni (ha csak a produktivitás számit) akkor, ha nincs, vagy minimális a branchelés. 2-3 fővel ez kb. definició szerint így van (és erre törekedni is kell, branchet csak ha muszáj), kis csapatoknak én mindenképpen az SVN-t ajánlanám. Minden más esetben Git vagy Mercurial, de számolni kell azzal, hogy nagyobb lesz a verziókezelési overhead ezekkel az eszközökkel.

Ha a betanulási faktor is számit, akkor mindenképpen nagyobb kihívás, és ezért érdekesebb valamilyen elosztott verziókezelőt megtanulni.

Miért ne? Megtehetem, olyan verziókezelő rendszert használok, ami a branchelést-mergelést triviálissá teszi. Másrészt vannak dolgok, amik függetlenek attól, hogy hányan dolgoznak egy projekten, pl. release management karbantartási és fejlesztői ágai.

Ismétlem: a release management nem függ a projekten dolgozó emberek számától.
Vannak "hagyományos" usereim, akik egy megbízhatóan működő programra vágynak, és szerencsémre vannak kísérletezőbb kedvű usereim is, akik a legújabb feature-ökért és az azokba való beleszólásért cserébe nem bánják, ha a program időnként hülyeséget ír ki, neadjisten megdeglik. Előbbiek kapják a stabil branch-et, bugfixekkel, utóbbiak meg a devel branch-et, új, adott esetben akár work in progress feature-ökkel és a bugfixekkel. Az teljesen lényegtelen, hogy magát a kódot hányan írják (ill. írom).

Hagyományos értelemben vett automatizált continuous integration nincs, plána nem VCS-mel integrálva (btw, git-hez van egyáltalán vmiféle CI tool?); bár push előtt többnyire for ciklusban lefuttatom a testsuite-ot az új commitokra.

Azért az nem igaz, hogy nem lehet branchokat használni SVN-ben. A release-, feature- és vendor branchek kezelésére jól működő folyamatok vannak.
Ami tény, hogy a task szintű branchek használata sokkal egyszerűbb Gitben, ráadásul nem szemeteled össze a commitokkal a nyilvános repositoryt.
Ha ez a szemetelés nem probléma, akkor ugyanolyan egyszerű SVN-ben privát branchokat használni, mint Gitben. A mergelés, bár szeretik szidni, használható szintű. Mint fentebb is írtam, vannak benne kényelmetlen megoldások, de ettől még egy vállalható alternatíva.

Az pedig teljesen projektfüggő, hogy szükség van-e task szintű branchok használatára, vagy a trunk / main branch kellően stabil marad akkor is, ha mindenki arra dolgozik.

Üdv,
Gergely

"Azért az nem igaz, hogy nem lehet branchokat használni SVN-ben."

Tudom, ezért nem is mondtam ilyet.

"A mergelés, bár szeretik szidni, használható szintű."

Ez nézőpont kérdése. A Git-beli (és talán Mercurial is?), rerere-vel támogatott, átnevezéseket kezelő 3-way és/vagy rekurzív merge-től nagyon messze van; erre vonatkozott a "triviálissá teszi" az előző hozzászólásban.

Kiserletezgetni sokkal jobb kulon branch-ben, egyszeruen azert, mert barmikor felreteheted vagy eldobhatod. Illetve egyedul is erdemes lehet feature-onkent kulon agba dolgozni, es csak a kesz cuccot betolni a trunk-ba.

Ugyanigy az, hogy kell-e karbantartasi ag, sem attol fugg, hogy hanyan dolgoznak egyutt (szerk: ja igen, pont ezt irtak mar), hanem hogy hany ugyfelnek hany verzio ment ki. Ha beesik egy bugfix, az csak akkor mehet a trunkba, ha jellemzoen onnan megy az osszes release.

Már miért ne lenne ilyen? Egy fejlesztő esetén is bőven megéri.
Sokkal egyszerűbb egy balul sikerült feature-höz tartozó branchet törölni, mint egy "mindent a trunk-ba" munkafolyamat esetén kimazsolázgatni, hogy melyik commitok tartoznak a törlendő feature-höz, majd revertelni őket.

Miért nem? Volt projektemen is már csak egy ember dolgozik (meg néha én, bár most lehet lesz rajta még valaki, mert megint lenne vele munka), mégis van több águnk, egy karbantartásra, egy fejlesztésre (trunk) valamint van egy külön ág, ahova egy másik, nagyobb fejlesztés megy majd, ha elfogadják.

Korábban is volt már olyan, hogy egy-egy nagyobb funkció fejlesztéséhez (pl. régi lecseréléséhez) csináltunk egy feature branch-t, hogy a trunkot zavartalanul tudjuk fejleszteni/karban tartani azalatt pár hét-hónap idő alatt, mialatt elkészült a másik funkció.

----------------
Lvl86 Troll

( amagda | 2010. 03. 30., k – 18:15 )

Szerintem maradj a clearcase-nel, nincs erdemi opensource-os parja.

Komolyan érdekel, hogy milyen olyan feature-ei vannak szerinted ClearCase-nek, ami nem váltható ki más verziókezelőkkel.

A kereskedelmi VCS-ek közül ClearCase-zel, Continuus / CM Synergy-vel és StarTeam-mel foglalkoztam.

Az tény, hogy ezek közül a ClearCase a legjobb, és vannak papíron jól hangzó funkciói (pl. object model, view koncepció, derived objects, VOB replikáció ... stb.), de gyakorlati felhasználás során ezek számunkra nem jelentettek előnyt az open-source megoldásokkal szemben.

Üdv,
Gergely

Az tudja valaki, hogy hogyan lehet ésszerűen párhzamos variánsokat kezelni Synergy-vel, és mindezt úgy, hogy a build manager nem hülyül bele? Branch-elést nem támogat a Synergy, és mondanom sem kell, hogy a kód nem 100% CBD kompatibilis, hogy egyszerűen tovább dekomponálni lehetne. Ötlet, azon kívül hogy váltsak ClearCase-re (svn-re, Mercurial-ra, stb.)? :-)

Köszi,
Attila

( ha1dfo | 2010. 03. 31., sze – 16:30 )

Na még kérdés: Az svn-ben ugyanúgy működik a checkout/checkin? (checkoutnál lockolódik a file, checkin-nél kerül rá új verzió.) Az svn commit-nak mi a clearcase megfelelője? Vagy az csak ilyen batch művelet könnyítő?

"A herceg én vagyok."

SVN-ben a checkout csak checkoutol, de alapból szerencsére nem lockol; ha tényleg mindenképpen elkerülhetetlenül abszolút lockolni akarsz, akkor van 'svn lock'.
SVN-ben csak commit van, nincs checkin. Ezzel lehet egy file-t (ránézésre a CC checkin megfelelője) vagy egyszerre több file-t committolni. Utóbbira rá lehet fogni, hogy "csak ilyen batch művelet könnyítő", de figyelembe véve, hogy a forrásfile-ok óhatatlanul is függenek egymástól, ezért inkább minden VCS-mel szembeni alapvető követelmény.

Hát ezt a forrásfile-ok mindóhatatlanul is függenek egymástól dolgot amit többet említettetek feljebb, ezt én azért megkérdőjelezném. Például ha webappot gyártunk, akkor például az egész mögötti buisniss logic-ot leíró forrásfile-jaimnak igazán semmi köze a webapphoz tartozó css-től. És ezért is ódzkodom attól, hogy minden apró css változtatás növeli az összes file-om verzióját.
Gondolom az SVN a lock-ot az egész repóra teszi, nem egy file-ra. Mert annak van értelme, hogy egy file-t én szerkesztek, ahhoz más ne nyúljon addig (tudom, merge-elhetne is). Az egész repót lockolni egy ilyen végett az meg ágyuval verébre.
SVN-hez mi olyan program van, mint a clearcase-ből a grafikus megremanager? (hehe, otromba csúf motif-os szutyok :) ) Csak hogy a bubik, a diff, meg ilyenek. (Esetleg eclipse-be épülve?)

"A herceg én vagyok."

"buisniss logic-ot leíró forrásfile-jaimnak igazán semmi köze a webapphoz tartozó css-től."
Jo esetben ezt vagy nem egyszerre fejleszti az ember, vagy nem egy ember fejleszti.

Viszont lehet csak egyes fajlokat es/vagy mappakat is commitolni, nem kell az osszes valtozast egy commitba felkuldeni. Ezt a modszert az IDE-k meg tamogatjak is. Meg lehet oldani, hogy egy-egy commitba csak osszetartozo fajlok legyenek.

En azt ajanlom, hogy probald legalabb ki az svn-t, nezegesd meg, mit tud, olvasd at a piros babos konyvet, es azutan donts.
-- 


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

És ha a CSS változása növeli a forrásfile verzióját, akkor mi van? Semmi az égvilágon. Használj Git-et, ott nem növeli (;
De ha pl. refaktorizálsz, és vhol átnevezel egy függvényt, akkor nem csak a függvény definícióját tartozó forrást kell módosítani, hanem a függvényt deklaráló header file-t (ha van, pl. C/C++) valamint az összes olyan file-t, ami meghívja ezt a függvényt. És ennek a több file-t is érintő változásnak egyetlen commitban van a helye. Az RCS(SCCS?)-örökség "minden file-t külön verziózunk" modellben esélyed nincs, hogy több file-on elvégzett összefüggő módosításokat kövessed.

svn lock nem az egész repót lockolja, hanem megadott file-okat és/vagy könyvtárakat.