Kolumna Igora Rumihe: Kratki prikaz Mercurial version control sustava

Postoji nekoliko grupa alata koje bi svi trebali koristiti ali se dosta malo koriste. Radi se o version control sustavima, o sustavima za internu dokumentaciju i praćenje grešaka, te o code review alatima.

Zapravo ti alati samo služe kao potpora korisnim praksama koje se premalo koriste u softverskim projektima. Najbolji slogan za bilo koji Version control sustav bio bi "to je stroj za putovanje kroz vrijeme".

Imati arhiviranu cijelu povijest vašeg projekta, imati mogućnost skočiti natrag u vremenu u trenutak prije nego što ste unijeli tu katastrofalnu grešku u vaš proizvod, luksuz je kojeg si danas dozvoljavaju samo informatičari i poneki junak iz SF priča. Činjenica je da bi taj alat mogao koristiti bilo tko čiji se posao sastoji od pisanja velikih količina teksta (a uz malo pažnje to se može proširiti i na razne oblike binarnih zapisa kao što su slike, glazba, tehnički crteži i drugo).

CENTRALIZIRANI ILI DISTRIBUIRANI?

Danas se koriste mnogi VCS proizvodi, i komercijalni i besplatni. Svaki ima neke mogućnosti kojima privlači korisnike, a možda najvidljivija razlika danas je razlika između centraliziranih i distribuiranih sustava. Distribuirani sustavi su "novi igrači" u industriji i za sad ih uglavnom prihvaćaju manje firme, opensource projekti i sl. Među besplatnim alatim predstavnici te grupe su Git, Mercurial, Darcs, SVK, Bazaar, itd. dok se među komercijalnim sustavima mogu istaknuti Bitkeeper i Code Co-op.

VCS uglavnom radi na način da imate 2 entiteta: repozitorij i radnu kopiju. Na radnoj kopiji vi radite a kad ste spremni te promjene spremiti pozivate naredbu "commit" kojom se sprema trenutno stanje radne kopije u repozitorij. Kad se projekt sastoji od više ljudi svaki radi na svojoj radnoj kopiji. U centraliziranom sustavu svaka "commit" naredba šalje vaše izmjene u jedan centralni repozitorij dok u distribuiranom sustavu svaki od članova tima ima svoju kopiju repozitorija u koju se spremaju promjene. Distribuirani sustav zato razumije jedan dodatni skup naredbi koje služe međusobnom sinkroniziranju različitih repozitorija.

Kakva je zapravo korist distribuiranih sustava i čemu sav taj hype koji se podiže zadnjih nekoliko godina? Prema mojem iskustvu distribuirani VCS jesu korak naprijed, iz nekoliko razloga:

1. Jednostavnost i brzina. Većina interakcije sa version control sustavom je offline odnosno ne postoji komunikacija s nekim centralnim serverom. To znači da je odgovor od sustava brži. Brži odgovor sustava znači manje frustracije koju moram trpiti čekajući da se neka naredba izvrši.

2. Lako grananje projekta. Kreirati novu granu u kojoj ćete nešto isprobati je jako brzo i lako. Nije potrebna nikakva dodatna konfiguracija.

3. Spajanje ("merging") u glavni repozitorij se radi često i rade ga članovi tima svaki na svojem privatnom repozitoriju što donekle smanjuje komplikacije pri razrješavanju konflikntih izmjena.

4. Rad u projektu s distribuiranim VCS zahtijeva veće uključivanje svih članova tima u stvaranju konačnog proizvoda. Činjenica da svi članovi razrješavaju merge konflikte znači da svaki član tima mora biti dobro upoznat s radom svojih kolega što u konačnici daje dobre preduvjete da i krajnji proizvod bude kvalitetniji.

MERCURIAL

Ovo su samo neki od razloga za korištenje distribuiranih VCS-ova i u slijedećim mjesecima ću se posvetiti određenim aspektima rada s DVCS-om, a sad ću se kroz nekoliko primjera posvetiti samo prvoj točki. Do sad sam u svojem radu najviše praktičnog iskustva skupio s Mercurial sustavom pa ću njega iskoristiti za primjere.

Iskustvo je pokazalo da neki alat koji podržava organizaciju projekta neće biti korišten ako nije jednostavan i ako nije brz. Drugim riječima ako ste prisiljeni svoje vrijeme trošiti na interakciju s tim alatom a ne na svoj posao počet ćete tražiti načine da izbjegnete korištenje tog alata.

Mercurial doslovno sjaji kad je u pitanju jednostavnost i brzina korištenja. Sve naredbe se zadaju pozivanjem programa "hg" na komandnoj liniji ili korištenjem nekih od GUI dodataka za Windows explorer (TortoiseHG) ili za neki od IDE alata. Ja ću ovdje za primjere koristiti komandnu liniju ali logika rada (i nazivi naredbi) identični su i u GUI verzijama.

"hg" je jedini program iz Mercurial sustava kojeg morate pozivati. Za popis svih naredbi možete pozvati:

hg help

Naredba "init" inicijalizira repozitorij u direktoriju kojeg zadate kao argument (u ovom slučaju zadao sam kao argument trenutni direktorij "."):

hg init .

Tu sad na red dolazi vaš kreativni talent. Organizirajte si projekt stvarajući datoteke i direktorije po vašim željama. Ako koristite neki IDE proizvod onda će taj program organizirati projekt za vas, po njegovim željama. Da bi vidjeli što Mercurial misli o stanju vašeg repozitorije pozovete:

hg status

Rezultat bi mogao biti nešto ovakvo:

? doc/install.txt
? doc/manual.txt
? src/main.pl

Upitnik ispred imena znači da hg vidi ove datoteke ali ih još nije smjestio u svoj repozitorij. Zato zovemo naredbu "add":

hg add *

Hg će odgovoriti:

adding doc/install.txt
adding doc/manual.txt
adding src/main.pl

Sad smo spremni za prvi unos u naš repozitorij:

hg commit -u korisnik -m "Inicijalni unos"

Naredba commit kao argument s opcijom "-m" prima kratki opis izmjena koje se unose u repozitorij. To je obavezno i vrlo je korisno ako u ovom trenutnu stanete i promislite što ćete unijeti kao opis izmjene. Ljudi često unose kratke i besmislene poruke (npr. samo jedno slovo) jer im se u tom trenutku ne razmišlja. Kasnije, kad se dese situacije u kojima poželite proći kroz povijest vašeg projekta vidjet ćete da se isplati unijeti malo kvalitetniji tekst od samo "m" ili "commit" ili "fix" i sl. Version control sustavi mogu pokazati što je promijenjeno u nekoj reviziji ali ne mogu pokazati zašto je ta promjena napravljena ako vi ne unesete neki kvalitetni opis. Opcijom -u zadajemo neko ime koje će biti zapisano kao vlasnik ove izmjene. Ono se ne mora nigdje konfigurirati i ako želite možete svaki put zadati neko drugo ime no bilo bi korisno kad bi koristili isto ime tako da vi i vaši članovi tima znate tko je odgovoran za određene izmjene u projektu. Mercurial tu ne donosi svoja pravila već vaš tim treba dogovoriti pravila za organizaciju projekta.

Sad kad imamo nešto u našem repozitoriju možemo pregledati povijest izmjena:

projekt> hg log
changeset:   0:5d9437a15da4
tag:         tip
user:        korisnik
date:        Mon May 31 20:20:34 2010 +0200
summary:     Inicijalni unos

A U SLJEDEĆOJ KOLUMNI:

Ovo su osnove korištenja Mercurial DVCSa. Osim što je vrlo jednostavno kreirati novi repozitorij i što "commit" naredba nije slala podatke preko mreže u centralni repozitorij osjećaj korištenja je vrlo sličan centraliziranim version control sustavima. To je i smisao: ljudi navikli na cvs ili svn i slične centralizirane sustave mogu se brzo prebaciti na mercurial i bez posebnog dodatnog znanja postati pruduktivni u osnovnim zadacima. U slijedećem nastavku opisat ću jedan od mogućih workflow scenarija s Mercurialom u kojem dolaze do izražaja sve karakteristike distribuiranog sustava.