Nemrégiben írtam egy rövid bejegyzést a Mercurial elosztott verziókezelő rendszerről. Ott a TortoiseHg-n keresztül mutattam be a rendszer lehetőségeit dióhéjban. Mivel azonban elsősorban a fejlesztésekhez használok verziókezelő rendszereket, szükségem volt egy Eclipse pluginre. Nagyon rövid keresés után rá is találtam a HgEclipse kiegészítőre. A kiegészítő telepítése nagyon egyszerű: a szokásos módon a honlapon található update URL-t kell megadni az eclipse-nek, ahonnan a rendszer lehúzza a kiegészítőt, és folyamatosan követi is annak frissítéseit. A HgEclipse nagyon jól integrálódik az Eclipse általános verziókezelő moduljába. Tehát a funkciókat a Team menüpont alatt fogjuk megtalálni, itt hozhatunk létre tárolót, innen commit-olhatunk, stb. Az egész annyira kézre áll, hogy ha lehet ilyet mondani, még kényelmesebb is a használata, mint a TortoiseHg-nek (pedig ahhoz sem kell atomfizikus diploma). Nézzük is meg dióhéjban, hogy működik.
Első körben hozzunk létre egy Java projektet, mondjuk MercurialTest néven. Eztán a szokásos jobb gomb -> Team/Share project .../Mercurial módszerrel hozzuk is létre a tárolót. Ahogyan az előző bejegyzésben már írtam, maga a tároló nem több, mint néhány speciális rejtett fájl a verziókezelt mappában, így nincs más dolgunk, mint nyomni egy finish-t, és kész is a tároló. Nem kell megadnunk szervert, stb. Ha megvagyunk, hozzunk is létre egy állományt, mondjuk egy szokásos HelloWorld.java programot. Ha ez is megvan, akkor az SVN-ből már megszokott Team/Commit módszerrel rögzíthetjük a változásokat. Ilyenkor kell adnunk valami rövid leírást az adott verzióhoz (igen, kell, nem lehet elhagyni, ami nem is feltétlen baj), kiválasztjuk a fájlokat, és már kész is a verzió. Tehát a dolog ugyanúgy megy, mint SVN esetén, csak nem kell hozzá szerver. E helyett minden a projekt könyvtárában lévő lokális tárolóba kerül. A Team/Show history-val láthatjuk az egyes verziókban történ változásokat, összehasonlíthatjuk, hogy hol mi változott, tehát mindent megtehetünk, amit SVN-ben. Ahogyan az előző bejegyzésben már írtam, az elosztott verziókezelőknél a fejlesztő a lokális tárolóba dolgozik mindaddig, amíg nem végez egy feladattal. Ha a feladat elkészült (letesztelte, jól működik a programrész, stb.), csak akkor tolja fel a változásokat a központi tárolóba. Ezt a Team/Push... menüpont segítségével tehetjük meg. Itt értelem szerűen megadhatjuk a távoli tároló címét, ahová betoljuk a változásokat. Ez felel meg kb. az SVN commit-nak. (Mivel a Mercurial lokális tárolója valójában néhány fájlból áll, ezért elvileg megtehető az is, hogy valaki Mercurial-t használ lokális verziókezelésre, majd ha elkészült, a változásokat a régi SVN tárolójába tolja be. Ilyesmivel nem próbálkoztam, és nem is tudom mennyire lehet hatékony, de ha valaki nagyon ragaszkodik az SVN-hez, az próbálkozhat ilyesmivel. Így esetleg fájdalommentesebb lehet az átállás egyik rendszerről a másikra.) Próbaképp készítsünk néhány lokális változatot, majd térjünk rá az elosztott verziókezelés egyik legnagyobb előnyére, és klónozzunk.
A klónozás kicsit trükkös Eclipse-ben, ugyanis nem a Team, hanem az Import menüpontban találjuk a Mercurial/Clone repository menüpont alatt (ami utólag végiggondolva végül is logikus). A klónozásra kiválaszthatunk távoli tárolót (ez felel meg kb. az SVN checkout-nak), vagy lokális tárolót. Próbaképp válasszuk ki a fájlrendszerből az eredeti (azóta Mercurial tárolóvá tett) eclipse projektet. Ha elkészült a klón, itt is csináljunk néhány változatot, és az eredeti projektben is commit-oljunk néhányat, lehetőleg úgy, hogy a kétféle változtatás üsse egymást (így tesztelhetjük majd a merge-öt). Ha készen vagyunk, próbáljuk visszafésülni az eredeti projektbe az újonnan létrehozott változatokat. Ehhez az eredeti tárolón használjuk a Team/Pull menüpontot. (Az előző bejegyzésben már írtam arról, hogy a változásokat vagy tolni [push], vagy húzni [pull] lehet egyik tárolóból a másikba.) Itt válasszuk ki a második lokális tárolót (természetesen használhatnánk távoli tárolót is), és húzzuk át a változásokat. Ekkor az eredeti tárolóban létrejön egy másik ág, és a HgEclipse rögtön rá is kérdez, hogy összefésülje-e a két ágat. Ezt ugye érdemes megtenni, úgyhogy válasszuk a merg-öt. Ha jól dolgoztunk, a rendszer nem fogja tudni simán összefésülni a két ágat, és néhány állomány conflict-es lesz. Ez ismerős lehet SVN-ből is, hiszen ott is előfordulhat, hogy a szerveren lévő változatot nem lehet automatikusan összefésülni a lokális változattal. Mondjuk az SVN ilyenkor televágja minden krix-krax-al a fájlt, és létrehoz egy állományt a lokális, egyet pedig a szerveren lévő változatnak. A Mercurial ennél szebben jár el, hiszen ott csak egy kis jelet látunk a fájl mellet, hogy conflict van, de nem rontja el az eredeti tartalmat, alul pedig megjelenik egy Mercurial Merge ablak, ahol látszik a conflict-es fájlok listája. Itt ha jobb gombbal rákattintunk egy állományra, a legelső menüpont az Open in Merge Editor. Itt szépen egymás mellett látjuk a két változatot, és kézzel kijavíthatjuk a hibákat. Elég kényelmes kis eszköz. Ha készen vagyunk a kézi merge-öléssel, újra nyomjunk jobb gombbal a fájlra, és az SVN-ből már megszokott "mark resolved" menüponttal fogadjuk el a változásokat. Ha megvagyunk a javításokkal, az eredményt kitolhatjuk a szerveren tárolt közös tárolóba, stb. Dióhéjban körülbelül ennyi lenne.
Véleményem szerint a HgEclipse egy nagyon jól sikerült kis eszköz, és önmagában a HgEclipse is, és a Mercurial mint verziókezelő is jóval többet ad nekünk, mint a hagyományos SVN tárolók. Az én jóslatom, hogy egyre többen fogják felismerni az ebben rejlő lehetőségeket, és néhány éven belül mindenhol át fognak térni valamilyen elosztott verziókezelő (Git, Mercurial, stb.) használatára.
Nincsenek megjegyzések:
Megjegyzés küldése