SVN sistemi

Ko se boji Git-a jo

Git je sistem za praenje i kontrolu revizija fajlova. Cilj ovog lanka je da korisnika uputi u osnove ovog alata, da pokae koliko je jednostavan kao i da ga motivie da pone da ga koristi. Ja ve nekoliko godina koristimSVNali me rastua popularnost Git-a podstie da ga to bolje prouim i primenim. Nije mi ovo prvi put da se susreem sa Git-om. Koristio sam ga po sistemu problem/reenje tj. nauio sam osnovne stvari ali kada je dolazilo do problema bilo kakve vrste pribegavao sam najgorim moguim reenjima. Nadam se da e mnogi koji su ovaj alat koristili na slian nain nai u ovom postu izvor motivacije da svoje znanje iz ove oblasti podignu na vii nivo. Siguran sam da e im u predstojeem periodu zatrebati. Danas se gotovo svi open source projekti oslanjaju na ovaj alat a podatak da ga u 2011. godini koristilo 11% a u 2012. godini ak 27% developera jasan je pokazatelj njegove vrednosti.

Kako je sve poeloNastao je iz praktine potrebe zajednice koja je bila okupljena oko razvoja kernela Linux-a. Najpre je u ovu svrhu korien softverBeetKeeper. Vremenom je dolo do pogoranja odnosa izmeu Linux zajednice i firme koja je stajala iza Bitkeeper-a te je Linus Torvalds, nezadovoljan ostalim alatima koji su tada bili dostupni, odluio da napravi novi sistem za verzionisanje gde e primeniti dobru praksu i iskustva koja su stekli koristei BeetKeeper. Sam naziv potie od engleske rei git to u prevodu znai glup, neprijatan ovek. Linus u ali kae Im an egotistical bastard, and I name all my projects after myself. First Linux, now git. Ciljevi koje su postavljeni pred novi sistem su:

Da bude brz

Da bude jednostavnog dizajna i jednostavan za uenje

Da podrava veliki broj branch-eva

Da bude potpuno distribuiran

Da bude siguran i otporan na greke

Da bude sposoban da podri velike projekte

Moemo slobodno rei da je ovaj alat ispunio zacrtano u svim kategorijama.

Tipovi sistema za kontrolu verzijaSistemi za kontrolu verzija predstavljaju alate koji slue kao podrka timovima i pojedincima u praenju razvoja i odravanju projekata. Koristei ove sisteme svi podaci su sigurniji, bolja je sinhronizacija izmeu lanova tima, smanjuje se mogunost greke i poboljava se sam proces voenja projekta. Postoje dve vrste sistema za kontrolu verzija centralizovani (CVCS) i distribuirani (DVCS). Prvoj vrsti pripadaju alati kao to suSVN,PerforceiCVSdok u drugu vrstu spadajuMercurial,Bazaar,DarcsiGit. Kod CVCS svi podaci o verzijama se nalaze na centralizovanom serveru dok klijenti imaju dostupnu samo trenutnu verziju na kojoj rade. Ovo je svakako lake za odravanje i administriranje ali u sluaju otkaza ovog sistema gube se sve informacije o projektu. Kod DVCS klijenti pored poslednje verzije preuzimaju i kompletnu bazu o svim verzijama na tom repozitorijumu. U sluaju bilo kakvog otkaza sistema dovoljno je da jedan od klijenata postavi podatke na server i svi problemi su vrlo brzo reeni.

Kako Git funkcioniePre nego to preemo na konkretne primere potrebno je objasniti kako odreeni delovi funkcioniu a sve u cilju breg uenja. Ono to predlau svi prirunici jeste da zaboravimo sve to smo do sada znali o bilo kom drugom sistemu za verzionisanje. Kod Git-a kao predstavnika DVCS prilikom kloniranja nekog repozitorijuma kopira se celokupna baza o projektu a ne samo poslednja verzija. To znai da su nam lokalno raspoloive sve verzije fajlova od prve do poslednje. Budui da se svi podaci nalaze u lokalu odziv je neuporedivo bri kada su nam potrebne informacije o repozitorijumu i fajlovima u njemu. Generalno govorei veina operacija se odvija lokalno bez potrebe za komunikacijom sa serverom. Git ima potpuno razliit princip uvanja podataka od svih ostalih sistema. Svaki put kada mu se podaci proslede na uvanje sauva se celokupno stanje sistema, snima se tzv. snapshot svakog fajla. Ukoliko neki fajl nije promenjen onda se uva pokaziva na njegovo prethodno stanje. Ovo u praksi znai da moemo itav sistem da preuzmemo u odreenoj verziji. Ostali sistemi uvaju informacije o osnovnom, prvom prosleenom fajlu, a zatim vode rauna o promenama koje su se na njemu desile. Za oekivati je da je prostor koji zauzima projekat koji je na Git-u mnogo vei od istog tog projekta na SVN-u ali to nije sluaj naprotiv mnogo je manji.

Tri glavna elementa Git-a su:

1. Repozitorijum (Git repository, Repository ili kratko Repo). Ovde se nalaze svi metapodaci i baza podataka o naem projektu. Kada neko preuzima (klonira) projekat kopira mu se ovaj direktorijum.

2. Radni direktorijum (Working directory). Predstavlja lokalni folder u kome menjamo i kreiramo fajlove koji su obuhvaeni verzionisanjem

3. Prostor pripreme (Staging area). Svi fajlovi pre nego to se komituju moraju da budu pripremljeni za to. Mesto gde se oni smetaju jeste ovaj pripremni deo. Samo oni fajlovi koji se nalaze ovde bie komitovani. Budui da Git pravi snapshot svih fajlova prilikom komita sasvim je logino postojanje pripremnog dela jer emo najpre ovde smetati fajlove i na taj nain sistem nee morati da pravi snapshot kad god imamo spreman neki fajl.

Fajlovi u Git repozitorijumu mogu imati statuse:

Praeni (Tracked) Imaju ga svi fajlovi koji su pod kontrolom Git-a. Oni mogu bitiizemenjeni, neizmenjeni, i pripremnljeni (modified, unmodified i staged).

Nepraeni (Untracked) u okviru repozitorijuma mogu biti fajlovi koji nisu pod kontrolom i nad njima Git nema nikakvog uticaja. Sve nove fajlove koje kreiramo unutar ili prekopiramo u repozitorijum imaju u startu ovaj status. Ove fajlove samo jedna komanda deli od toga da postanu praeni. Imamo i mogunost da konfiguracijom podesimo odreene tipove fajlova koje e sam Git po automatizmu da ignorie

InstalacijaGit server se moe instalirati na Linux-u, Windows-u i MacOS-u. U ovom postu u pokazati instalaciju na Ubuntu a uputstva za instalaciju na ostalim sistemima moete lako pronai. Od verzije 12.04 Ubuntu za instalaciju Git-a ima paket koji se zove git. Za ranije verzije ovaj paket se zove git-core. Ovo je osnovni paket. Ostale pakete moemo podeliti:

transfer sa drugih sistema za kontrolu verzija git-arch,git-cvs,git-svn grafiki UI git-gui,gitk,gitweb email git-email za deljenje repozitorijuma git-daemon-runKomanda sa osnovnu instalaciju bila bi:

sudoapt-getinstallgitgit-docgitwebgit-guigitkgit-emailgit-svngit-daemon-run

Sve je spremno da postavimo neki projekat pod Git kontrolu. Proces emo objasniti preko osnovnih elemenata Git-a.

RepozitorijumOtvoriemo novi folder i nazvati gagitrepo. Da bi od njega napravilli repozitorijum dovoljno je da se pozicioniramo unutar tog foldera i unesemo sledeu komandu:

Sistem e nam poslati sledei odgovor:

InitializedemptyGitrepositoryin/var/git/gitrepo/.git/

To znai da smo uspeno kreirali na prvigit repozitorijum. Unutar naeg foldera kreiran je novi podfolder.giti u njemu e se nalaziti celokupna baza o naem projektu. Kako bismo videli trenutni status direktorijuma ukucaem komandu:

Budui da u ovom trenutku nita nije menjano u repozitorijumu odgovor sistema je:

# On branch master

#

# Initial commit

#

nothingtocommit(create/copyfilesanduse"git add"totrack)

Kao to vidite ve smo dobili uputstvo ta treba dalje da radimo. Budui da smo kreirali novi repozitorujum mi nemamo fajlova koje bi u startu dodali u repozitorijum. Prei emo na sledei korak.

Radni direktorijumSada kada imamo formiran repozitorijum pokazaemo kako se on klonira. elimo da radimo sa naim, radnim direktorijumom i da tu pripremamo izmene koje bi zatim komitovali u repozitorijum. Kloniraemo na lokalni, upravo formirani repozitorijum. Budui da se on nalazi u lokalu kao putanju mogu uneti putanju do lokalnog foldera prilikom kloniranja. Pozicioniraemo se na folder u kome elimo da smestimo na radni direktorijum. U mom sluaju komanda za kloniranje je sledea:

gitclone/var/git/gitrepo

Hajde da kreiramo novi fajl fajl first.txt u naem radnom direktorijumu i unesite proizvoljni sadraj u njega. Kada nakon toga zatraimo status dobijamo sledei odgovor:

# On branch master

#

# Initial commit

#

# Untracked files:

# (use "git add ..." to include in what will be committed)

#

# first.txt

nothingaddedtocommitbutuntrackedfilespresent(use"git add"totrack)

Trenutno u direktorijumu imamo jedan fajl koji ima status nepraen (Untracked). Sistem nam je pruio informaciju ta dalje treba da uradimo. Potrebno je da ovaj fajl prvo smestimo u pripremni prostor.

Pripremni prostorOvo je deo koji je potpuno zbunjujui za sve one koji su koristili SVN. Pre nego se neto komituje mora da se smesti u pripremni prostor. Samo fajlovi koji se nalaze u ovom prostoru mogu se komitovati. Kao to smo rekli svaki komit znai i snapshot celog sistema te je postojanje pripremnog dela sasvim opravdano. Hajde da dodamo fajl first.txt u pripremni prostor. Sistem nas je uputio da koristimo komandugit addda bismo ovaj fajl oznaili za praenje. Ovoj komandi moemo rei da ubaci samo ovaj fajl git add first.txt, sve fajlovegit add .ili samo npr. fajlove sa ekstenzijom txt git add *.txt. Sada smo prebacili fajl u pripremni prostor. Status direktorijuma sada je:

# On branch master

#

# Initial commit

#

# Changes to be committed:

# (use "git rm --cached ..." to unstage)

#

# new file: first.txt

#

Fajl first.txt je spreman da se komituje u repozitorijum.

KomitovanjePre prvog komitovanja potrebno je podesiti osnovne infomarcije o nama kao korisnicima. Ovi podaci pojavie se u prikazu istorije promena na fajlovima. Potrebno je uneti odgovarajue podatke u sledeim komandama:

gitconfig--globaluser.name"Ime Prezime"

gitconfig--globaluser.emailexample@email.com

Pre svakog komita potrebno je, a mogu slobodno rei i obavezno, to jasnije definisati opis promena obuhvaenim komitom. Takoe je bitno da fajlovi koji se komituju budu grupisani u neku celinu. Ovde ponovo dolazi do razlaza sa logikom SVN-a. Komitovanjem se fajlovi ne alju u centralni repozitorijum ve se i dalje uvaju u okviru naeg radnog direktorijuma. Dakle mi moemo imati vie komita pa onda kada zavrimo neku celinu moemo fajlove poslati u repozitorijum. Fajl emo komitovati na sledei nain:

gitcommit-m"Initial commit"

Odgovor sistema je:

[master(root-commit)89edc70]Initialcommit

1fileschanged,1insertions(+),0deletions(-)

createmode100644first.txt

Hajde sada da promenimo sadraj fajla first.txt. Kada zatraimo status odgovor je sledei:

# On branch master

# Changes not staged for commit:

# (use "git add ..." to update what will be committed)

# (use "git checkout -- ..." to discard changes in working directory)

#

# modified: first.txt

#

# Untracked files:

# (use "git add ..." to include in what will be committed)

#

# first.txt~

nochangesaddedtocommit(use"git add"and/or"git commit -a")

Primeujete kako Git ponovo zahteva da izmenjeni fajl najpre postavimo u pripremni deo a zatim da ga komitujemo. Dakle nije mogue odmah komitovati fajl bez obzira da li je on bio praen ranije ili ne. Fajl se pre komita mora smestiti u pripremni deo. Kao dodatni parametar u komandi commit moemo proslediti opciju da se fajlovi automatski dodaju u pripremni deo pre samog komita na sledei nain:

gitcommit-a-m"Second commit"

Snimanje u repozitorijumSada kada imamo u naem direktorijumu dva komita elimo da taj sadraj poaljemo u repozitorujum kako bi to bilo dostupno i ostalim korisnicima koji ga koriste. To emo uraditi preko komande:

Ukoliko budete imali problema sa slanjem izmena na repozitorijum unesite sledeu komandu u folder gde se nalazi repozitorijum (detaljna objanjenja pogledajteovde) :

gitconfig--boolcore.baretrue

Nakon ovoga ponovo pokuajte da poaljete podatke na repozitorijum.

Preuzimanje iz repozitorijumaUkoliko ima jo korisnika koji rade nad istim repozitorijumom sledeom komandom bismo preuzeli izmene u na radni direktorijum:

Dalji koraciOvo je samo prvi u nizu postova o Git-u. Mnogo je jo funkcionalnosti i mogunosti koje treba opisati. Ovo je samo poetak, osnova za dalje uenje. Odlian pregled mogunosti moete pogledati nasnimku predavanjaMire Svrtanana nedavno odranom PHP meetup-u u Zagrebu. Sledei post bie posveen branch-evima i spajanju istih. Videete koliko je to jednostavno uraditi koristei Git.

U skladu sa obeanjem koje sam dao najpre sebi, a i drugima, da u da nauim da koristim Git ovaj blog post e biti dokaz da sam to i uinio. Ne znam za vas ali za sebe sam poprilino siguran koji u sistem za verzionisanje koristiti ubudue.SVET KOMPJUTERA - PD KUTAK - TortoiseSVN 1.5.2

Svi za jednog, jedan za sve

Da li ste se ikada zapitali kako velikim razvojnim timovima, pre svega u softverskoj industriji, polazi za rukom da usklade rad velikog broja uesnika u projektu, a da pri tom ne doe do meusobnih konflikata u radu? Jeste li ikada razmiljali o tome kakoopen sourceprojekti, moda kao najupeatljiviji primer masovne saradnje, opstaju u situacijama gde je neophodno uskladiti rad ljudi koji neretko ive u najrazliitijim delovima sveta? Jo ako je priroda samog projekta takva da se esto prave korenite promene u njegovoj koncepciji, postavlja se pitanje kako obezbediti stalan uvid u stanje projekta i pri tome ne bauljati konstantno po arhiviranim rezervnim kopijama koda. Ovo su pitanja koja e svaki ozbiljan menader projekta ili programer bar jednom u svojoj karijeri morati samom sebi da postavi, a odgovori na njih su, verovali ili ne, stari gotovo isto koliko i sam problem i datiraju jo iz osamdesetih godina prolog veka, kada su svetlost dana ugledali prvi sistemi za kontrolu verzija(version control systems).

U najkraim crtama, sistem za kontrolu verzija jeste aplikacija iji je osnovni zadatak da skladiti podatke projekta (programski kod, dokumentaciju itd.) zajedno sa infomacijama o njihovim izmenama i da pri tom bude sposobna da u bilo kom trenutku rekonstruie kompletan izgled projekta, onako kako je dotini izgledao u tano zadatom trenutku. Ako izuzmemo veliki broj nesumnjivo kvalitetnih (ali i skupih) komercijalnih sistema za kontrolu verzija, dva sistema koja je iznedrilaopen sourcezajednica mogu se pohvaliti izuzetno velikom popularnou i kvalitetom. To suCVS(Concurrent Versioning Systemwww.nongnu.org/cvs) iSVN(Subversion subversion.tigris.org), oba objavljena pod slobodnim licencama i besplatna.CVSje nastao pre skoro trideset godina i, pored jo neosporne popularnosti, sve vie posustaje pred savremenijim sistemima kao to jeSVN,koji je nastao upravo iz potrebe da se eliminiu odreeneCVS-ovebubice i koncepcijski nedostaci. Ipak, vreme je pokazalo da jeSVNizrastao u potpuno nezavisan sistem sa relativno malim brojem zajednikih dodirnih taaka saCVS-om.

ZaSubversionje karakteristino to da se najee koristi kroz skup programa koji se pokreu iz konzole(shella),pri emu korisnici Windowsa mogu pre svega da uivaju u blagodetima korienja nekog od mnogobrojnih grafikih interfejsa, koji ih oslobaaju potrebe da se uputaju u rvanje sashellom.Najpoznatiji i ubedljivo najpopularniji program te vrste svakako jeTortoiseSVN,koji dolazi iz softverske kue Tigris,open sourceogranka CollabNeta (www.collab.net), koji je inae zasluan i za razvoj samogSubversiona.U pitanju je program koji se nakon instalacije smeta u kontekstni meniWindows Explorera,to znai da se svim njegovim opcijama moe pristupiti desnim klikom mia, pri emu program sam nudi opcije koje su primenljive i pre svega dozvoljene nad trenutno izabranim fajlovima i folderima. Kad smo ve kod fajlova i foldera, od izuzetne pomoi pri radu je vizuelna identifikacija njihovog statusa putem sistema veoma dopadljivih ikonica, koje svojim izgledom jasno stavljaju do znanja korisniku da li je bilo izmena nad fajlom (folderom) od trenutka poslednje evidentirane izmene, da li je fajl sastavni deo sistema za praenje verzija itd.

Pre bilo kakvog rada sa svee instaliranimTortoiseSVN-ompotrebno je odrediti folder na raunaru koji e sluiti kao repozitorijum za skladitenje podataka. SamTortoiseSVNsposoban je da napravi i pristupi tzv. lokalnim repozitorijumima, koji su dostupni iskljuivo njemu, ali je zahvaljujui izuzetno velikom broju podranih mrenih protokola direktno iz programa omoguen i rad sa udaljenim repozitorijumima, kojima se moe pristupiti preko sledeih protokola: http, https, svn, svn+ssh i svn+XXX. Za prikaz sadraja repozitorijuma u svakom trenutku zaduen je tzv.repo browser,putem kog je mogue, sa samo nekoliko klikova, realizovati operacije kao to su interno kopiranje fajlova, njihovo brisanje itd. Svaka od navedenih operacija, ukljuujui i operacije pridodavanja novih ili izmenjenih starih delova projekta (tzv.commit),evidentira se u okviru izuzetno detaljnog internog log sistema. Pravu poslasticu predstavlja vizuelni grafiki prikaz izmena (revizija), kao i eventualnih grananja(branch)projekta, kojima je mogue projekat povesti u nekoliko potpuno nezavisnih razvojnih pravaca, uz ouvanje nezavisnosti svakog pravca.

Jedno od najmonijih orujaTortoiseSVN-aupravo predstavljaju njegove alatke za regulisanje konflikata i spajanja u okviru kojih su implementiraniTortoiseDiff, TortoiseMerge, TortoiseIDiffiTortoiseBlame.Prvi i trei slue za uporeivanje razlika u fajlovima izmeu dve revizije, pri emu se prvi koristi za tekstualne fajlove a drugi za slike.TortoiseMergeje zaduen za spajanje revizija uz pruanje veoma velikog stepena slobode kod izbora komponenata koje e sainjavati finalnu spojenu verziju projekta. ik pogodite emu sluiTortoiseBlame. Kako mu samo ime kae, on slui da ocinkari osobu koja je bila zasluna za doprinos odreenog, eventualno spornog elementa koji je postao sastavni deo projekta u odreenom trenutku.TortoiseSVNpodrava preko dvadeset jezika, meu kojima se ne nalazi srpski, a veoma je pohvalno to to je uz odreena podeavanja program veoma lako podesiti da sarauje sa bilo kojim od poznatijihissueibug trackingsistema.

PotencijaliTortoiseSVN-asu neosporni, to potvruje ogroman brojdownloadai veoma pozitivne kritike njegovih korisnika. Njegova prava mo dolazi, dodue, do izraaja u trenucima kada projekat naraste do odreenog stepena kompleksnosti, a ideja za meusobnom saradnjom veeg broja ljudi preraste u potrebu. Jednostavan, brz i, pre svega, odlino integrisan u operativni sistem,TortoiseSVNje jedan od onih programa koji veoma brzo izazivaju zavisnost kod svakoga ko je nauio da ceni ono to on moe da prui.

Mia BREANAC

Maturski, seminarski i diplomski radovi iz informatike.

Tokom razvoja veih softverskih projekata postoji potreba za kvalitetnim praenjem verzija kroz koje projekat prolazi. Pri tome se mora voditi rauna o odravanju celog projekta kao i svih njegovih verzija. Praenje razvoja projekta moe se raditi runo, ali je to vrlo teak i mukotrpan posao, koji je podloan grekama (gubitak izvrenih promena, nemogunost uvanja svih verzija, ...).

Danas se za praenje razvoja softverskih projekata koriste pomoni alati koji se jednim imenom nazivaju Sistemi za kontrolu verzija (Version Control Systems - VCS). Sistemi za kontrolu verzija pomau u odravanju softverskih projekata u aurnom stanju i prate njihov razvoj tokom vremena. Iako se ovi sistemi koriste, uglavnom, za praenje razvoja softverskih projekata, oni se mogu koristi i za praenje verzija bilo koje vrste tekstualnih elektronskih podataka (word dokumenti, txt dokumenti, ). [3]

Neki od problema, koji mogu nastati u toku razvoja projekta, su:

Komplikovano praenje paralelnog razvoja projekta na vie radnih mesta.

Promene u jednom delu projekta mogu prouzrokovati promene u drugom delu, a da se to nije oekivalo i predvidelo.

Kada se izvri neka promena i sauva se u projektu, teko je u sluaju potrebe, vratiti se na prethodno stanje projekta.

Na kraju razvoja projekta potrebno je spojiti razliite celine razvijane na vie radnih mesta, to je esto teak i komplikovan posao.

Ovi problemi se uspeno prevazilaze primenom Sistema za kontrolu verzija. Danas postoji veliki broj razvijenih sistema za kontrolu verzija softvera i elektronskih podataka. Razliiti proizvoai softvera nude ove sisteme kao podrku pri razvoju softverskih aplikacija. Neki od proizvoaa su Microsoft, Uni Software Plus, Perforce Inc., a veliki broj ovih sistema je open source.

U ovom radu e biti prikazan razvoj, opis i funkcionisanje Sistema za kontrolu verzija.

2. RAZVOJ SISTEMA ZA KONTROLU VERZIJA

Poetak Sistema za kontrolu verzija je bio razvoj programa diff i patch, koji su poeli da se koriste za poreenje fajlova pri projektovanju softverskih aplikacija. Program diff prikazuje razliku izmeu dva fajla. Ako se program diff primeni na neki fajl pre i posle njegove modifikacije, rezultat e biti samo modifikovani redovi, dok e ostali biti preskoeni. Program patch koristi razlike nekih fajlova (uglavnom dobijenih kao proizvod programa diff), i te razlike pridruuje odgovarajuem fajlu. Na primer, ako se pronae razlika izmeu fajla A i fajla B (pomou diff programa), i na tu razliku i prvi od tih fajlova se primeni program patch, odgovarajui fajl e se dopuniti razlikama. Ovime je omogueno da vie ljudi radi na razvoju jednog projekta i da svoje promene pomou diff i patch programa uine dostupne drugim korisnicima. [3]

Tokom razvoja projekta, ponekad se desi da promene koje su napravljene u fajlu posle nekog vremena treba ponititi tj. projekat treba vratiti u stanje kakvo je nekada bilo. Meutim, ako se projekat odrava na ovaj nain jako je teko ui u trag ko je kakve promene u meuvremenu napravio, a ak i da se to ustanovi, sve promene bi morale runo da se briu, to je teak i dugotrajan proces podloan grekama. Reenje tog problema je bilo u izgradnji sistema za praenje istorije projekta tj. sistema koji bi mogao da pronae ranije verzije projekta. Izgraeno je vie takvih sistema, a jedan od poznatijih je Revision Control System (RCS) [1]. RCS je imao veliku primenu ali su uoeni i njegovi nedostaci:

Nemogunost kontrole celog projekta,

Nije dozvoljen istovremeni pristup jednom fajlu od strane vie korisnika,

Nije mreno orjentisan - svi korisnici sistema moraju da rade na maini na kojoj je instaliran RCS ili da organizuju transfer podataka izmeu radnih stanica i RCS servera.

Kao rezultat prevazilaenja ovih nedostataka, 1986. godine je razvijen Conccurent Versioning System (CVS) od strane Dick Grune-a [3]. Ovaj sistem je poeo da se razvija od skupa skriptova koje RCS ine funkcionalnijim. CVS je doiveo veliku popularnost, ali se u praksi pokazalo da i on ima neke nedostatke (komplikovana promena strukture skladita, lo oporavak od pada sistema, ...).

U periodu od 2000. do 2004. godine razvijen je sistem Subversion v1.0 [3]. Od tada njegova popularnost raste i pojavljuju se njegove novije verzije. Subversion je besplatan softver koji se moe preuzeti sa razliitih internet lokacija.

Danas postoji veliki broj sistema za kontrolu verzija kako komercijalnih, tako i onih besplatnih. Pored pomenutih sistema, koriste se i Git, Perforce, Bazaar, Visual SourceSafe, i dr. [4, 5]

3. OPIS SISTEMA

Osnovni elementi Sistema za kontrolu verzija su [2, 3]:

Skladite (repository),

Radni direktorijumi korisnika (working directories), i

Revizije sistema (revisions).

Na slici 1 je dat ematski prikaz Sistema za kontrolu verzija.

Slika 1. Prikaz Sistema za kontrolu verzija

Skladite je centralni deo sistema za kontrolu verzija, gde se smetaju fajlovi projekta, izvrene promene korisnika na njima i drugi sistemski podaci. Skladitu moe da pristupi vei broj korisnika istovremeno sa ciljem itanja ili izmena fajlova. Organizacija skladita varira od sistema do sistema. Skladite moe biti:

direktorijum na serveru u koji su smeteni svi fajlovi projekta i sve njegove verzije,

baza podataka koja sadri zapise svih fajlova projekta tj. sve verzije projekta,

kompleksan distribuirani sistem koji smeta fajlove projekta, tj. sve njegove verzije, na vie raunara.

Kako god da je skladite organizovano, korisnici ne pristupaju direktno fajlovima u skladitu, ve rade na svom radnom direktoriju.

Radni direktorijum korisnika je prostor na lokalnom raunaru gde se nalaze kopije podataka iz skladita. Korisnici u radnom direktorijumu mogu da itaju, menjaju i testiraju delove projekta tokom procesa njegovog razvoja. Tek kada je zadovoljan izmenama, korisnik ih moe potvrditi, i one se upisuju u skladite. Posle toga ostali korisnici mogu da im pristupe. U svakom trenutku se moe izvriti auriranje verzije fajlova u radnim direktorijumima sa stanjem u skladitu.

Revizije se mogu opisati kao delovi skladita u kojima se uvaju promene koje su korisnici izvrili i potvrdili na svojim radnim direktorijumima. Korisnici mogu menjati fajlove ali i strukturu i arhitekturu celog projekta. Sistemi za kontrolu verzija pamte trenutno stanje i sve prethodne verzije projekta.

U zavisnosti od Sistema za kontrolu verzija, postoje:

Globalne revizije, i

Revizije na nivou fajla.

Globalne revizije se odnose na stanje celokupnog skladita. Ako su revizije globalne, onda svaka potvrda izmene na jednom fajlu povlai novu reviziju za taj fajl i sve ostale fajlove u skladitu. Revizije na nivou fajla se odnose na stanje pojedinanog fajla u skladitu. Ako su revizije na nivou fajla, onda svaki fajl ima svoju istoriju izmena nezavisnu od ostatka projekta. Ovakav vid praenja revizija je jako teak kada je potrebno sagledati itav projekat.

4. Osnovni principi funksionisanja sistema

Svi Sistemi za kontrolu verzija moraju da obezbede korisnicima korienje fajlova iz skladita, ali i da spree gubitak fajlova ili njihovih delova, koji mogu da nastanu kao posledica kolizije izmeu njih. Do gubitka fajlova ili njihovih delova, moe doi kada bar dva korisnika istovremeno pristupaju nekom fajlu i menjaju ga. Tada jedan korisnik moe ponititi promene koje je drugi korisnik napravio, a takve situacije se moraju prevazii. Pri tome, izmene koje je napravio prvi korisnik nisu trajno izgubljene, ali se ne nalaze u tekuoj verziji projekta. Na slici 2 je prikazan postupak gubitka podataka kada dva korisnika snimaju svoje izmene.

Jedan od naina za izbegavanje ovakve situacije je 'Zakljuaj Izmeni Otkljuaj' pravilo [2]. Po ovom pravilu samo jedan korisnik jednovremeno moe da menja jedan fajl, on ga zakljua, a drugi korisnici, ako ele menjati isti fajl, moraju da ekaju da on bude osloboen tj. otkljuan. Na slici 3 je prikazan ovaj nain pristupa podacima.

Ovo reenje ima dosta nedostataka, a neki od njih su [2]:

Korisnik moe da zakljua fajl, i da zaboravi da ga otkljua ime on postaje nedostupan za ostale korisnike.

Gubljenje vremena u pristupu kada korisnici ele da menjaju isti fajl, ali ne i i ste delove, jer tada kolizija zapravo ne postoji.

Zakljuavanje moe da proizvede lanu sigurnost jer time to je jedan fajl zakljuan ne znai da su zakljuani i svi fajlovi koji su vezani za njega, pa je u njima mogue vriti izmene to moe prouzrokovati da pomenuti fajlovi vie ne funkcioniu kao sistem.

Veina Sistema za kontrolu verzija koriste 'Kopiraj Izmeni - Sastavi' pravilo za reavanje ovih problema [2]. Po ovom pravilu korisnik preuzima kopiju fajla iz skladita, menja ga i potvruje promene. Ako je vie korisnika preuzelo kopije istog fajla, kada se izmene potvrde, kopije se spajajaju u konanu verziju. Meutim, u nekim situacijama neophodna je i pomo oveka radi pravilnog spajanja ovih kopija. U situacijama kada jedan korisnik potvruje izmene na nekom fajlu, a nakon nekog vremena i drugi korisnik potvruje svoje promene na istom fajlu, sistem funkcionie tako to druga potvrda ne uspeva, ve se korisnik obavetava da nema tekuu verziju fajla. Korisniku je omogueno da zatrai spajanje svojih izmena sa izmenama u tekuem fajlu. Ovo e biti uraeno osim ako nije dolo do konflikta tj. situacije u kojoj su oba korisnika menjala iste redove u fajlu. Tada e korisniku biti predoeno da je dolo do konflikta, bie mu prikazane obe verzije fajla i on e sam odluiti na koji e nain razrei...

SVET KOMPJUTERA - PD KUTAK - Eclipse Classic 3.3Besplatno razvojno okruenje

Samo programeri koji su preli trnovit put od tekst editora do integrisanih razvojnih okruenja znaju koliko dobro razvojno okruenje poboljava efikasnost rada i smanjuje broj sitnih greaka koje zagoravaju ivot. Sada, kada su vremena piraterije (skoro) iza nas, postajemo svesni da kvalitetna razvojna okruenja esto kotaju itavo bogatstvo, a ako na rad pokriva vie razliitih oblasti, onda je potrebno koristiti i vie alata, od kojih svaki donosi svoje specifinosti i zahteva vreme za prilagoavanje i uenje.

Eclipse je prvobitno zamiljen kao naslednik IBM-ovog integrisanog razvojnog okruenja VisualAge (Integrated Development Environment IDE), da bi 2001. godine zapoeo ivot kaoopen-sourceprojekat koji 2003. godine prerasta u Eclipse Consortium, neprofitnu organizaciju softverskih kompanija predvoenih IBM-om, formiranu radi usmeravanja razvoja Eclipsea. Iako veina ljudi doivljava Eclipse kao Java IDE, Eclipse je mnogo vie od toga radi se o platformi za razvoj i pokretanje radnih okruenja za razliite namene koje nisu ograniene samo na programiranje (mada takvih ima najvie). Prava mo platforme Eclipse lei u proirivosti, gde se osnovne funkcionalnosti koje obezbeuje platforma jednostavno nadograujuplug-inovimakoji Eclipse pretvaraju u krajnju korisniku aplikaciju koja moe imati bilo koju namenu. Eclipse platforma se brine oplug-inovima, obezbeujui im osnovne funkcionalnosti kao to su otkrivanje, instalacija i odravanje. Pored toga, za kreatoreplug-inovau Eclipseu postoji programska podrka za rad sa resursima (projekti, fajlovi, folderi), pojednostavljeno je dodavanje korisnikih elemenata u postojee korisniko okruenje, kreiranjehelpa,rad sa sistemima za kontrolu verzija kod rada u timovima (VCS), podrka za debagovanje nezavisna od jezika, kao i niz drugih stvari koje olakavaju kreiranje i integracijuplug-inovau Eclipse.

Po preuzimanju arhive sa Interneta, prvo to ete primetiti jeste da ne postoji klasina instalacija, ve je arhivu dovoljno raspakovati u proizvoljni folder i pokrenuti izvrni fajl. Pri tom je na raunaru mogue istovremeno imati proizvoljan broj razliitih verzija Eclipsea i sve one e raditi bez meusobnih konflikata. U ovom tekstu bie opisan Eclipse Classic, ali treba imati u vidu da postoji vie razliitih paketa sa unapred instaliranimplug-inovima, tako da su spremni za odreenu oblast primene C/C++, Java, Java EE i slino. Pored toga, svake godine se kreira godinje izdanje Eclipsea kao zajedniki poduhvat vie timova koji rade na razliitim projektima da bi se izbegao problem kompatibilnosti osnovne verzije i verzijaplug-inova.Ovogodinje izdanje Eclipsea dolazi pod kodnim imenom Europa, sadri 21plug-ini pokriva zaista irok asortiman primena, sasvim dovoljan za veinu korisnika.

Eclipse donosi odreenu terminologiju koja za korisnike koji se prvi put susreu sa ovim okruenjem moe biti zbunjujua, zato emo se ovde ukratko pozabaviti osnovnim pojmovima.Workspacepredstavlja skup projekata na kojima korisnik radi, pri emu se u projektima mogu nai fajlovi i folderi. Projekti, fajlovi i folderi spadaju u resurse. I dokWorkspacepredstavlja relativno apstraktnu kategoriju,Workbenchnam nudi elemente pomou kojih manipuliemo elementimaWorkspacea:perspektive, editore i poglede (views). Svrha editora je jasna, s tim to editor koji se koristi zavisi od vrste fajla koja se edituje ukoliko Eclipse sadriplug-innamenjen editovanju date vrste fajla, on e biti korien, a ukoliko to nije sluaj, Eclipse e pokuati da fajl otvori aplikacijom koju tom tipu fajla dodeljuje operativni sistem. Pogledi predstavljaju komponente koje prikazuju neku vrstu informacija oWorkbenchu. Kao primere pogleda moemo navesti pogled koji prikazuje hijerarhiju projekata, foldera i fajlova, ili pogled koji prikazuje listu greaka i upozorenja koja se generiu prilikom kompajliranja programa. Na kraju, kombinacije pogleda i editora formiraju perspektive koje korisnici mogu proizvoljno aranirati prema svojim potrebama. Tako kod razvoja Java aplikacija postoje dve predefinisane perspektive,JavaiDebug.Prva je prilagoena pisanju aplikacija, dok druga slui za njihovo debagovanje. Korisnik moe proizvoljno menjati perspektive i po elji dodavati nove, kako bi radno okruenje maksimalno prilagodio svojim afinitetima.

Kada se naviknete na pomalo specifino radno okruenje, vreme je da otkrijete kako izgleda rad u njemu. Kao primer emo navesti razvoj Java aplikacije, ali veina stvari koje emo navesti vai i za veinu podranih programskih jezika. Bojenje kljunih rei (syntax coloring) neto je to predstavlja standard, uz mogunost da korisnik podesi boje za svaki jezik prema svojim potrebama. Pored toga to vodi rauna o bojenju teksta koji korisnik kuca, editor istovremeno vri sintaksnu proveru kda, na vreme upozoravajui korisnika na greke. Automatsko dopunjavanje kda pokree se kada pristupate lanicama klasa, a mogue ga je inicirati i runo, korienjem kombinacije taster CTRL i Space. Klase koje ste upravo kreirali bivaju trenutno ubaene u sistem za dopunjavanje kda, tako da su vam odmah na raspolaganju. Ovo moda i nije naroita novost kada su Java IDE-ovi u pitanju, ali ako napomenemo da istu funkcionalnost nudi iplug-inza JavaScrit ili PHP, to ve menja stvari. Vrlo lepa stvar kod Eclipsea je i to to pored predloenih dopuna vidimo i informacije izhelpavezane za dopunu. Sve ove mogunosti, naroito automatska dopuna kda, u prethodnim verzijama Eclipsea umele su da uspore program do neupotrebljivosti, ali po ovome to smo videli, nova verzija je viestruko bra i ovakvih problema nema. Automatsko popunjavanje komentara funkcija i klasa takoe je veoma lepo izvedeno, tako da je pravljenje dokumentacije kda pravo zadovoljstvo na osnovu deklaracije funkcije, Eclipse e vam momentalno pripremititemplatekoji samo treba popuniti. Pored reanja prozora editora po tabovima, nova verzija Eclipsea nudi i mogunost paralelnog prikaza prozora, to je dobra mogunost za korisnike sa irokim monitorima. Refaktoring kda je doveden na sasvim novi nivo, tako da je pored klasinog refaktoringa mogue pisati i skriptove u ovu svrhu, pratiti i menjati istoriju refaktoringa i jo puno toga.

Java razvojna okruenja su komfor u programiranju, barem u tom programskom jeziku, dovela na sasvim novi nivo. Eclipse taj komfor uvodi u druge programske jezike, ali i u primene koje nemaju veze sa programiranjem, istovremeno omoguavajui da (skoro uvek) sve svoje poslove moemo obavljati iz samo jednog okruenja.

Dejan STEFANOVI