Kolumna Igora Rumihe: Mercurial iskustva u praktičnom radu, savjeti i trikovi

Vrijeme je za nekoliko opažanja i trikova u praktičnom radu s Mercurialom. Teorija je zgodna stvar ali praksa je često malo drugačija.

Danas ću navesti neka od svojstava Mercuriala, koja možda nisu očita na prvi pogled.

1.1 Rad s binarnim datotekama

Binarne datoteke (slike, video zapisi, dokumenti u ne-tekstualnom obliku - PDF, DOC, itd.) su vrijedni elementi svakog projekta i treba ih pohranjivati u version control sustavu vašeg projekta. Version control sustavi koji podržavaju snimanje inkrementalnih promjena na binarnim datotekama su rijetki. Većina ih radi tako da u slučaju izmjene binarne datoteke jednostavno u novoj reviziji snime cijelu binarnu datoteku. Tako radi i Mercurial. Nedostatak ovog pristupa je vidljiv kad se radi novi klon repozitorija koji već ima mnogo pohranjenih revizija. Pošto se u svakoj reviziji snima cijeli sadržaj binarne datoteke (naravno, ako je modificirana) a kloniranje repozitorija znači kopiranje kompletne povijesti jednog repozitorija na novu lokaciju, takve operacije mogu postati vrlo "skupe" jer će biti potrebno prebaciti velike količine podataka.

Rješenja su različita i ovise o uzorcima korištenja podataka u repozitoriju. Ako imate relativno malo binarnih datoteka u vašem projektu i još k tome se one rijetko modificiraju tad nema nekih značajnih prepreka da se one pohranjuju u Mercurial repozitorij. Kad to nije slučaj ljudi pribjegavaju raznim rješenjima. Jedno od popularnih je smještati binarne datoteke u Subversion repozitorij (Subversion je primjer centraliziranog verzion control sustava koji ima svojstvo da dobro podnosi binarne datoteke). Drugi pristup bio bi raditi vlastiti repozitorij za takve datoteke i "ručno" brinuti o čuvanju starih verzija tih datoteka. Mogućih rješenja ima još ali sva rješenja koja pretpostavljaju više različitih mjesta za pohranu podataka donose probleme sa sinkronizacijom, ručnu izradu alata koji pomažu s tim zadacima ili jednostavno uvođenje procedura kojih se svi članovi tima moraju pridržavati da bi sinkronizacija bila održana. Ništa od ovog ne možemo nazvati idealnim.

1.2 Brisanje dijela povijesti iz repozitorija

Version control sustavi su tu da bi nam dali pregled nad razvojem našeg projekta, što uključuje i sve greške koje smo napravili. Sa stajališta dokumentiranja kako se došlo do nekog rješenja vrijednost version control sustava je ogromna. Ipak, ponekad u vaš rapozitorij uđu izmjene koje poželite "izvaditi" što prije. Može se na primjer desiti da ste u repozitorij ubacili puno objektnih datoteka nastalih kompajliranjem vašeg projekta. Zbog distribuirane prirode Mercuriala pogrešku može biti jako teško ispraviti. Ako niste koristili neku od naredbi za sinkronizaciju s drugim repozitorijima tad si možete pomoći tako da napravite novi klon vašeg repozitorija ali sa zadnjom revizijom koja je prije revizije u kojoj ste napravili grešku. Ako ste vaše promjene već poslali na repozitorij na nekoj drugoj lokaciji tad uglavnom nema pomoći jer ovisno o veličini vašeg tima promjene su se mogle brzo propagirati na desetke drugih repozitorija. Ovdje nemam pravi savjet osim da treba biti oprezan kad se snimaju promjene u repozitorij. Brzopletost nam je gotovo svaki put donijela mnogo glavobolje.

1.3 Razmjena podataka s glavnim repozitorijem

Prije nego pokrećete naredbu "push" uvijek pokrenite naredbu "pull". Na taj način ćete riješiti eventualne merge konflikte prije nego vaše izmjene završe u glavnom repozitoriju. Iskustvo je pokazalo da se na Mercurialov "automatic merge" ne možete oslanjati pa ga je pametno isključiti u konfiguraciji i svaki merge raditi ručno. Postoje mnogi zgodni merge GUI alati i Mercurial se može podesiti da pokreće onog koji vama najviše odgovara.

1.4 Ad-hoc razmjena podataka između repozitorija

Ako vi i vaš kolega želite na brzinu testirati izmjene koje ste radili bez da ih šaljete na centralni repozitorij, korisno je upotrijebiti naredbu "serve". Tom naredbom stvorit ćete server koji sluša na konekcije s drugih računala i daje im na raspolaganje sadržaj vašeg repozitorija. Vaš kolega tad može narebom "pull" ili "clone" prebaciti vaše izmjene na svoje računalo.

1.5 Predstavljanje više revizija kao jedna

Ako ste radeći na svojem lokalnom repozitoriju završili neki dio posla i želite ga poslati u glavni repozitorij ali ne želite da se vide sve revizije već samo vaš krajnji rezultat možete koristiti naredbe "diff" ili "export" koje rezultiraju datotekom koju treba prebaciti na računalo s glavnim repozitorijem i tad osoba koja ima dovoljne privilegije na glavnom repozitoriju poziva komandu "patch". Ovo može biti korisno ako u vašem glavnom repozitoriju želite smanjiti količinu bespotrebnog šuma, iako je moj stav da sve te informacije imaju svoju vrijednost i jednom se mogu pokazati korisnima.

1.6 Dokumentacija i praktični rad

U svim ovim "savjetima" koje sam napisao navodio sam samo ime naredbe koju treba pokrenuti a ne i sve ostale potrebne parametre. Naredbom "help" koju pokrećete kao:

[pero] /projekt > hg help 

dobit ćete opširan opis naredbe koja vas zanima. Ako je i dalje nešto nejasno najbolji način je stvoriti repozitorij za testiranje i ono što vam nije jasno iskušati u praksi.