Diploma lektorirana

Transkripcija

1 Dušan Fugina IMPLEMENTACIJA ODJEMALCA SISTEMA ZA UPRAVLJANJE RAZLIČIC»SUBVERSION«Diplomsko delo Maribor, september 2009

2 I Diplomsko delo univerzitetnega študijskega programa Študent: Študijski program: Smer: Mentor: Dušan Fugina Računalništvo in informatika Informatika doc. dr. Gregor Polančič, univ. dipl. inž. Maribor, februar 2009 UNIVERZA V MARIBORU

3 II (ime fakultete oz. visoke strokovne šole) Številka: Datum: SKLEP O DIPLOMSKEM DELU 1., študent univerzitetnega (visokošolskega strokovnega) študija, izpolnjuje pogoje, zato se mu dovoljuje izdelati diplomsko delo. 2. Tema diplomskega dela je s področja katedre/oddelka/inštituta, pri predmetu. Mentor: Somentor: 3. Naslov diplomskega dela: 4. Vsebina diplomskega dela: 5. Diplomsko delo je potrebno izdelati skladno z»navodili za izdelavo diplomskega dela«in ga oddati v izvodih do v referatu za študentske zadeve. Predstojnik katedre/oddelka/inštituta: Mentor: Dekan:

4 III ZAHVALA Zahvaljujem se mentorju za pomoč in vodenje pri opravljanju diplomskega dela.

5 IV IMPLEMENTACIJA ODJEMALCA SISTEMA ZA UPRAVLJANJE RAZLIČIC»SUBVERSION«Ključne besede: sistem Subversion, SVN, SVNKit, upravljanje konfiguracije, upravljanje različic, element konfiguracije. UDK: 659.2:004(043.2) Povzetek Razvoj informacijskih sistemov je kompleksen proces. Med mnogimi orodji, ki nam pomagajo obvladovati ta proces, so orodja za upravljanje različic, izmed katerih sodi med najbolj pogosto uporabljeno orodje sistem Subversion. Eden izmed razlogov za široko uporabo slednjega, je množica različnih uporabniških vmesnikov, s katerimi poenostavimo uporabo sistema in povečamo dostopnost sistema. Razlog za veliko število uporabniških vmesnikov gre iskati v dobro definirani zgradbi modulov iz katerih je sistem sestavljen, ter v programskih vmesnikih za različne programske jezike, s katerimi je relativno preprosto implementirati uporabniški vmesnik. V diplomskem delu bomo spoznali programski vmesnik SVNKit, s katerim bo implementiran preprost uporabniški vmesnik.

6 V IMPLEMENTATION OF A CLIENT APPLICATION FOR VERSION CONTROL SYSTEM»SUBVERSION«Key words: Subversion, SVN, SVNKit, Configuration Management, Revision Control, Version Control. UDK: Abstract Information system developing is a complex process. Among many tools that help us manage that process are version control systems. One of the most widely used tools in this category is Subversion. Variety of client applications is one of the reasons for ease of use and increased accessibility of this system. The reason for variety of client application can be found in good structure of system and many application programming interfaces (APIs) for different program languages. APIs can make implementing new solutions easy. The objective of this work is to present SVNKit API and develop a simple client application using this API.

7 VI KAZALO VSEBINE 1 UVOD Opredelitev problema Teza diplomskega dela Struktura diplomskega dela UPRAVLJANJE KONFIGURACIJE IN SISTEMI ZA UPRAVLJANJE RAZLIČIC Upravljanje konfiguracije Kaj je sistem za upravljanje različic? Centraliziran model Distribuirani model Koncepti upravljanja različic Repozitorij Kaj naj se shranjuje? Delavne kopije in upravljanje datotek Projekti, mape, datoteke Različice Številčenje Oznake (tags) Vejitve (branching) Združevanje Možnosti zaklepanja datotek SISTEM SUBVERSION Zgodovina Značilnosti Arhitektura sistema Nivo strežnika... 23

8 VII Nivo odjemalca Možnosti za razširitev SVN SVNKit - PROGRAMSKI VMESNIK ZA SVN Uporaba sistema SVN Programski vmesnik za programski jezik C Sloj repozitorija (repository layer) Sloj dostopa do repozitorija (repository access layer) Sloj odjemalca (client layer) Uporaba SVN v ostalih programskih jezikih Kaj je SVNKit Arhitektura SVNKit-a Nižji nivo vmesnika Višji nivo vmesnika RAZVOJ LASTNE REŠITVE Z UPORABO SVNKit-a Opredelitev problema in analiza zahtev Statični vidik Scenariji uporabe Implementacija rešitve Razvojno okolje Uporabljene knjižnice Zahteve za izvajalno okolje UGOTOVITVE ZAKLJUČEK LITERATURA... 58

9 VIII SLIKE Slika 1.1: Število namestitev sistema Subversion Slika 2.1: Upravljanje konfiguracije. [16]... 7 Slika 2.2: Tipičen primer sistema odjemalec/strežnik. [1]... 9 Slika 2.3: Repozitorij in delovne kopije. [2] Slika 2.4: Številke revizij v repozitoriju. [2] Slika 2.5: Glavna veja razvoja. [2] Slika 2.6: Glavna veja s stransko vejo. [2] Slika 2.7: Rešitev zakleni-spremeni-odkleni. [1] Slika 2.8: Rešitev kopiraj-spremeni-združi. [1] Slika 2.9: Rešitev kopiraj-spremeni-združi. [11] Slika 3.1: Arhitektura SVN. [1] Slika 3.2: Revizije. [11] Slika 4.1: Struktura knjižnice SVNKit Slika 5.1: Diagram primerov uporabe Slika 5.2: Razredni diagram Slika 5.3: Grafični vmesnik aplikacije

10 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 1 1 UVOD 1.1 Opredelitev problema Razvoj informacijskih sistemov je timsko delo, ki zahteva tesno sodelovanje strokovnjakov, informatikov in uporabnikov. Pri razvoju skozi celotni življenjski cikel informacijskega sistema, nastaja množica izdelkov (dokumentacija, načrti, programski kod, navodila za uporabo in drugo), ki se neprestano spreminjajo. Te izdelke lahko ustvarja in spreminja več ljudi. Pri množici izdelkov in razvijalcev, ki te izdelke neprestano ustvarjajo, spreminjajo in brišejo, se lahko brez primernega sistema izgubi nadzor nad njimi. Pride lahko do raznih nekonsistentnosti (prepisovanje kode, ki jo istočasno obdeluje več ljudi; nezmožnost vračanja v prejšnje, boljše stanje ali pa ni razvidno, kdo opravlja spremembe). Potreben je sistem, ki koordinira delo z izdelki. Torej sistem, ki hrani izdelke na prostoru, ki je dostopen vsem tistim, ki sodelujejo na projektu in imajo za to dovoljenje; sistem, ki hrani zgodovino izdelkov in s tem omogoča vračanje oz. vpogled v predhodno stanje izdelka ter vsebuje mehanizem za preprečevanje (nenamernega) prepisovanja izdelkov različnih avtorjev. V procesu razvoja programske opreme lahko s skrbno izbrano programsko opremo in doslednim uporabljanjem le-te, povečamo sledljivost procesa razvoja programske opreme, prispevamo k večji splošni varnosti, k učinkovitemu sodelovanju, k organizaciji gradnikov, k odgovornosti oseb in k dostopu iz oddaljenih lokacij. Takšni sistemi obstajajo in se imenujejo sistemi za upravljanje različic. Takšni sistemi so tudi neke vrste sledilni mehanizmi, saj lahko z njimi preverimo potek razvoja izdelkov v primeru, da bi med delom prišlo do nepravilnosti. Na trgu obstaja več sistemov za upravljanje različic. Najhitreje rastoč odprtokodni sistem za upravljanje različic je sistem Subversion. Zamenjal je najbolj razširjen odprtokodni sistem za upravljanj različic CVS. Subversion je izdan pod licenco Apache/BSD 1. Danes se več kot 1,75 milijona razvijalcev zanaša na Subversion (slika 1.1). Od izida prve produkcijske različice leta 2004, se število uporabnikov neprekinjeno povečuje, kar je, predvsem za programsko opremo razvito v odprti skupnosti 2, odličen dosežek. 1 Pridobljeno , iz 2»community-developed«- Pridobljeno iz

11 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 2 Slika 1.1: Število namestitev sistema Subversion 3. 3 Na javnih strežnikih Apache, ki imajo nameščen modul mod_dav_svn, ki omogoča uporabo sistema Subversion na daljavo [14].

12 Implementacija odjemalca sistema za upravljanje različic»subversion«stran Teza diplomskega dela Kljub temu da uporaba sistema za upravljanje različic daje vtis nepogrešljivosti, je veliko delovnih skupin in posameznikov ne uporablja. Razlogov za neuporabo je lahko več: (a) teorija se težko prenese v prakso, (b) problema se lotimo preveč rigorozno in preveč kompleksno, tako da je tudi za vpeljavo najpreprostejših opravil potrebno veliko časa in truda (v takšnih primerih se sčasoma opusti raba koristnega orodja), (c) ni primernega uporabniškega vmesnika (programa), s katerim bi se na enostaven način vključili v sistem za upravljanje različic ali širše v sistem za upravljanje konfiguracije. Kadar je razlog za neuporabo neprimeren uporabniški vmesnik, se lahko vprašamo zakaj je temu tako. Eden izmed odgovorov bi lahko bil zaprt sistem, za katerega uporabniške programe lahko pišejo samo znotraj podjetja, ki izdeluje sistem ali ostali izdelovalci programske opreme, ki kupijo licenco za izdelavo oziroma dopolnjevanje programske opreme. Tudi v tem primeru lahko pride do težav, če sistem ni izdelan za razširjanje in spreminjanje funkcionalnosti. V primeru sistema Subversion nobena izmed zgoraj navedenih slabosti ne drži. Sistem ima odprtokodno licenco, poleg tega je arhitektura sistema dovršena do te mere, da na enostaven način gradimo dodatne uporabniške vmesnike v različnih programskih jezikih, poleg tega pa lahko tudi dopolnjujemo ali popravljamo osnovno zgradbo sistema, če bi to bilo potrebno. Iz zgornjih odstavkov je nastala tudi teza diplomskega dela, ki da na preizkus programski vmesnik SVNKit, s katerim je mogoče na enostaven način razviti uporabniški vmesnik. Kot delni dokaz tej trditvi, je lahko že množica do sedaj razvitih uporabniških vmesnikov na strani odjemalca 4. Teza diplomskega dela je naslednja: Z uporabo programskega vmesnika sistema Subversion, je mogoče na relativno preprost način izdelati odjemalca Subversion, ki poenostavi uporabo in poveča dostopnost sistema Subversion. Cilji diplomskega dela je pokazati, do kakšne mere drži zastavljena teza. Da bi se dokopali do tega cilja, se bomo (1) seznanili z osnovnimi pojmi in funkcijami sistemov za upravljanje različic, (2) spoznali osnovno arhitekturo sistema Subversion, (3) spoznali programski vmesnik SVNKit za 4

13 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 4 programski jezik Java in (4) izdelali preprost, funkcionalen in uporaben uporabniški vmesnik v jeziku Java z uporabo programskega vmesnika SVNKit. Z opisanimi znanji in s pridobljenimi izkušnjami bomo preverili tezo diplomskega dela. Ker bo presoja v večji meri subjektivne narave, si bomo delo olajšali s tremi splošnimi kriteriji, izvzetimi iz teze. Kriterije bomo po principu»topdown«razgradili na pod-kriterije in na koncu v obratnem vrstnem redu preverjali, do kakšne mere držijo posamezni kriteriji. Ta način nas bo pripeljal do potrditve, delne potrditve ali zavrnitve teze. Kriteriji so sledeči: 1 Implementacija (funkcij) programskega vmesnika SVNKit je relativno preprosta. 1.1 Uporabniško aplikacijo je mogoče izdelati samo z uporabo jezika Java ter programskega vmesnika SVNKit, brez zunanjih klicev drugih vmesnikov za sistem Subversion. 1.2 Programski vmesnik je dobro dokumentiran, kar vključuje: opis sestavnih delov vmesnika: paketov, razredov, vmesnikov, izjem, metod primere uporabe posameznih delov vmesnika opise primerov uporabe splošne (celostne) primere uporabe primere izdelave konkretne aplikacije 1.3 Za implementacijo funkcij, je potrebno poznavanje programiranja v jeziku Java, ki vključuje: poznavanje splošnih principov programiranja poznavanje principov jezika Java poznavanje dela s programskim okoljem NetBeans 2 Uporaba aplikacije bo poenostavila uporabo sistema Subversion. 2.1 Aplikacija bo namenska, zato bo vsebovala majhen nabor funkcionalnosti, ki so nujno potrebne za uresničitev cilja in vključujejo: brskanje po repozitoriju izključitev datoteke vključitev poprej izbrane in popravljene datoteke 2.2 Pregleden in preprost grafični vmesnik: vmesnik s prepoznavnimi ikonami vse funkcije dosegljive iz ene forme 5 Mesto, navadno na strežniku, kjer se hranijo podatki.

14 Implementacija odjemalca sistema za upravljanje različic»subversion«stran pomoč 2.3 Programa ne bo potrebno nameščati na sistem. 3 Uporabniška aplikacija bo povečala uporabnost. 3.1 Do sistema Subversion lahko dostopamo preko lokalnega omrežja ali svetovnega spleta preko različnih protokolov: http SVN lokalni dostop 3.2 Uporabnik nastavi minimalno število nastavitev: naslov repozitorija uporabniško ime in geslo delovna mapa na lokalnem računalniku 1.3 Struktura diplomskega dela Diplomsko delo po uvodnem delu, v drugem poglavju z naslovom»upravljanje konfiguracije«, obravnava definicijo pojma sistema za upravljanje konfiguracije in splošno predstavitev, kaj so sistemi za upravljanje konfiguracije. Nadalje, v istem poglavju, so na splošno opisani različni sistemi za upravljanje različic. Navedeno je, kakšna je razlika med sistemom za upravljanje različic in sistemom za upravljanje konfiguracije ter možnosti, ki jih ponujajo taki sistemi. V tretjem poglavju bo podrobneje predstavljen konkretni sistem za upravljanje različic sistem Subversion (v nadaljevanju SVN). Opisana bo zgradba sistema, na kakšen način hranimo podatke v repozitoriju in način dostopa do repozitorija. V četrtem poglavju sta predstavljena programska vmesnika za SVN. Opisana sta vmesnik za programski jezik C in Java knjižnica SVNKit. V petem poglavju je predstavitev programske rešitve. V zadnjem poglavju so navedeni zaključki in ideje za nadaljnje delo s SVN, ki so nastale ob pisanju diplomskega dela.

15 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 6 2 UPRAVLJANJE KONFIGURACIJE IN SISTEMI ZA UPRAVLJANJE RAZLIČIC 2.1 Upravljanje konfiguracije Upravljanje konfiguracije 6 se uvršča v področje upravljanja, ki se ukvarja z vzpostavitvijo in vzdrževanjem kakovosti proizvoda in njegovih funkcionalnih in fizičnih lastnosti v skladu z zahtevami, načrtovanjem in operativnimi cilji skozi njegov življenjski cikel [15]. Proces upravljanja konfiguracije je prepoznaven kot eden (boljših) načinov upravljanja sprememb pri razvoju proizvoda. Proces prepoznava funkcionalne in fizične lastnosti proizvoda v različnih fazah razvoja in izvaja sistematičen nadzor sprememb, z namenom vzdrževanja integritete in sledljivosti skozi celoten življenjski cikel. [6] V informacijski tehnologiji in telekomunikacijah je pojem upravljanje konfiguracije zajet v mnogih definicijah. Navedene so nekatere izmed njih: Nadzor in prilagajanje razvoja kompleksnih sistemov. Je disciplina razvoja programskih produktov pod nenehnim nadzorom. S tem je prispevano h kakovosti in odpravi zamud. Upravljanje konfiguracije programske opreme 7 delimo na dve področji. Prvo, starejše področje, včasih imenovano tudi upravljanje komponent repozitorija 8, se nanaša na hranjenje entitet (elementov konfiguracije), ki nastanejo med razvojem programske opreme. Drugo področje se nanaša na aktivnosti za produkcijo in spremembo entitet [8]. Osnovni namen je formalen nadzor celovitosti elementov konfiguracije in aktivnosti [9]. Upravljanje razporeditve delov oz. elementov sistema [10]. Iz navedenih definicij lahko strnemo, da proces upravljanja konfiguracije zahteva sledenje spremembam in preverjanje skladnosti dobljenega proizvoda z začetnimi specifikacijami. S tem ciljem se v procesu izvaja sistematičen razvoj, ki izvaja štiri aktivnosti (slika 2.1): identifikacijo, nadzorovanje, 6 Konfiguracija je skupek vseh posameznih elementov, ki sestavljajo nek proizvod in jih formalno obvladujemo, ter je odvisna od faze razvoja v kateri se nahaja proizvod. Konfiguracija predstavlja funkcionalne in fizične karakteristike strojne in programske opreme, kot je vnaprej določeno v razvojni dokumentaciji ali kot je doseženo v končnem proizvodu [5]. 7 software configuration management - SCM 8 component repository management

16 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 7 spremljanje statusa in presojanje proizvodov v času od njihove konceptualne faze do faze dobave in vzdrževanja [10]. Upravljanje konfiguracije lahko apliciramo na razna področja v industriji, vendar se bo v diplomskim delu obravnavalo le področje razvoja programske opreme, v katerem se uporablja strokovni pojem upravljanja konfiguracije programske opreme 9 (v nadaljevanju besedila: upravljanje konfiguracije). Slika 2.1: Upravljanje konfiguracije. [16] 2.2 Kaj je sistem za upravljanje različic? Sistem za upravljanje različic je orodje, ki omogoča shranjevanje različnih revizij 10 elementov konfiguracije 11 med razvojem aplikacije. Sistem za upravljanje konfiguracije uporablja sistem za upravljanje različic, da doseže svoj tehnični cilj. Običajno se uporabljajo v inženirstvu in pri razvoju programske opreme za upravljanje razvoja digitalnih izdelkov, kot so programski kod, kosovnice, elektronski modeli in ostali pomembni produkti, in so nepogrešljivi pri projektih, kjer je delovna skupina velika. Spremembe teh izdelkov se beležijo kot povečanje številke revizije in so povezane z osebo, ki je spremembo prijavila. 9 software configuration management 10 Revizija je nova verzija izdelka, ki je nadomestila predhodno verzijo izdelka. 11 Elementi konfiguracije so samostojne entitete v procesu upravljanja konfiguracije, ki predstavljajo delovni proizvod, ki ga vključimo v upravljanje konfiguracije [5].

17 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 8 Področje sistemov za upravljanje različic obsega vključevanje/izključevanje (sprememb) elementov konfiguracije, označevanje in vejitve programskega koda ter zmožnost prevajanja, povezovanja in pakiranja proizvoda. Upravljanje sprememb omogoča ponoven priklic kateregakoli stanja v procesu razvoja (posnetek stanja), kar nam omogoča ponovljivost postopkov v obliki, kot so bili v trenutku posnetka [7]. Sisteme za upravljanje različic poznamo kot samostojno programsko opremo, vendar jo najdemo tudi kot del različnih vrst programske opreme: urejevalniki besedil, preglednice, sistemi za upravljanje vsebin, IDE orodja, sistemi za upravljanje konfiguracije in drugo. Ker se pojma sistem za upravljanje različic in sistem za upravljanje konfiguracije pogosto zamenjujeta, poudarimo razliko med njima. Medtem ko je sistem za upravljanje različic orodje (programski produkt), je sistem z upravljanje konfiguracije proces izdelave produkta. Obstajata dva različna modela sistemov za upravljanje različic. Centraliziran model in distribuiran model. Vsak posebej sta predstavljena v naslednjih poglavjih Centraliziran model Tradicionalni sistemi za upravljanje različic uporabljajo centraliziran model, kjer se vse funkcije izvajajo na skupnem strežniku. Če dva uporabnika želita spremeniti isto datoteko naenkrat, lahko brez nekega mehanizma, ki upravlja te datoteke, prepišeta opravljene spremembe drug drugemu. Centraliziran model rešuje te težave na dva različna načina, ki bosta opisana v nadaljevanju. Ta dva načina sta rešitev z zaklepanjem datoteke (zakleni-spremeni-odkleni) in rešitev z združevanjem (kopiraj-spremeni-združi) [7]. V nadaljevanju (poglavje 2.3)bodo podrobneje predstavljeni elementi centraliziranega modela, ki jih najdemo tudi v SVN. Le-ta spada med centralizirane modele Distribuirani model Distribuirani model uporablja pristop vsak z vsakim, kar pomeni da ni centralnega repozitorija, kjer se hranijo elementi konfiguracije. Namesto enega repozitorija, kjer se usklajujejo elementi konfiguracije, vsak uporabnik svojo delovno kopijo po potrebi združi z drugim posameznikom. To prinese naslednje spremembe v primerjavi s centraliziranim modelom: Ne obstaja centralni repozitorij, ampak samo delovne kopije. Najbolj pogoste operacije (vključevanje, pogled zgodovine, vračanje v prejšnja stanja) so hitrejše, ker ni potrebne povezave s centralnim repozitorijem.

18 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 9 Vsaka delovna kopija je tudi varnostna kopija, kar je naravni sistem proti izgubi podatkov. Obstajata dve vrsti distribuiranih modelov: zaprti in odprti. Odprti model je bolj primeren za razvoj odprtokodnih sistemov, zaprti model je bolj tradicionalno usmerjen [7]. V tej nalogi se ne bomo osredotočali na ta model. 2.3 Koncepti upravljanja različic Repozitorij Repozitorij predstavlja shrambo elementov konfiguracije, ki jih navadno gosti osrednji strežnik sistema za upravljanje različic. Slika 2.2: Tipičen primer sistema odjemalec/strežnik. [1] V večini sistemov za upravljanje različic je repozitorij središčno mesto, ki hrani kopije vseh različic izdelkov projekta. V nekaterih sistemih repozitorij hrani podatke v bazi podatkov, v drugih hrani podatke v množici navadnih datotek, nekateri pa uporabljajo kombinacijo obojega. Tako ali drugače je repozitorij osrednja komponenta sistemov za upravljanje različic in prav zato ga je potrebno namestiti na varen in zanesljiv računalnik ter slediti primerni varnostni politiki. Nedolgo nazaj so si uporabniki in repozitorij delili računalnik (repozitorij je bil vedno na računalniku, ki ga je uporabnik uporabljal) ali vsaj datotečni sistem. To se je izkazalo za zelo omejujoče. Razvijalci

19 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 10 so za delo na drugem računalniku morali prenesti izdelke, zato je bilo težko delati na različnih mestih, različnih računalnikih in različnih operacijskih sistemih. Ta težava se danes rešuje prav s centralnim repozitorijem, do katerega v največ primerih dostopamo preko omrežja (internet, intranet), lahko pa tudi lokalno. Za povezavo med repozitorijem in odjemalcem skrbi strežnik, ki je lahko ločen od repozitorija. V primeru SVN je strežnik ločen od repozitorija. V tem trenutku lahko izbiramo med dvema implementiranima strežniškima rešitvama:»http Apache«spletni strežnik z modulom»mod_dav«ali posebej za to priložnost implementiran»svnserve«strežnik. S tem je omogočen trajen dostop do izdelkov projekta in njihove zgodovine. Navedeno privede do zanimivega vprašanja. Kaj storiti v primeru, ko bi uporabniki radi spreminjali izdelke in nimajo dostopa do repozitorija? Nekateri sistemi za upravljanje različic so uporabni samo takrat, kadar so povezani z repozitorijem (online). Domneva se, da je uporabnik (programer, razvijalec) ves čas povezan z repozitorijem in kode ni mogoče spreminjati, ne da bi se prej povezal s centralnim repozitorijem. Drugi sistemi omogočajo spreminjanje datotek tudi kadar uporabniki niso povezani z repozitorijem. Razvijajo oz. spreminjajo lahko datoteke in uskladijo spremembe šele, ko se povežejo s strežnikom (repozitorijem). Možnost online/offline dela je ključna pri izbiri sistema upravljanja različic. Nekateri sistemi za upravljanje različic omogočajo več decentraliziranih repozitorijev, namesto enega centralnega. V takem primeru lahko razvijalci menjujejo množico sprememb med različnimi repozitoriji. Ta možnost je uporabna, kjer večje število razvijalcev razvija na pol avtonomno, neodvisno drug od drugega. Najbolj znan primer takšnega delovanja, je razvoj jedra Linuxa. Ostali primer so: BitKeeper, Arch in SVK. Ti sistemi imajo zelo različne stile razvoja Kaj naj se shranjuje? Vsi elementi konfiguracije (izdelki) projekta so shranjeni v repozitoriju. Toda kaj točno štejemo za elemente konfiguracije? Najbolj očiten primer je programski kod: Java, C# ali katerikoli programski jezik, v katerem pišemo aplikacijo. Programski kod je vsekakor pomemben, vendar če omenjamo le programski kod, pozabljamo na ostale, prav tako pomembne zapise in izdelke, ki se hranijo (skripte, metapodatke, testne podatke, dokumentacijo, sestanke ). To pomeni katerekoli dele projekta, ki se spreminjajo v času razvoja Delavne kopije in upravljanje datotek Delovna kopija je lokalna kopija elementov konfiguracije. Lokalno kopijo izdelkov potrebujemo za delo na svojem delu projekta. Za manjše do srednje velike projekte je delovna kopija kar ves programski kod in ostali izdelki projekta. Za večje projekte lahko uredimo stvari tako, da dela

20 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 11 razvijalec na delu programskega koda projekta in s tem izolira podsistem od celotnega sistema. Delovno kopijo lahko tako poimenujemo tudi delovna mapa ali delovni prostor. Da pridemo do delovne kopije, moramo prenesti elemente konfiguracije iz repozitorija. Različni sistemi upravljanja različic imajo različna poimenovanja za ta proces. Najbolj pogosto se pojavlja pojem izključitev (check out). Ko izvedemo operacijo izključitve, iz repozitorija prenesemo elemente konfiguracije v delovno kopijo. Tudi v primeru, ko delamo na istem računalniku, kjer se nahaja repozitorij, moramo datoteke, ki jih želimo uporabljati, izključiti. Repozitorij je obravnavan oz. viden kot črna skrinja. Operacija izključitve zagotavlja, da dobimo poljubno različico datotek, ki jih zahtevamo in da je ta kopija zrcalna tisti v repozitoriju. Navadno izključujemo zadnje aktualne različice izdelkov, vendar to ni pravilo. Slika 2.3: Repozitorij in delovne kopije. [2] Obstaja tudi možnost izvoza (export) datotek iz repozitorija, ki je drugačna operacija od izključitve. Ko se datoteka izvaža, ne dobimo delovne kopije, temveč trenutni posnetek datotek iz repozitorija, kjer se ne beležijo spremembe. To je koristno v raznih primerih, recimo pri pakiranju kode za distribucijo. Med delom spreminjamo projekt na delovni kopiji. Zaradi tega Spremembe hranimo v repozitorij. Razlog za to je lahko strah pred izgubo podatkov, končano delo, objava sprememb v repozitorij Vse to z namenom, da ostali člani projekta vidijo spremembe. Temu procesu se reče vključitev (commit, check-in) sprememb v repozitorij. Medtem ko mi spreminjamo elemente konfiguracije, tudi ostali člani tima spreminjajo elemente konfiguracije. Tudi oni vključujejo svoje spremembe v repozitorij. Te spremembe se ne odražajo na lokalnih delovnih kopijah drugih razvijalcev. Če želimo posodobiti svojo lokalno kopijo z

21 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 12 spremembami drugih razvijalcev, moramo sistemu upravljanja različic poslati ukaz posodobi (update). S tem prenesemo v lokalno okolje zadnjo različico datotek iz repozitorija. V takšnem primeru pa se lahko zgodi, da isti izdelek spreminjata dva člana delovne skupine in se spremembe prekrivajo. Ti dogodki niso redki, naloga sistema za upravljanje različic je, da ti dogodki ne ostanejo neopaženi in da jih reši. Različni sistemi upravljanja različic ta problem rešujejo na različne načine, ki bodo razloženi v nadaljevanju (poglavje 2.3.9) Projekti, mape, datoteke Do sedaj je bil opisan sistem shranjevanja elementov konfiguracije, ni pa bilo opisano, kako so le-ti organizirani. Na najnižjem nivoju se večina sistemov za upravljanje različic sooča z datotekami. Vsaka datoteka ima ime in je shranjena v repozitoriju; če dodamo v repozitorij datoteko»helloworld.java«, bodo lahko ostali člani delovne skupine izključili»helloworld.java«v svoje delovne kopije. Projekti po navadi vsebujejo večje število datotek. Pogosto tudi sto, tisoč ali še več. Podjetje lahko ima več projektov, ki se izvajajo istočasno. Na srečo skoraj večina sistemov omogoča strukturiranje repozitorija. Na najvišjem nivoju je delo razporejeno po projektih. Znotraj projektov je delo deljeno v module in sub-module. Repozitorij sistema SVN te module in sub-module vidi kot navadne mape. V vlogi projekta je mapa na najvišjem nivoju, nižje ležeče mape pa lahko enačimo z moduli Različice Repozitorij ni zadolžen samo za hranjenje trenutnih (zadnjih) kopij datotek, temveč hrani vsako različico, ki je bila kadarkoli vključena. Če torej izključimo datoteko, jo popravimo in nato ponovno vključimo, bo repozitorij obdržal originalno različico in različico s spremembami. Večina sistemov za upravljanje različic hrani samo razlike med dvema sosednjima različicama, namesto celih kopij revizij Številčenje Obstajata dva načina številčenja različic za sisteme upravljanja različic: Vsaka vključitev spremeni revizijo vsaki datoteki posebej. Prva revizija datoteke je imenovana 1.1. Ko je sprememba vključena, se datoteki dodeli število 1.2, ITD. Če imamo datoteko»krog.java«v različici 1.2 in datoteko»kvadrat.java«v različici 1.5 in potrdimo spremembo v»krog.java«, le-ta dobi oznako 1.3 (slika 2.1). Vsaka vključitev spremeni revizijo repozitorija. Cel repozitorij začne z revizijo 0. Vključitev spremembe dvigne številko različice celega repozitorija na 1, nato na 2, itd. Pri tej shemi je bolj pravilno govoriti o»krog.java«v reviziji 7, kot revizija 7 datoteke»krog.java«.

22 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 13 Sistem SVN uporablja drugo shemo številčenja različic, kar se v praksi kaže kot zelo učinkovito. Slika 2.4: Številke revizij v repozitoriju. [2] CVS uporablja prvo shemo številčenja. Tukaj lahko uporabniki direktno vidijo koliko aktivnosti se dogaja na eni datoteki. Uporabniki SVN morajo za to uporabiti ukaz log, ki pregleda spremembe v repozitoriju za določeno datoteko. Številčenje SVN ni namenjeno razbiranju števila sprememb v določeni datoteki ali skupini datotek. Ljudje, navajeni na ta način številčenja (file-specific), so pogosto zmedeni, ko se revizijska številka poveča, ne da bi sami kaj spreminjali. Šele ko vidimo, da so bili druge datoteke spremenjene, je sprememba revizij razumljiva Oznake (tags) Z oznakami dodelimo ime skupini datotek (ali mapam ali celotnemu projektu) v določeni točki v času, to pomeni v določeni reviziji. Tako se lahko namesto s številko revizije sklicujemo z nekim bolj pomenskim besedilom. Ko izvajamo izključitev določene revizije, prav tako uporabljamo ime oznake namesto številke revizije. Oznake so odličen način za označevanje pomembnih dogodkov v življenjskem ciklu razvojne kode Vejitve (branching) Pri običajnem poteku dela si uporabniki delijo skupne elemente konfiguracije (izdelke), čeprav verjetno delajo na različnih delih projekta. Razvijalci izključijo kodo, nato spreminjajo svojo delovno kopijo in jo potem vključijo. Ta del izdelkov v razvoju, se imenuje glavna veja (trunk)(slika 2.1).

23 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 14 Slika 2.5: Glavna veja razvoja. [2] Poglejmo situacijo, pred izdajo nove različice programa. Del skupine razvijalcev pripravlja program za izid različice. V tem občutljivem obdobju potrebujejo stabilnost. Ne sme se zgoditi, da bi ostali razvijalci, ki nadaljujejo z razvojem, popravljali kodo in dodajali nove funkcionalnosti. Ponuja se več možnosti za rešitev tega problema: Med postopkom finaliziranja te različice, lahko zamrznemo razvoj novih različic. To pomeni, da preostali del tima ostane brez dela. Prekopiramo kodo na drugo lokacijo. Skupina, ki zaključuje delo za različico, dela na tem delu kode. Kaj pa se zgodi s spremembami po koncu razvoja različice? Kako jim sledimo? Razvoj lahko razdelimo v dve ločeni vzporedni veji. Temu načinu se reče vejitev (branching). (slika 2.6). Slika 2.6: Glavna veja s stransko vejo. [2] Nova veja v sistemu Subversion je, kot bi imeli ločen repozitorij. Uporabniki, ki uporabljajo to vejo, vidijo izdelke, ki jo vsebujejo, neodvisno od uporabnikov, ki uporabljajo kodo v drugih vejah ali glavni

24 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 15 veji. Vsaka veja ima svojo zgodovino in vodi spremembe neodvisno od glavne veje. Vsaka veja ima svojo zgodovino od točke, kjer se veji razvoj razide. Od te točke v preteklost je zgodovina skupna. Dejansko vejitev pomeni, da se ustvari notranja povezava, ki kaže na specifično revizijo, kjer se veji ločita. Rezultat tega je zelo hitro potekanje operacije vejitve. Poleg tega ne zasede dodatnega prostora, kot bi ga navadno kopiranje datotek Združevanje Privzemimo, da Janko dela na glavni veji projekta in da Metka dela na vzporedni veji projekta. Kljub ločenemu razvoju, lahko v eni veji najdemo napako, ki obstaja tudi v glavni veji. Sistem SVN nam ponuja možnost selektivnega kopiranja med vejami. To imenujemo združevanje Možnosti zaklepanja datotek Vsi sistemi za upravljanje različic morajo rešiti osnovno vprašanje, ki ga opredeljuje problem:»kako naj sistem uporabnikom dovoljuje skupno rabo informacij in jim pri tem prepreči prepisovanje dela drugih?«rešitev zakleni-spremeni-odkleni Na ta način lahko v danem trenutku samo ena oseba spreminja datoteko. To ekskluzivno pravico dosežemo z zaklepanjem datoteke. Preden želimo spremeniti datoteko, jo moramo zakleniti. Če želi kdo drug v tem času popravljati datoteko, torej jo zakleniti, tega ne more storiti. Vse kar lahko dela med tem časom, je branje datoteke, dokler je prava oseba ne odklene. Ta način imenujemo tudi striktno zaklepanje (slika 2.7).

25 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 16 Slika 2.7: Rešitev zakleni-spremeni-odkleni. [1] Ta način je restriktiven in vodi do nekaterih praktičnih problemov: Povzroča administrativne probleme (uporabnik po končanem delu pozabi odkleniti datoteko). Lahko povzroči nepotrebno periodično obnavljanje - serializacijo (v kolikor en uporabnik ureja začetek datoteke, drug uporabnik ne more istočasno urejati konca). Lahko povzroči lažen občutek varnosti (v primeru, da dva razvijalca istočasno zakleneta in delata vsak na svoji datoteki, ki sta druga od druge odvisni, se v času dela ti dve datoteki ne osvežujeta. Razvijalca tako ne moreta zaznati sprememb, ki jih delata v odvisnih datotekah in zato svoje spremembe sprejemata kot ločeno nalogo. Zaklepanje velikokrat postane nadomestek za dejansko komunikacijo).

26 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 17 Rešitev kopiraj-spremeni-združi (Copy-Modify-Merge) V sistemu SVN, CVS-u in nekaterih ostalih sistemih se uporablja ta sistem kot alternativa striktnemu zaklepanju datotek. Imenuje se tudi optimistično zaklepanje. V tem načinu vsak uporabnik ustvari svojo delovno kopijo. Uporabniki lahko nato delajo vzporedno. Popravljajo lahko svoje delovne kopije. Če dva uporabnika spremenita isto datoteko, je potrebno združiti datoteki. Sistem pomaga pri združevanju, vendar se na koncu uporabniki odgovorni za pravilno združitev. Slika 2.8: Rešitev kopiraj-spremeni-združi. [1]

27 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 18 Slika 2.9: Rešitev kopiraj-spremeni-združi. [11] Kdaj je zaklepanje nujno? Medtem ko velja rešitev lock-modify-unlock kot splošno neustrezna pri sodelovanju večih uporabnikov, je v nekaterih primerih lahko ustrezna. Ta rešitev pride do veljave, kadar datotek ni mogoče združiti in to predvsem takrat, ko so datoteke v binarni obliki.

28 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 19 3 SISTEM SUBVERSION 3.1 Zgodovina Projekt Subversion je začela skupina razvijalcev, ki so imeli izdatne izkušnje s sistemom CVS. Vzroki za izdelavo novega sistema za upravljanje različic so bili med drugim staranje sistema CVS in posledično njegove pomanjkljivosti. Razvijalci so se zelo zavedali pomanjkljivosti sistema CVS in razvili visoko zmogljiv sistem za upravljanje različic. Njihov namen ni bil ustvariti popolnoma nove paradigme pri sistemih za upravljanje različic, saj se je CVS razvojni model izkazal kot zelo uspešen, ampak nadomestiti sistem CVS z novim sistemom, ki bo odpravil vse pomanjkljivosti sistema CVS. [2] Del ponudbe podjetja CollabNet 12 je tudi programski paket SourceCast, pri katerem je ena izmed komponent sistem za upravljanje različic. Kljub temu da je SourceCast uporabljal sistem CVS kot sistem za upravljanje različic, so bile pomanjkljivost sistema CVS znane od začetka in v CollabNet so vedeli, da bodo sčasoma morali najti boljšo rešitev. Navsezadnje je sistem CVS postal de-facto standard v odprto kodnih sistemih, predvsem zaradi tega, ker ni bilo boljšega produkta, vsaj ne med brezplačnim programjem. Zaradi tega se je CollabNet odločil, da napiše nov sistem za upravljanje različic, pri tem pa ohrani osnovne ideje sistema CVS brez hroščev in z dodatnimi funkcionalnostmi. V začetku leta 2000 je podjetje CollabNet pričelo iskati razvijalce za sistem, ki bi nadomestil sistem CVS. Februarja 2000 so sklenili pogodbo z Karlom Foglom, avtorjem odprto kodnega razvoja sistema CVS (Coriolis 1999), in ga povabili k sodelovanju pri novem projektu. Sočasno se je Karl s svojim prijateljem Jimom Blandyem že pogovarjal o novi različici sistema za upravljanje različic. Leta 1995 sta ustanovila družbo Cyclic Software, ki je nudila podporo CVS-u, in čeprav sta družbo kasneje prodala, sta CVS še nadalje uporabljala pri svojem delu. Zaradi pomanjkljivosti CVS-a je Jim začel razmišljati o boljših načinih upravljanja različic podatkov in ustvaril ime»subversion«, kakor tudi zasnovo za repozitorij. Ko je CollabNet Karla povabil k sodelovanju, je Karl nemudoma privolil. Jim je pridobil donatorja: RadHat Software. CollabNet je zaposlil Karla in Bena Collinsa-Sussmana in izčrpno delo se je pričelo v mesecu maju S pomočjo strokovnjakov Briana Behlendorja in Jasona Robbinsa iz CollabNeta in Grega Steina (v tistem času je bil neodvisen razvijalec za specifikacijo WebDAV/DeltaV protokola), je SVN hitro pritegnil skupino aktivnih programerjev. Začetna skupina razvijalcev sistema se je osredotočila na nekaj osnovnih ciljev. Niso si prizadevali odkriti novih 12

29 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 20 temeljev v metodologiji upravljanja različic, temveč samo popraviti napake sistema CVS. Odločili so se, da bo SVN ohranil lastnosti sistema CVS in enak razvojni model, odpravili pa bi naj najbolj očitne pomanjkljivosti sistema CVS. Kljub temu da SVN ni predstavljal popolnoma enakega nadomestila za sistem CVS, je vendarle moral biti dovolj podoben, da bi lahko vsak uporabnik sistema CVS prešel nanj brez težav. Po štirinajstih mesecih kodiranja, 31. avgusta 2001, je SVNSVN postal zrel za uporabo. Prvi so ga začeli uporabljati ravno razvijalci sami in s tem prešli iz prejšnjega sistema CVS. CollabNet je začel s projektom in še vedno plačuje pretežni del dela (izplačuje plače nekaterim polno zaposlenim razvijalcem SVN). SVN je, enako kakor drugi odprtokodni projekti, pogojen z ohlapnimi, vendar transparentnimi pravili, ki spodbujajo meritokriteto (boljši posamezniki napredujejo oz. vodijo razvoj). Licenca CollabNet-a za avtorske pravice je popolnoma v skladu z licenco Debian Free Software Guidelines. Z drugimi besedami, vsakdo lahko prosto kopira, spreminja in redistribuira SVN; za to ne potrebuje dovoljenja CollabNeta ali kogarkoli drugega. [2] 3.2 Značilnosti Ko je govora o lastnostih SVN, le-te običajno primerjamo z lastnostmi CVS sistema. SVN je nastal z namenom izboljšati lastnosti sistema CVS. Iz tega vidika lahko rečemo, da ima SVN večino lastnosti sistema CVS in vse tiste, ki so bile pri CVS pogrešane. Beleženje sprememb celotnega datotečnega drevesa. Medtem ko pri nekaterih sistemih za upravljanje različic (CVS) vodimo zgodovino samo datotekam, SVN beleži spremembe za celotno datotečno drevo (mape in datoteke), vključno z operacijami nad njimi (preimenovanje, kopiranje, premikanje, dodajanje, brisanje). Operacije z repozitorijem delujejo kot transakcija. Operacija vklapljanja in druge operacije, ki izvajajo spremembe v repozitoriju, delujejo kot transakcija. Izvede se celotna akcija, v primeru neuspeha se akcija razveljavi. Spremembe metapodatkov se beležijo. Vsaka mapa in datoteka ima lastnosti. Te lastnosti in njihove spremembe, se prav tako hranijo v repozitoriju, enako kot vsebina datotek in map. Različne omrežne implementacije za dostop do repozitorija. SVN omogoča različne implementacije dostopa do repozitorija. Trenutno sta poznani dve implementaciji, preko katerih lahko dostopamo do repozitorija. SVN lahko preko dodatnega modula priključimo na Apache spletni strežnik. SVN s tem pridobi na stabilnosti in interoperabilnosti, ki jih Apache kot zanesljiv in široko uporabljan spletni strežnik omogoča. Poleg tega imamo dostop do standardnih Apache lastnosti, kot so avtentikacija, avtorizacija, stiskanje podatkov in druge.

30 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 21 Drugi način dostopa do repozitorija preko omrežja je strežnik»svnserve«, ki je preprost in samostojen strežniški proces, ki uporablja svoj protokol. Ta strežnik omogoča osnovno avtentikacijo in avtorizacijo. Enostavno in hitro ustvarjanje novih vej razvoja in poimenovanja točk v razvoju. Stroški ustvarjanja novih vej v razvoju in poimenovanja določene različice v razvoju (oznak), ni nujno enakovredna velikosti projekta. SVN ustvarja nove veje in oznake s kopiranjem projekta, podobno kot trde povezave (hard-link) 13 pri sistemu UNIX. Čas za izvedbo take operacije je minimalen (konstanten) in ni odvisen od velikosti in števila podatkov. Konsistentno upravljanje s podatki. SVN uporablja binarni algoritem za ugotavljanje sprememb med različicami. Ta algoritem deluje enako pri tekstovnih in binarnih datotekah, zato sta obe obliki shranjeni v repozitoriju na enak, stisnjen način. To nam omogoča, da lahko po omrežju prenašamo samo razlike med datotekami. Možnost razširitve. Subversion je implementiran modularno. Sestavljen je iz programskih knjižnic, ki so narejene v programskem jeziku C. Programski vmesniki so dobro definirani. S tem lahko tudi zunanji razvijalci na enostaven način uporabljajo in vzdržujejo sistem tudi v drugih programskih jezikih. 3.3 Arhitektura sistema SVN deluje na principu odjemalec - strežnik. Na eni strani je repozitorij (strežnik), ki hrani vse spremembe izdelkov. Na drugi strani je odjemalec 14, ki upravlja lokalno sliko dela spremenjenih izdelkov, imenovano delovne kopije. Med tema ekstremoma je mnogo poti skozi različne nivoje dostopa do repozitorija (repository access layers). Nekatere poti vodijo skozi omrežja in skozi omrežne strežnike, ki nato dostopajo do repozitorija. Nekatere obidejo omrežje in dostopajo do repozitorija direktno (lokalno). SVN je zgrajen na prenosnem nivoju (portability layer) imenovanem Appache Runtime library (APR). Knjižnica APR-ja ima vse vmesnike, ki jih SVN potrebuje za delovanje na različnih operacijskih sistemih: dostop do diska, dostop do omrežja, upravljane pomnilnika in drugo. SVN lahko uporablja Apache kot enega od omrežnih strežnikov. SVN odvisnost od APR-ja pa še ne pomeni, da je Apache Aplikacija na strani odjemalca.

31 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 22 potrebna komponenta za delovanje. APR je samostoječa (standalone) knjižnica, ki jo lahko uporablja katerakoli aplikacija. Kljub vsemu pa tako kot Apache, tudi SVN odjemalci in strežniki delujejo na vseh operacijskih sistemih, na katerih deluje Apache httpd strežnik: Windows, Linux, BSD, Mac OS, Netware. Slika 3.1: Arhitektura SVN. [1]

32 Implementacija odjemalca sistema za upravljanje različic»subversion«stran Nivo strežnika Repozitorij SVN repozitorij je centralna shramba za beleženje sprememb izdelkov za poljubno število projektov. Repozitorij v splošnem obvladamo z minimalnim upravljanjem. Kljub temu ga je potrebno primerno konfigurirati in primerno vzdrževati, da se izognemo potencialnim nevarnostim. Konceptualno je SVN repozitorij drevesna struktura map in datotek (slika 3.2). Vsako drevo je prikaz, kako so izgledale v določenem trenutku različice datotek in map v repozitoriju. Ti posnetki so rezultat odjemalcev in se imenujejo revizije. Revizije 15 V delovni kopiji lahko spreminjamo vsebino datotek, kreiramo nove datoteke, brišemo datoteke, preimenujemo datoteke ali mape, premikamo datoteke ali mape in opravljamo še ostale operacije nad datotekami in mapami. Operacija vključevanja prenese vse opravljene spremembe v repozitorij kot en sama atomarna transakcija. V repozitoriju je vsaka vključitev obravnavana kot atomarna. Vedno, ko repozitorij sprejme vključitev, nastane novo stanje datotečnega drevesa, ki ga imenujemo revizija. Vsaki reviziji se dodeli unikatno naravno število za ena višje kot prejšnja revizija. Začetna revizija ima številko nič in se sestoji iz prazne korenske mape. 15 Verzija, ki nadomesti predhodno verzijo. Do nove revizije najpogosteje pride zaradi odpravljanja napak v predhodni verziji.

33 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 24 Slika 3.2: Revizije. [11] Globalno številčenje revizij Številka revizije se nanaša na celotno drevo in ne na posamezne datoteke. Vsaka številka revizije določa celotno drevo - stanje repozitorija po spremembi vključevanja. N-ta revizija predstavlja stanje po N-ti vključitvi. Ko znotraj SVN govorimo o 5-ti reviziji datoteke»krog.java«to v resnici pomeni datoteko, kakršna je bila v reviziji številka 5. Pomembno je spoznanje, da je lahko datoteka v M-ti in N-ti reviziji enaka.

34 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 25 Kako se podatki hranijo? SVN hrani podatke na dva načina: podatkovna baza Berkeley navadne datoteke. Razvijalci SVN drugi mehanizem shranjevanja podatkov označujejo s kratico FSFS. FSFS je implementacija datotečnega sistema za beleženje sprememb izdelka, ki uporablja za shranjevanje podatkov datotečni sistem operacijskega sistema. Ko kreiramo repozitorij mora administrator določiti ali bo uporabil Berkeley DB ali FSFS. Vsaka od možnosti ima svoje prednosti in slabosti (tabela 3.1). Uporabniški vmesniki, ki dostopajo do repozitorija, so izolirani od detajlov implementacije. Odjemalci nimajo informacije kako repozitorij shranjuje podatke. Vidijo samo revizije in transakcijska drevesa skozi repozitorijev programski vmesnik.

35 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 26 Kategorija Značilnost Berkely DB FSFS Zanesljivost Integriteta podatkov Pri ustrezni namestitvi zelo zanesljiv. Starejše verzije so imele razne uničujoče hrošče. Občutljivost na prekinitve (interruptions) Velika Dokaj neobčutljiva Dosegljivost Uporabno iz priklopa omogočenega samo za branje (read-only mount) Ne Da Shramba neodvisna od platforme Ne Da Uporabno preko omrežnega datotečnega sistema Upravljanje skupinskih pravic V splošnem ne Občutljiv pri problemih uporabniških mask; najbolj uporaben v primeru enega uporabnika. Da Obide probleme z uporabniškimi maskami. Skalabilnost Zasedenost diska na repozitoriju Velika, še posebej v primerih, ko se datoteke z dnevniki ne brišejo. Majhna Število revizijskih dreves Ni težav Nekateri starejši datotečni sistemi imajo težave pri veliki količini datotek v eni mapi. Mape z velikim številom datotek Počasnejša Hitrejša Performanse Izključitev zadnje revizije Ni razlike Ni razlike Vključevanje»velikih«sprememb V celoti počasneje, vendar se stroški skozi življenjsko dobo operacije vključevanja amortizirajo. Hitreje, vendar lahko finalizacija operacije doprinese k časovnim zamudam. Tabela 3.1.: Primerjava različnih vrst hranjenja podatkov v repozitoriju.

36 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 27 Berkely DB V začetni fazi razvoja so se razvijalci iz več razlogov odločali za uporabo Berkeley DB: odprto kodna licenca, zmogljivost, podpora transakcijam, zmožnost delanja varnostnih kopij, brez zaustavitve sistema, zanesljivost. Vendar ima tudi slabosti: Ni prenosljivo okolje. Ne moremo preprosto prekopirati repozitorija iz enega operacijskega sistema v drugega. Ne dela v Windows 95/98. Ne smemo imeti repozitorija v skupni rabi. Ker je Berkeley DB knjižnica povezana direktno v SVN, je bolj občutljiva na prekinitve kot tipična relacijska baza. Tipična relacijska baza teče kot samostojen proces, ki posreduje vse dostope v tabele. Če se program, ki dostopa do baze zruši, bo prikriti proces opazil prekinitev povezave in počistil za seboj. Ker je prikriti proces edini proces, ki dostopa do tabel, aplikacija ne rabi skrbeti za konflikte med pravicami. Ker je Berkeley DB repozitorij relativno hiter in skalabilen, je najbolje, da ga uporabljamo z enim strežniškim procesom, ki ga poganja en uporabnik, kot sta Apache httpd ali svnserve, kar je boljše, kot da dostopamo do njega kot različni uporabniki preko file:// ali SVN+ssh:// URLja. FSFS Sredi leta 2004 je zaživel drugi tip shranjevanja podatkov repozitorija. Ta sistem ne uporablja baze podatkov. FSFS repozitorij hrani spremembe ene revizije v eno datoteko. Na ta način lahko najdemo vse revizije repozitorija v eni mapi polni označenih datotek. Transakcije so kreirane v ločenih mapah kot samostojne datoteke. Če je transakcija končana, je datoteka preimenovana in premaknjena v revizijsko. S tem zagotovimo atomarnost operacij. Ker je revizijska datoteka stalna in nespremenljiva, lahko delamo varnostne kopije repozitorija med delom le-tega, enako kot Berkeley. Format datoteke revizije (revision file format) predstavlja revizijsko drevesno strukturo, vsebino datotek in razliko (deltas) med datotekami drugih revizijskih dreves. Format shranjevanja je prenesljiv med različnimi operacijskimi sistemi in ni občutljiv na CPU arhitekturo. Do repozitorija lahko varno dostopamo preko omrežnih datotečnih sistemov. Velikost repozitorija je manjša v primerjavi z Berkeley DB.

37 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 28 Predstavitve pri vstavljanju so boljše O(N) v primerjavi z Berkeley DB O(N^2). Izključevanje pa je pri FSFS počasnejše. Najpomembnejša razlika med repozitorijem, ki uporablja Berkeley DB in FSFS, je lastnost slednjega, da ko pride do problema v procesu, le-ta ostane neprizadet. V enakem primeru ko pride do problema uporabniških pravic ali sesutja v Berkeley DB sistemu, je baza neuporabna vse do posredovanja administratorja, ki jo mora vzpostaviti v delovno stanje. Pri FSFS sistemu pa v najslabšem primeru transakcija ni dokončana. Edini argument proti uporabi FSFS je relativna nezrelost v primerjavi z Berkeley podatkovno bazo. FSFS ni bila uporabljena in testirana pod stresnimi pogoji v tolikšni meri kot Berkeley. Zato je mnogo izjav o hitrosti in skalabilnosti ugibanje. Teoretično obljublja nizko vstopno oviro za administratorje in manj občutljivosti na težave. Več bo povedal čas. Možnosti dostopa do repozitorija Shema file:/// SVN:// SVN+ssh:// Metoda dostopa direkten dostop do repozitorija (na lokalni disk) dostop preko WebDAV protokola do Apache strežnika enako kot vendar s SSL enkripcijo dostop prek prirejenega protokola do svnserve strežnika enako kot SVN://, ampak preko SSH tunela Tabela 3.2.: Url-ji za dostop do repozitorija. Mrežni protokoli Obstajata dva načina, kako dostopati do repozitorija. Prva možnost je lokalni dostop. Do repozitorija dostopamo lokalno na istem računalniku, na katerem se nahaja tudi repozitorij. Ta način se po navadi uporablja za osebno rabo. Druga, tipična namestitev SVN, vključuje strežnik. Pri tej možnosti uporabniki dostopajo do neke oddaljene lokacije preko omrežja. Za povezavo med repozitorijem in uporabnikom skrbi strežnik. Obstajajo različni mrežni protokoli, preko katerih lahko dostopamo do repozitorija iz oddaljenih računalnikov. SVN je bil zasnovan z abstraktnim mrežnim slojem. To pomeni, da lahko dostopamo do repozitorija s katerimkoli strežniškim procesom. Prav tako lahko naredimo nove odjemalce, ki dostopajo do repozitorija. Le-ti morajo biti skladni z ustreznimi mrežnimi protokoli. To nam daje možnost, da

38 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 29 naredimo neskončno različnih omrežnih implementacij. Kljub temu trenutno obstajata le dve implementaciji strežnika: Apache http strežnik z modulom mod_dav_svn. Ta modul omogoča dostop do repozitorija. Strežnik je odjemalcem dosegljiv preko WebDAV/DeltaV protokola. Ta protokol je razširitev HTTP protokola. Svnserve je majhen, samostojen strežniški program, ki z odjemalci komunicira s svojim lastnim protokolom. Svnserve s SSH povezavo uporablja enak scenarij kot prejšnja možnost, vendar podatke šifrira SSH algoritem. Podjetje Collabnet, kot predstavnik odprtokodnega projekta, uradno nobenemu od strežnikov ne daje prednosti. Vsakemu lahko pripišemo določene prednosti in pomanjkljivost (tabela 3.3). Možno je tudi, da oba strežnika delujeta vzporedno. V tem primeru vsak strežnik dostopa do repozitorija na sebi lasten način, ne da bi drug drugega oviral.

39 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 30 značilnost Apache + mod_dav_svn svnserve svnserve s SSH možnosti avtentikacije osnovna HTTP(S) avtentikacija X.509 certifikati LDAP NTLM drugi mehanizmi, ki jih omogoča Apache httpd CRAM-MD5 LDAP NTLM drugi mehanizmi, ki jih omogoča SASL SSH možnosti uporabniških računov zasebna uporabniška datoteka drugi mehanizmi, ki jih omogoča Apache httpd (LDAP, SQL in drugi) splošni dostop pisanja in branja dostop pisanja in branja za posamezno mapo zasebna uporabniška datoteka drugi mehanizmi, ki jih omogoča SASL (LDAP, SQL in drugi) splošni dostop pisanja in branja dostop pisanja in branja za posamezno mapo sistemski računi možnosti splošni dostop avtorizacije pisanja in branja dodeljen samo celemu repozitoriju šifriranje možnost SSL možnost SASL del SSH povezave beleženje dnevnika(logging) Apache beleženje za vsako HTTP zahtevo z možnostjo zahtevnega (»high-level«) beleženja za splošne operacije klienta dosegljiv za ostale WebDAV odjemalce omejena že vgrajena podpora preko orodij drugih proizvajalcev (ViewCVS) ne omogoča ne omogoča medobratovalnost (interoperabil) komunicira samo s SVN klienti komunicira samo s SVN klienti Spletni pogled (web preko orodij drugih preko orodij viewing) proizvajalcev (ViewVS) drugih proizvajalcev (ViewVS) hitrost sorazmerno počasnejša sorazmerno hitrejša sorazmerno hitrejša začetna nastavitev sorazmerno sorazmerno sorazmerno kompleksnejša preprostejša preprostejša Tabela 3.3.: Primerjava strežnikov. [1] Mrežni model SVN odjemalec porabi večino časa za upravljanje delovnih kopij. Ko potrebuje informacije iz repozitorija, izvede omrežno zahtevo, strežnik pa se odzove z ustreznim odgovorom. Podrobnosti omrežnega protokola so uporabniku skrite. Odjemalec poizkuša dostopati do željenega URL-ja in glede na URL shemo, je uporabljen ustrezen protokol za povezavo s strežnikom. Ko strežniški proces prejme odjemalčevo zahtevo, od odjemalca zahteva, da se identificira. Strežnik izda odjemalcu zahtevo po avtentikaciji (authetication challenge), na katerega odjemalec odgovori s

40 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 31 poverilnico. Ko je avtentikacija opravljena, strežnik odgovori z originalno informacijo, ki jo je zahteval odjemalec. Ta način je drugačen kot pri nekaterih drugih sistemih za upravljanje različic (CVS), kjer odjemalec predhodno ponudi poverilnico, preden izda zahtevo. Pri SVN strežnik izpuli (pull) poverilnico, da izzove odjemalca ob primernem trenutku, raje kot da jo odjemalec potisne (push). To napravi določene operacije elegantnejše. Privzemimo, da je strežnik nastavljen tako, da dovoli branje repozitorija vsakomur. V tem primeru strežnik nikoli ne bo izdajal zahteve po avtentikaciji. SVNSERVE strežnik Svnserve je preprost strežnik, ki je zmožen komunicirati z odjemalci preko TCP/IP, z uporabo lastnega protokola. Odjemalci navežejo stik s svnserve strežnikom z uporabo URLja, ki se začne z SVN:// ali SVN+ssh:// sheme. Apache HTTPD strežnik Najbolj uveljavljen in razširjen spletni strežnik za podporo SVN, je Apache spletni strežnik. Z dodanim modulom mod_dav_svn omogoča odjemalcem dostop do SVN repozitorija. To doseže s protokolom WebDAV/DeltaV. WebDAV WebDAV (Web-based Distributed Authoring and Versioning) je množica razširitev protokola HTTP, ki omogoča, da uporabniki urejajo in upravljajo datoteke na oddaljenih spletnih strežnikih. Ideja o protokolu WebDAV se je začela razvijati leta 1996 v okviru WWW konzorcija. Cilj je bil rešitev problema distribuiranega ustvarjanja in urejanja dokumentov v svetovnem spletu. S tem bi postal svetovni splet medij, primeren za branje in ustvarjanje oz. spreminjanje dokumentov. V začetku nastajanja spletnih brskalnikov, so bili le-ti zmožni tako brati, kakor tudi spreminjati vsebino spletnih strani, vendar je z rastjo spleta postala za večino uporabnikov spleta edina operacija branje. S protokolom WebDAV se je to spremenilo. Protokol naredi svetovni splet medij, primeren za branje in pisanje. Omogoča nam kreiranje, spreminjanje in premikanje dokumentov na oddaljenih strežnikih. To je med drugim primerno za urejanje dokumentov, ki jih ponuja spletni strežnik. Uporablja se tudi kot prostor za shranjevanje podatkov prirejenih za splet, do katerega dostopamo od kjerkoli. Mnogo modernih operacijskih sistemov ima že vgrajeno podporo za WebDAV, ki omogoča dostop do datotek na WebDAV strežniku, kot bi bili shranjeni na lokalnem računalniku.

41 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 32 Kot del integracije z Apache strežnikom SVN uporablja WebDAV protokol med odjemalcem in strežnikom. Namesto razvoja lastnega omrežnega protokola, so se razvijalci SVN odločili za»podporo«z WebDAV Nivo odjemalca Medtem ko je repozitorij postavljen na stran strežnika in hrani datoteke projekta, je na strani odjemalca uporabniški program, katerega glavna naloga je, da skrbi za delovno kopijo. Delovna kopija je datotečno drevo na lokalnem računalniku, ki vsebuje mape in datoteke. Za upravljanje s temi datotekami skrbi knjižnica odjemalca. Do knjižnice odjemalca lahko dostopamo z različnimi uporabniškimi programi. Uporabniški program, ki je dodan vsaki distribuciji SVN, je ukazna vrstica. Obstaja tudi množica drugih uporabniških programov, predvsem grafičnih, ki nudijo bolj pregledno in enostavnejše delo z delovnimi kopijami. Atomarnost operacij (transakcije) Uporabnik s pomočjo uporabniškega programa izvaja operacije. Ko izvede operacijo vključitev, si zgradi transakcijo, ki zrcali lokalne spremembe in nato v repozitorij shrani to drevo, kot naslednji posnetek v zaporedju. Če je vključitev uspešna, je transakcija uspešno vnesena kot novo drevo. Dodeljena je nova številka revizije. Če vključitev ni uspešna je transakcija uničena, odjemalec pa je obveščen o neuspešni operaciji. Operacija posodobitve deluje podobno. Odjemalec zgradi začasno transakcijsko drevo, ki odseva stanje delovne kopije. Repozitorij nato primerja transakcijsko drevo z revizijskim drevesom izbrane revizije (ponavadi je to zadnja revizija - najmlajša) in pošlje nazaj informacijo, ki obvesti odjemalca o spremembah, ki jih je potrebno prenesti v delovno kopijo v repliko revizijskega drevesa. Ko je posodobitev končana, se začasna transakcija izbriše. Uporaba transakcijskega drevesa je edina možnost, da naredimo spremembe trajne v datotečni repozitorij. Življenjska doba transakcij je fleksibilna. V primeru posodabljanja so transakcije začasna drevesa, ki so takoj uničena. V primeru vključevanja so transakcije pretvorjene v stalne revizije, ali odstranjene, če vključevanje spodleti. Kako delovne kopije sledijo repozitoriju? Za vsako datoteko v delovni mapi SVN vodi dve nujni informaciji, ki se hranita v skriti mapi ".SVN/": Katera številka revizije je temelj delovne datoteke? Temu pravimo delovna revizija datoteke. Časovni žig beleži, kdaj je bila lokalna kopija nazadnje posodobljena iz repozitorija.

42 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 33 Če imamo te podatke na razpolago, ko komuniciramo z repozitorijem, SVN lahko ve, v katerem od štirih stanj se nahaja delovna datoteka: Nespremenjena in zadnja različica (unchanged, and current). Datoteka je nespremenjena v delovni mapi in nobene spremembe v tej datoteki niso bile potrjene v repozitorij od delovne revizije. Vključitev ali posodobitev datoteke ne spremeni datoteke ali repozitorija. Lokalno spremenjena in zadnja različica (locally changed, and current). V delovni mapi je bila spremenjena datoteka. V repozitoriju niso bile potrjene spremembe te datoteke od bazne revizije naprej. Spremembe na delovni različici niso bile potrjene v repozitorij. Vključitev datoteke objavi naše spremembe. Posodobitev ne naredi ničesar. Nespremenjena in zastarela (unchanged, and out-of-date). Datoteka ni bila spremenjena v delovni mapi, bila pa je spremenjena v repozitoriju. Da bo datoteka takšna, kot je v repozitoriju, jo moramo posodobiti. Vključitev datoteke ne povzroči nobene spremembe. Posodobitev prenese spremembe v delovno kopijo. Lokalno spremenjena in zastarela (locally changed, and out-of.date). Datoteka je bila spremenjena v delovnem mapi in repozitoriju. Vključitev datoteke ne uspe in javi napako»out-of-date«. Datoteka mora biti najprej posodobljena. Posodobitev poizkusi združiti javno spremembe z lokalno spremembo. Če se to ne more uresničiti avtomatsko, morajo uporabniki rešiti problem. Odjemalčevo predpomnenje poverilnice (Client Credentials Cashing) Veliko strežnikov je konfiguriranih tako, da zahtevajo avtentikacijo za vsako zahtevo. Če moramo za vsako zahtevo vpisovati geslo, lahko to postane zelo moteče in upočasnjuje delo. V ta namen ima SVN odjemalec rešitev: vgrajen sistem predpomnjenja poverilnice, ki se shrani na disk. Privzeto je da vedno, ko odjemalec preko ukazne vrstice uspešno odgovori na strežniški avtentikacijski izziv, shrani poverilnico na uporabniški zasebno območje»%appdata%/subversion/auth«(pri OS Windows). Uspešne poverilnice se shranijo na lokalni disk in zaklenejo s kombinacijo imena gostitelja, vrat in avtentikacijske domene. Ko odjemalec sprejme avtentikacijski izziv, najprej poišče primerno poverilnico v uporabniškem predpomnilniku. Če ne obstaja, odjemalec vnese uporabniške podatke. Območje, kjer se hranijo poverilnice, je varnostno zaščiteno tako, da lahko samo uporabnik (lastnik) dostopa do poverilnice.

43 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 34 Odjemalci (aplikacije oz. uporabniški programi na strani odjemalca) Od prve distribucije dalje, je v standardni namestitvi SVN priložena ukazna vrstica, s katero lahko upravljamo delovne kopije na strani odjemalca. Ukazna vrstica omogoča upravljanje z vsemi funkcijami, ki jih SVN omogoča in je zaradi tega zelo močno orodje predvsem za izkušene uporabnike, ki so vešči dela z ukazno vrstico iz drugih sistemov (Linux, Unix ). Ima pa slabost. Za nevešče uporabnike, to so občasni uporabniki ali uporabniki začetniki, je ukazna vrstica zahtevno orodje. Za uporabnike vajene grafičnih okolij so osnovne, predvsem pa napredne možnosti, predstavljene v obliki naprej pripravljenih možnosti, dosegljivih preko menijev, bližnjic, gumbov. Za to vrsto uporabnikov (in tudi za ostale) so različni razvijalci, ki niso nujno del ekipe SVN, pripravili različne, predvsem grafične rešitve za delo s SVN. Te rešitve omogočajo zelo enostavno delo, poleg tega pa imajo nekatere dodatne, specialne in uporabne funkcionalnosti, ki pridejo v poštev pri zahtevnejšem delu. Najbolj znan odprto kodni odjemalec je ToortoiseSVN, ki je integriran v Windows delovno okolje. Obstaja ogromno drugih odjemalcev 16, tudi komercialnih, ki omogočajo specialne možnosti za razvijalce in ostale uporabnike. 3.4 Možnosti za razširitev SVN V primeru, da želimo razširiti funkcionalnost odjemalca in ga prilagoditi svojim potrebam ali narediti popolnoma novega, ga moramo programsko spremeniti. Ker je SVN odprtokodna rešitev, ga lahko spreminja vsakdo. SVN je napisan v programskem jeziku C, zato bodo poznavalci le-tega najlažje prilagajali vmesnik. Poleg tega obstajajo programski vmesniki za druge programske jezike, s katerimi je programiranje lažje. 16

44 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 35 4 SVNKit - PROGRAMSKI VMESNIK ZA SVN V tem poglavju je opisan pogled na SVN, kot ga vidijo programerji, ki delajo in vzdržujejo SVN ali pa kot programerji, ki bi radi naredili svoj nov ali spremenjen uporabniški program, ki bi izkoriščal programski vmesnik za SVN. Obstaja več programskih vmesnikov za SVN, do katerih lahko dostopamo z različni programskimi jeziki. 4.1 Uporaba sistema SVN SVN lahko uporabljamo na dva načina: Končni uporabniki uporabljajo SVN preko že obstoječih uporabniških programov (ukazna vrstica, ToortoiseSVN in drugi). Kadar želijo datoteko ali mapo vključiti, izključiti, preimenovati, izvoziti, ali želijo upravljati repozitorij, napišejo ustrezen ukaz oz. poiščejo ustrezen grafični simbol za sprožitev ukaza, če uporabljajo grafični uporabniški vmesnik. SVN uporablja neka aplikacija programsko (recimo razvojna okolja, kot so Eclipse, Netbeans, Visual Studio ). Ta možnost je uporabna predvsem za programerje, ki v aplikaciji dostopajo do funkcij SVN. V tem primeru, kjer aplikacija dostopa do funkcionalnosti SVN, sta spet dve možnosti uporabe SVN. V prvem primeru program uporablja že narejene odjemalce (SVN ukazno vrstico, TortoiseSVN in druge). Nov odjemalec mora v tem primeru opraviti zunanje klice na odjemalcu in nato razčleniti morebiten vrnjen rezultat in izjeme. Drugi primer daje možnost aplikacijam, da uporabljajo programske vmesnike za SVN. V tem trenutku obstaja več programskih vmesnikov za različne programske jezike (C, Java, Python). SVN ima modularno zgradbo. Sestavljen je iz programskih knjižnic, ki so napisane v programskem jeziku C. Vsaka knjižnica ima dobro definiran namen in svoj programski vmesnik. S tem je zagotovljeno, da je SVN enostaven za vzdrževanje, prav tako pa programerji na enostaven način v svoje programe dodajo funkcije za upravljanje s SVN. Programski vmesnik lahko uporabljamo tudi v drugih višjih programskih jezikih, kot so Python, Perl, Java, Ruby, po navadi s pomočjo povezav med programskimi jeziki. Za programski jezik Java je narejen vmesnik, ki je narejen v programskem jeziku Java. V nadaljevanju poglavja bo predstavljena arhitektura programskega vmesnika SVN napisanega v jeziku C (original), nato pa bo opisan programski vmesnik SVNKit, ki je napisan v jeziku Java.

45 Implementacija odjemalca sistema za upravljanje različic»subversion«stran Programski vmesnik za programski jezik C Vsako od ključnih programskih knjižnic SVN lahko umestimo v enega od treh slojev (slika 3.1): sloj repozitorija sloj dostopa do repozitorija sloj odjemalca Razvojna skupina za SVN vztraja pri tem, da so funkcionalnosti v ustreznih slojih in knjižnicah. Prednost, ki jo z modularno zgradbo pridobimo je, da z vidika razvijalca zmanjšamo kompleksnost, saj se le ta osredotoči na vmesnik (vhodne, izhodne podatke), sama implementacija pa ga praviloma ne zanima. Z lahkoto si ustvarimo celotno sliko sistema, ki nam omogoča da natančno določimo, kje se katera funkcionalnost nahaja. Naslednja prednost modularnosti je, da lahko nadomestimo katerikoli modul z novim, ki implementira isti programski vmesnik, ne da bi s tem vplivali na ostali del sistema. Kot primer navedimo knjižnice libsvn_ra_local, libsvn_ra_neon, libsvn_ra_serf in libsvn_ra_svn, ki vse implementirajo isti vmesnik. Vse te knjižnice so vtičniki za knjižnico libsvn_ra. Vse štiri komunicirajo s slojem repozitorija. Libsvn_ra_local se neposredno poveže na repozitorij. Ostale tri: libsvn_ra_neon, libsvn_ra_serf in libsvn_ra_svn se na repozitorij poveže preko omrežja. Odjemalec prav tako koristi prednosti modularnosti pri programiranju SVN. Knjižnica libsvn_client vsebuje vse potrebne funkcionalnosti za zasnovo klienta. Sestavni del distribucije SVN za odjemalca je ukazna vrstica. Ker je le-ta precej okorna za uporabo, je na trgu več odjemalcev z grafičnim vmesnikom. Ti odjemalci uporabljajo isti programski vmesnik kot ukazna vrstica. Iz tega izhaja, da ravno modularnost prispeva k številnim odjemalcem in tudi integraciji v razvojna okolja, s tem pa povečanemu sprejetju uporabe SVN kot celote Sloj repozitorija (repository layer) Na nivoju repozitorija obravnavamo dva osnovna koncepta. Prvi se nanaša na implementacijo datotečnega sistema, ki beleži spremembe, drugi pa govori o logiki repozitorija, ki ga obdaja. Te knjižnice implementirajo mehanizme za shranjevanje in nadzor izdelkov, ter poročanje. Ta sloj se preko sloja za dostop do repozitorija povezuje z slojem odjemalca in je za samega odjemalca sloj na»drugi strani«, to pomeni, da ga ne zanima.

46 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 37 Datotečni sistem SVN ni na nivoju jedra (kot Linux ext2 ali NTFS), temveč je virtualni datotečni sistem. Namesto hranjenja pravih datotek in map, uporablja dva abstraktna sistema za shranjevanje podatkov: Berkely DB ali FSFS (navadne datoteke). Programski vmesnik na tem nivoju ima funkcionalnosti, ki jih imajo navadni datotečni sistemi (kopiranje, premikanje, spreminjanje vsebine...), poleg tega pa ima lastnosti, ki so lastne sistemom za upravljanje različic, in sicer dodajanje, spreminjanje, odstranjevanje metapodatkov (lastnosti) datotek in map. Kar je najpomembnejše in kar loči tega od ostalih datotečnih sistemov, je sistem za beleženje sprememb izdelkov, kar pomeni, da ko naredimo spremembo v drevesni strukturi, si SVN zapomni stanje, kot je bilo pred spremembo in tako nazaj do prve različice. Vse spremembe so narejene v kontekstu transakcij sistema Subversion. Ko je transakcija zaključena, so spremembe za vedno shranjene v datotečnem sistemu. Vsaka transakcija naredi novo revizijo datotečnega drevesa Sloj dostopa do repozitorija (repository access layer) To je povezovalni sloj med skrajnima slojema odjemalca in repozitorija. Namenjen je posredovanju podatkov med knjižnicami klienta in repozitorijem. SVN uporablja enolični krajevnik vira (URL) za identifikacijo virov repozitorija. Del URL sheme določajo protokoli (file://, SVN://, or SVN+ssh://), le-ti pa določajo, kateri modul v sloju dostopa do repozitorija bo zadolžen za komunikacijo. Javni programski vmesnik, ki ga ponuja ta sloj, vsebuje funkcionalnosti potrebne za pošiljanje in sprejemanje spremenjenih izdelkov do in od repozitorija preko različnih protokolov Sloj odjemalca (client layer) Večji del funkcionalnosti, ki jih implementirajo knjižnice na strani odjemalca, se nanašajo na upravljanje delovnih kopij in propagiranja sprememb do ali od sloja dostopa do repozitorija. Knjižnica(ce) na strani odjemalca je narejena tako, da jo lahko uporablja katerakoli aplikacija. Medtem ko v osnovni distribuciji SVN dobimo standardno ukazno vrstico, je zelo enostavno narediti tudi grafični vmesnik za odjemalca, ki sloni na odjemalčevi knjižnici. Novi vmesnik tako ne rabi razčlenjevati ukazne vrstice odjemalca, temveč ima dostop do uporabniškega vmesnika (knjižnice libsvn_client), ki jo uporablja tudi ukazna vrstica (funkcionalnosti, podatkov, klicev, izjem).

47 Implementacija odjemalca sistema za upravljanje različic»subversion«stran Uporaba SVN v ostalih programskih jezikih Do knjižnic SVN lahko dostopamo tudi z nekaterimi drugimi višjimi programskimi jeziki kot samo C in C++. Za to lahko uporabimo orodje SWIG 17 (Simplified Wrapper and Interface Generator). S tem orodjem lahko povežemo programe napisane v jeziku C in C++ z drugimi višjimi programskimi jeziki. Med njih spadajo skriptni jeziki (Perl, PHP, Python, Tcl and Ruby) in tudi neskriptni jeziki (C#, Common Lisp (CLISP, Allegro CL, CFFI, UFFI), Java, Lua, Modula-3, OCAML, Octave in R). Povezave omogočajo indirektne klice funkcij programskega vmesnika z uporabo»ovojnice«(wrapper), ki prevede podatkovne tipe jezika C v podatkovne tipe izbranega jezika in obratno. Za jezike Python, Perl in Ruby je bilo vloženega dosti veliko truda, medtem kot je pri ostalih programskih jezikih potrebno dodatno programiranje povezav. Za programski jezik Java je razvit poseben sistem povezav imenovan javahl povezave, ki je kombinacija med Javo in JNI ogrodjem. Javahl podpira večino funkcij programskega vmesnika na strani odjemalca, zato je primeren predvsem za implementacije Javanskih klientov in IDE integracij. SVNKit, ki je na novo zasnovana knjižnica na strani odjemalca za SVN, je napisana v jeziku Java in je namenjena programerjem jezika Java 18. Poudariti je treba, da razne povezave med jeziki spremenijo modularno zgradbo SVN z dobro definiranimi in določenimi moduli. Kljub temu jim je mogoče zaupati in so primerni za produkcijsko rabo. 4.4 Kaj je SVNKit SVNKit je programska knjižnica, napisana v jeziku Java, namenjena programerjem jezika Java za delo s SVN na strani odjemalca. Implementirane ima skoraj vse funkcije sistema Subversion. Ponuja vmesnik za delo z delovnimi kopijami SVN ter dostop in upravljanje repozitorija SVN. [12] Leta 2005 je manjše podjetje TMate izdalo prvo različico JavaSVN implementacije SVN. Projekt se je med tem preimenoval v SVNKit in dosegel relativno velik uspeh. Programerjem v jeziku Java omogoča dostop do funkcionalnosti SVN, ki jih lahko uporabijo v odjemalcih, razvojnih orodij in ostalih programskih produktih

48 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 39 Knjižnica SKNKit ni samo ovoj okoli originalnih knjižnic SVN, kot je to knjižnica javahl, temveč je na novo zasnovan sistem, ki uporablja skoraj vse funkcionalnosti originalnega sistema Subversion. Programski kod je popolnoma na novo napisan v jeziku Java. SVNKit ni razvit kot odprtokodna programska oprema. Njegova licenca je bolj restriktivna kot licenca za SVN. SVNKit je torej programski vmesnik (knjižnica) napisan v programskem jeziku Java in je namenjen Java aplikacijam za delo z izdelki, ki so pod nadzorom SVN. Vmesnik dopušča naslednje: Neposredno delo s repozitorijem. Ustvarjanje repozitorija na lokalnem računalniku. Upravljanje delovnih kopij. Implementacija novega formata za upravljanje različic za lokalne podatke. Replikacijo repozitorija. Brskanje po repozitoriju. Izvoz vsebine repozitorija. Uvoz vsebine repozitorija. 4.5 Arhitektura SVNKit-a SVNKit programski vmesnik je sestavljen iz dveh nivojev (slika 4.1): Nižji nivo (low-level layer) upravlja nivo dostopa do repozitorija. Predstavlja gonilnik za neposredno delo z repozitorijem. Višji nivo (high-level layer) upravlja delovne kopije. Ta del programskega vmesnika omogoča upravljanje delovnih kopij na način, ki ga dosežemo, z funkcijami ukazne vrstice.

49 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 40 Slika 4.1: Struktura knjižnice SVNKit Nižji nivo vmesnika Ta nivo predstavlja abstraktni nivo sistema Subversion za dostopa do repozitorija. Opozoriti je potrebno na dvoje: Nižji nivo ne zna upravljati delovnih kopij (delovne kopije so na višjem nivoju). Ta nivo zna komunicirati s SVN repozitorijem preko različnih protokolov. Ta nivo implementira te protokole. Podatkovne strukture se na tem nivoju upravljajo kot abstraktne hierarhije podatkov. Na ta način omogočimo bolj napredno predstavitev abstrahiranja kot z navadno drevesno hierarhijo, obenem pa obdržimo to hierarhijo pod nadzorom sistema za upravljanje različic. 19

50 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 41 Razrede in vmesnike, ki delujejo na nižjem nivoju najdemo v paketu org.tmatesoft.svn.core.io Višji nivo vmesnika Višji nivo programskega vmesnika je podoben ukazom ukazne vrstice SVN. Vse operacije za upravljanje delovnih kopij se nahajajo v SVN*Client (SVNCommitClient, SVNBasicClient, SVNCommitClient in ostale) razredih. (Na primer: vse operacije za ažuriranje delovnih kopij (vključitev, izključitev in druge) izvaja isti razred SVNUpdateClient. Argumenti, ki jih dobijo metode teh razredov, so enaki kot argumenti SVN ukazne vrstice). Vsi ti razredi in vmesniki se nahajajo v paketu org.tmatesoft.svn.core.wc. V primeru, ko je zahtevan dostop do repozitorija, višji nivo vmesnika uporablja nižji nivo vmesnika.

51 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 42 5 RAZVOJ LASTNE REŠITVE Z UPORABO SVNKit-a 5.1 Opredelitev problema in analiza zahtev Privzemimo, da smo nekje, kjer nimamo dostopa do svojega ali službenega računalnika in moramo (nujno) popraviti izdelek (dokument, programski kod), ki se nahaja v repozitoriju, ki je dostopen preko svetovnega spleta. Navadno se v takšnem primeru namesti odjemalec, recimo TortoiseSVN, s katerim se lahko iz oddaljenega repozitorija izključi datoteka, ki se nato v urejevalniku besedil popravi in vključi nazaj v repozitorij. Ta postopek je popolnoma vsakdanji in nič nenavaden. Vendarle pa ta postopek v nekaterih primerih ni najprimernejši iz naslednjih razlogov: Primer, ko na računalniku nimamo administratorskih pravic za nameščanje aplikacij. Nameščanje nove programske opreme ni vedno najbolj primerno opravilo, še posebej, če program uporabimo samo enkrat in ga takoj nato odstranimo. Če imamo na razpolago drugo možnost kot namestitev programa, jo navadno izberemo. Med obstoječimi odjemalci 20 za SVN v času nastajanja diplomskega dela, nisem našel aplikacije, ki bi obšla ti dve oviri. Iz tega razloga sem si zadal sledeče zahteve za izdelavo svoje aplikacije: Aplikacijo je mogoče uporabljati na računalniku z operacijskim sistemom Windows ali Linux, ne glede na uporabniške pravice. Preprost grafični uporabniški vmesnik z omejeno funkcionalnostjo: o avtentikacija uporabnika o pregled datotek v repozitoriju o izključitev datoteke iz repozitorija o vključitev (popravljene) datoteke v repozitorij 20

52 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 43 Na podlagi teh zahtev sem izdelal primer uporabe (slika 5.1) in izdelal scenarij, po katerem bi potekala uporaba aplikacije: 1. Uporabnik se poveže s sistemom Subversion. 2. V repozitoriju poišče datoteko, ki jo želi izključiti. 3. Izbrano datoteko izključi. 4. Popravi (spremeni) izključeno datoteko. 5. Datoteko vključi v repozitorij. Slika 5.1: Diagram primerov uporabe.

53 Implementacija odjemalca sistema za upravljanje različic»subversion«stran Statični vidik Aplikacija je zgrajena iz treh modulov (razredov). Sestavljata jo dva razreda, ki upravljata repozitorij in delovne kopije(svnlow, SVNhigh) ter en razred (GrafikaUI), ki upravlja grafični vmesnik in uporablja funkcije razredov SVNlow in SVNhigh in drugih, v tem primeru, pomožnih funkcij (slika 5.2). SVNlow (Funkcionalnosti nižjega nivoja vmesnika. Vmesnik uporablja dela direktno z repozitorijem). o Poveži (vzpostavi povezavo klienta s repozitorijem) o Prekini (prekine povezavo klienta s repozitorijem) o VrniVsebinoMape (vrne vsebino mape na določenem naslovu) SVNhigh (Funkcionalnosti višjega nivoja vmesnika. Opravlja operacije z delovnimi kopijami). o Poveži (vzpostavi povezavo klienta s repozitorijem) o Prekini(prekine povezavo klienta s repozitorijem) o Vključi (vključi datoteko v repozitorij) o Izključi (izkluči datoteko iz repozitorija) GrafikaUI (Grafični vmesnik za komunikacijo z uporabnikom). o main o initcomponents o btnizberidirmouseclicked o btncommitmouseclicked o btncheckoutmouseclicked o listdirmouseclicked o btnpovezimouseclicked o btnexitmouseclicked o deletedirectory

54 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 45 Slika 5.2: Razredni diagram.

55 Implementacija odjemalca sistema za upravljanje različic»subversion«stran 46 Uporabniški vmesnik (slika 5.3) je narejen s pomočjo knjižnic Swing, ki omogočajo gradnjo grafičnih programskih vmesnikov. Slika 5.3: Grafični vmesnik aplikacije. Grafični vmesnik je sestavljen iz dveh delov. Prvi del, ki se nahaja na vrhu okna v zgornjem okvirju, je namenjen prijavi v repozitorij. Nujno je vnesti podatke o lokaciji repozitorija (»repozitorij«). Ostale podatke vnesemo po potrebi. Začetno mapo (»začetna mapa«) znotraj repozitorija vnesemo, če želimo začeti brskati po repozitoriju v mapi, ki ni korenska. To lahko storimo tudi tako, da ime mape priključimo imenu repozitorija. V primeru, da je potrebna prijava v repozitorij z geslom, vpišemo uporabniško ime in geslo v za to namenjen prostor. Preden izključimo izbrano datoteko, moramo vnesti tudi mapo, kjer bomo izključili datoteko (»delovna mapa«). Ko kliknemo gumb»poveži«, se ob