FAKULTETA ZA MATEMATIKO, NARAVOSLOVJE IN INFORMACIJSKE
TEHNOLOGIJE
Računalništvo in informatika, 1. stopnja
Igor Renko
Sistemi za nadzor različic
Zaključna naloga
Mentor:
doc. dr. Branko Kavšek
Koper, 2012
FACULTY OF MATHEMATICS,
NATURAL SCIENCES AND INFORMATION TECHNOLOGIES
Computer Science, undergraduate
Igor Renko
Revision control systems
Final project paper
Supervisor:
prof. Branko Kavšek
Koper, 2012
i
KLJUČNA DOKUMENTACIJSKA INFORMACIJA
Ime in PRIIMEK: Igor RENKO
Naslov zaključnega dela: Sistemi za nadzor različic
Kraj: Koper
Leto: 2012
Število listov: 55 Število prilog: 0 Število referenc: 22
Število slik: 8 Število strani prilog: 0 Število tabel: 3
Mentor: doc. dr. Branko Kavšek
Ključne besede: sistem za nadzor različic, modeli upravljanja izvorne kode, združevanje, CVS, VSS, Git, TFS, Baazar, SVN, prednosti in slabosti sistemov za nadzor različic
ii Povzetek:
Sodobni projekti pogosto vključujejo geografsko porazdeljene ljudi, ki delajo na istem projektu hkrati. Obstaja velika verjetnost, da bo vsebino projekta bralo in urejalo več ljudi. Iz tega razloga postanejo sistemi za nadzor različic ključnega pomena. Omogočijo nam centralno hranjenje podatkov, s tem pa izboljšuejo dostopnost do shranjenih podatkov in vpogled nad spremembami, ki so se na teh podatkih zgodile.
Pomembno je, da se izbere takšen sistem za nadzor različic, ki ne bo oviral in upočasnjeval dela. Ker se omenjeni sistemi pogosto uporabljajo v večjih projektih, morajo zagotoviti podporo za dobro združujevanje in pregled nad celotno zgodovino projekta. Boljši sistemi za nadzor različic poskrbijo za združevanje sami, kar razbremeni razvijalce oziroma uporabnike tega sistema. Na ta način se zmanjšajo možnosti, da bi prišlo do človeške napake pri združevanju in se razbremeni uporabnika do te mere, da ni več primoran imeti vpogled nad vsemi spremembami, ki so se zgodile v projektu.
Diplomska naloga predstavlja zgodovino razvoja in rasti sistemov za nadzor različic, različne tehnike združevanja, strukturo in arhitekturo teh sistemov, njihove prednosti in slabosti ter uporabo sistemov za nadzor različic danes.
iii
KEY WORDS DOCUMENTATION
Name and SURNAME: Igor RENKO
Title: Revision control systems
City: Koper
Year: 2012
Number of pages: 55 Number of appendices: 0 Number of references: 22
Number of figures: 8 Number of appendix pages: 0 Number of tables: 3
Supervisor: prof. Branko Kavšek
Key words: revision control system, source code management models, merging, CVS, VSS, Git, TFS, Baazar, SVN, advantages and disadvantages of revision control systems
iv Abstract:
Modern projects often involve geographically spread people working on the same project simultaneously. The content of the project is likely to be read and edited by more people than the original authors of the content. Revision control systems provide a way to store the data centrally. In this way it is easier to access to stored data and insight into the changes that have occurred in these data.
It is important to choose revision control systems, which will not interfere with work and slow it down. Since revision control systems are widely used in bigger projects, they must provide good merging support and overview of the history of the project. Merging support enables several developers to merge their work without doing much manual work and history gives them overview of all changes made in project.
This thesis presents history of the development and growth of revision control systems, different merging techniques, structure and arhitecture of this systems, their advantages and disadvantages and today's use of revision control systems.
v
SLOVAR
SNR – sistem za nadzor različic
Slovar sistemov za nadzor različic
RCS – (angl. revision control system, kratica RCS ). Sistem za nadzor različic izvorne kode, ki ga je v začetku 1980-ih let razvil Walter Tichy. [20]
Baseline – odobrena revizija dokumenta ali izvorne kode, iz katerega se lahko delajo naknadne spremembe.
Commit – (sopomenka: Check in); potrditev sprememb na delovni kopiji in oddaja teh sprememb nazaj v centralni repozitorij dokumentov.
Update – (sopomenka: sync); s posodobitvijo združimo spremembe dokumentov iz centralnega skladišča z dokumenti, ki so shranjeni lokalno pri uporabnikih (posodobimo našo delovno kopijo dokumentov).
Repository – repozitorij (skladišče) je lokacija, kjer je shranjena zgodovina dokumentov in najnovejša različica dokumentov. Najpogosteje se ta lokacija nahaja na strežniku. V zaključnem delu naslovljeno kot skladišče.
Checkout – akcija, s katero se iz centralnega repozitorija ustvari delovna kopija na lokalni ravni.
Working copy – delovna kopija datotek, ki jo uporabnik pridobi iz centralnega skladišča in je shranjena lokalno. Delovna kopija se imenuje, ker se vso delo naredi na datotekah, ki so shranjene lokalno in se komaj nato spremembe iz lokalne kopije shranijo v centralno skladišče. Konceptualno lahko rečemo temu tudi peskovnik (sandbox). Peskovnik je nadzorovano okolje za razvoj in preizkus programja.
Change list/Change set – seznam vseh sprememb, ki se zgodijo, ko se spremembe posredujejo nazaj na centralni strežnik. Vsak seznam ima unikatno številko oziroma oznako, po kateri lahko spremljamo spremembe.
vi Change – sprememba predstavlja specifično spremembo dokumenta, ki se nahaja pod sistemom za nadzor.
Diff – razlika med istimi dokumenti v časoven obdobju od nastanka dokumenta pa do danes.
V večini primerov so te razlike prikazane kot seznam sprememb.
Tag/Label – oznaka (tag) se nanaša na pomemben posnetek (snapshoot) datotek v času. Te datoteke na tej točki so vse označene z uporabniku prijaznim, smiselnim imenom ali številko revizije.
Branch – veja predstavlja nabor datotek shranjenih pod sistemom za nadzor različic, ki se lahko odcepi oziroma se naredi nova veja teh datotek. Tako da se od takrat naprej lahko dva izvoda teh datotek razvija pri različnih hitrostih in na različne načine neodvisno drug od drugega.
Merge – združitev ali spajanje je operacija, v kateri se seznami sprememb uporabijo/aplicirajo na datotekah ali nizu datotek v sistemu za nadzor različic. Nekaj primerov scenarijev:
- Uporabnik, ki dela na svoji delovni kopiji, posodobi to svojo kopijo s spremembami, ki so jih naredili drugi uporabniki in so spremembe že shranili v centralno skladišče.
- Uporabnik poskuša oddati svoje spremembe dokumentov v centralno skladišče, vendar je predhodno že nek drug uporabnik posodobil obstoječi dokument. Sistem za nadzor različic v tem primeru poskuša združiti dokumente, ne da bi tako prepisal spremembe od enega ali drugega uporabnika. Velikokrat pa, v primeru da so spremembe bolj obsežne, sistem uporabniku ponudi možnost združevanja in mora nato ta sam združiti dokumente.
- Naredila se je nova veja programske kode, kjer so se recimo popravile napake iz glavne veje. Po končanih spremembah in popravkih se mora ta veja oziroma popravki na tej veji združiti z glavno vejo.
Conflict – konflikt se pojavi, ko različni uporabniki naredijo spremembe v istem dokumentu in sistem nato ne more uskladiti sprememb. Uporabnik mora rešiti spor s kombiniranjem spremembe, ali pa z izborom ene spremembe v korist drugih.
vii Lock – zaklepanje datotek. Način, da se razglasi namen spremembe določene datoteke ali imenika. Ne podpirajo vsi sistemi možnost zaklepanja datotek pred spreminjanjem, a tudi tisti ki jo imajo, dovoljujejo izklop te možnosti. To pa zato, ker zaklepanje datotek upočasnjuje razvoj v primeru, da pri razvoju sodeluje več razvijalcev. Sistemom za nadzor različic, ki zahtevajo zaklepanje, pravimo, da uporabljajo zakleni-spremeni-odkleni model, ostalim pa, da uporabljajo model kopiraj-spremeni-združi. Na splošno je model kopiraj-spremeni-združi boljši za razvoj večjih projektov, kjer sodeluje več ljudi.
Resolve – dejanje posredovanja uporabnika za reševanje konfliktov med različnimi spremembami na istem dokumentu.
Revision – revizija ali verzija. Je stanje projekta v nekem določenem časovnem trenutku.
Share – dati v skupno rabo. Je dejanje, ki eno datoteko ali mapo da na voljo več vejam v istem času. Ko se takšna datoteka ali mapa spremeni v neki veji, se spremeni tudi v vseh drugih vejah.
Trunk – unikatna/edinstvena razvojna linija, ki pa ni veja. V bistvu je to glavni program (glavna veja razvoja), na katero se združijo vse veje oziroma iz katere vse veje izhajajo.
Slovar drugih besed
Obratni inženiring (angl. reverse engineering) – raziskovanje in analiza mehanizmov delovanja končne implementacije z namenom pridobivanja informacij o intelektualni lastnini za obnovitev in ponovno uporabo.
GPL (angl. General public license) – ta licenca uporabniku računalniškega programa daje pravico reprodukcije programa pod nekaterimi pogoji. Glavni pogoj je, da uporabnik skupaj s programom (oziroma na zahtevo) distribuira tudi njegovo programsko kodo, vključno z vsemi lastnimi spremembami in izboljšavami programa.
viii
KAZALO VSEBINE
1. UVOD ... 11
2. ZGODOVINA SISTEMOV ZA NADZOR RAZLIČIC ... 15
2.1 Prva generacija ... 15
2.2 Druga generacija ... 17
2.3 Tretja generacija ... 19
3. FUNKCIONALNOST SISTEMOV ZA NADZOR RAZLIČIC ... 21
3.1 Modeli za upravljanje izvorne kode ... 21
3.1.1 Centraliziran model upravljanja ... 21
3.1.2 Porazdeljen model upravljanja ... 23
3.2 Združevanje... 24
3.2.1 Načini združevanja (algoritmi združevanja) ... 26
3.2.2 Vrste združevanja ... 26
3.3 Trendi... 30
4. SISTEMI ZA NADZOR RAZLIČIC DANES ... 31
4.1 Opis nekaterih sistemov za nadzor različic... 31
4.1.1 VSS (Visual SourceSafe) ... 31
4.1.2 TFS (Team Foundation Server) ... 33
4.1.3 CVS ... 33
4.1.4 Git ... 35
4.1.5 Bazaar ... 36
4.1.6 SVN (Apache Subversion) ... 37
4.2 Primerjava funkcionalnosti nekaterih sistemov za nadzor različic ... 39
4.3 Prednosti in slabosti sistemov za nadzor različic ... 41
4.4 Zakaj potrebujemo sistem za nadzor različic? ... 43
4.5 Nasveti za izbiro sistemov za nadzor izvorne kode ... 44
5. PRIHODNOST SISTEMOV ZA NADZOR RAZLIČIC ... 46
6. ZAKLJUČEK ... 49
LITERATURA ... 51
VIRI ... 52
ix
KAZALO SLIK
Slika 1: Vizualizacija sistema za nadzor različic ... 12
Slika 2: Centraliziran model upravljanja ... 21
Slika 3: Zaklepanje datotek ... 22
Slika 4: Združevanje verzij ... 23
Slika 5: Porazdeljen model upravljanja ... 24
Slika 6: Združevanje ... 25
Slika 7: Semantično združevanje ... 28
Slika 8: Strukturno združevanje ... 29
x
KAZALO TABEL
Tabela 1: Splošni pregled sistemov za nadzor različic ... 39 Tabela 2: Tehnične informacije opisanih sistemov za nadzor različic ... 40 Tabela 3: Tehnične značilnosti sistemov za nadzor različic ... 41
11 1. UVOD
Nadzor različic je postopek shranjevanja projektov v specializirane sisteme za vodenje izvorne kode. Sistemi za nadzor različic shranjujejo celotne projekte v centralno skladišče in zagotavljajo možnost uporabe ne le zadnje shranjene verzije, ampak tudi katerekoli druge različice, ki je bila kadarkoli shranjena v skladišču. Večina sistemov nudi tudi druge funkcije, kot je možnost, da bi spremljali različne veje istega projekta, polavtomatskega združevanja različnih sprememb, ki jih ustvarijo različni razvijalci, itd.
Najpogosteje se uporablja pri razvoju programske opreme, kjer lahko skupina ljudi opravlja spremembe na isti datoteki.
Spremembe so običajno označene s kodno številko ali črko, imenovano "številka revizije" ali enostavno "popravek". Na primer: začetni nabor datotek se imenuje "revizija 1". Ko nastopi prva sprememba, ki izhaja iz prejšnje revizije, dobi ta sprememba ime "revizija 2" in tako naprej. Vsaka revizija je povezana z časovnim žigom in imenom osebe, ki je opravila spremembo. Revizije se lahko primerjajo, povrnejo v prejšnje stanje in združujejo (vendar se operacijo združevanja lahko opravi samo nad nekaterimi vrstami datotek).
- Sistemi za nadzor različic hranijo zgodovino datotek. Če se stvari v teh datotekah spremenijo, lahko brez težav pridobimo nazaj prejšnjo oziroma starejšo različico.
- Sistemi za nadzor različic pomagajo pri sporočanju sprememb. To lahko olajša upravljanje v primeru, ko več razvijalcev dela skupaj oziroma, če razvijalci delajo na različnih lokacijah.
Najpogosteje tečejo kot samostojne (stand-alone) aplikacije. Velikokrat pa so tej sistemi tudi vgrajeni v različne vrste programske opreme, kot so urejevalniki besedil (npr. Microsoft Word, OpenOffice.org Writer, KWord, itd.), preglednice (npr. Microsoft Excel, OpenOffice.org Calc, KSpread, številke, itd.) in v različne sisteme za upravljanje vsebin (npr.
Drupal, Joomla, WordPress).
Sistemi za nadzor različic so se razvili zaradi formaliziranja postopkov za sledenje sprememb v dokumentih. Dovoljujejo vrnitev v prejšnje stanje, za primere, v katerih je razvoj dosegel slepo ulico pri razvoju. Prav tako se v razvoju računalniške programske opreme za nadzor različic smatra vsaka praksa, ki sledi spremembam in zagotavlja nadzor nad spremembami
12 izvorne kode. Razvijalci programske opreme včasih uporabljajo sisteme za nadzor različic za vzdrževanje dokumentacij in konfiguracijskih datotek, kot tudi za nadzor izvorne kode.
Teoretično je te sisteme mogoče uporabljati za vse vrste zapisov podatkov. V praksi pa se ta orodja le redko uporabljajo zunaj razvoja programske opreme.
Slika 1: Vizualizacija sistema za nadzor različic [8]
Med načrtovanjem, razvojem in nameščanjem programske opreme se pogosto dogaja, da se na različne lokacije namesti različne verzije programske opreme in da razvijalci istočasno delajo popravke na teh različnih verzijah. Hrošči (programske napake) ali značilnosti programske opreme, so pogosto prisotni le v nekaterih različicah. Zato je za lociranje in določanje hroščev zelo pomembno, da se lahko pridobijo in vodijo različne različice programske opreme. S takšnim vodenjem se lahko ugotovi, v kateri različici se pojavi problem. V veliko primerih bi bilo potrebno sočasno razviti dve različici programske opreme.
13 Ena različica bi se uporabljala za reševanje programskih napak (hroščev), (branch – veja/podverzija). Druga različica pa bi bila namenjena izključno razvijanju novih funkcionalnosti (trunk - tekoča verzija).
V bistvu lahko razvijalec pridobi več kopij iste programske opreme in jih primerno označi. Ta način lahko deluje, vendar je nekoliko neučinkovit, saj je potrebno vzdrževati veliko število skoraj identičnih kopij programa.
Problem, ki se pojavi v velikih projektih razvoja programske opreme je, da več razvijalcev skuša popravljati isti del programa ob istem času. Če dva razvijalca poskušata spremeniti isto datoteko ob istem času, ne da bi pri tem uporabljala metode za upravljanje dostopa, se lahko zgodi, da na koncu prepišejo delo drug drugega.
Večina sistemov za nadzor različic uporabljajo sistem imenovan delta stiskanje (delta compression [6]), v katerem so ohranjene le razlike med zaporednimi različicami datotek, kar omogoča učinkovito shranjevanje mnogih različic istih datotek in tudi zmanjša porabo prostora.
Nekateri sistemi zagotavljajo metode za preprečevanje težav sočasnega dostopa s preprostim zaklepanjem datotek, tako da ima le en razvijalec pisalni dostop do centralnega skladišča naenkrat. Drugi sistemi pa zagotavljajo možnosti avtomatskega ali polavtomatskega združevanja sprememb.
Nekatera bolj napredna orodja za nadzor različic ponujajo številne druge vsebine, ki omogočajo večjo integracijo z drugimi orodji in procesi za razvoj programske opreme.
Različni vtičniki (plug-in) so pogosto na voljo za integrirana razvojna okolja (IDE), kot je na primer ''Visual Studio''.
V nadaljevanju bodo sistemi za nadzor različic bolj podrobno opisani, tako bomo v naslednjem poglavju na kratko opisali zgodovino le-teh. Sledilo bo poglavje o funkcionalnosti teh sistemov, kjer bomo povedali nekaj o načinih upravljanja z izvorno kodo, ki jo hranijo takšni sistemi ter o združevanju izvorne kode. Nato se bomo osredotočili na današnje bolj priljubljene sisteme za nadzor različic. Nekatere bomo na kratko opisali, povedali njihove prednosti in slabosti, naredili primerjavo funkcionalnosti med njimi ter povedali, zakaj so takšni sistemi priporočljivi. V poglavju o prihodnosti teh sistemov bo govora o idealnem
14 sistemu, ki bi pokril slabosti dosedanjih sistemov. V zaključku pa bo sledil kratek povzetek napisane zaključne naloge in moje izkušnje z uporabo sistemov za nadzor različic.
15 2. ZGODOVINA SISTEMOV ZA NADZOR RAZLIČIC
V tem poglavju bomo na kratko opisali zgodovino razvoja sistemov za nadzor različic, ki so veliko doprinesli k razvoju modernih sistemov za nadzor različic. [7]
Razvoj sistemov lahko razdelimo na tri obdobja oziroma generacije, v katerih so se zgodile večje spremembe v funkcionalnosti in uporabnosti. [1]
2.1 Prva generacija
Skupna značilnost prve generacije sistemov za nadzor različic je, da so bili vsi datotečno usmerjeni in centralizirani. Večina jih je temeljila na zaklepanju datotek. Sistemi, ki so podpirali združevanje, pa so prišli proti koncu tega obdobja.
''Prazgodovina'' sistemov za nadzor različic
Lahko bi rekli, da sistemi za nadzor različic izhajajo iz upravljanja sprememb in sistemov beleženja uporabljenih na velikih računalnikih v 1960-ih letih. Treba je omeniti, da je bil prvi sistem za nadzor različic prvotno napisan na računalniku IBM System/370, na katerem je tekel operacijski sistem OS/MVT.
Source Code Control System (SCCS)
Na začetku razvoja sistemov za nadzor različic je bil SCCS. Tega je leta 1972 napisal Marc Rochkind, eden od zgodnjih Unix razvijalcev v podjetju Bell Labs. SCCS je uporabljal zaklepanje datotek kot metodo, ki je preprečevala razvijalcem, da prepišejo delo drug drugega. Bil je datotečno usmerjen in centraliziran. Ni imel podpore za oddaljen dostop (prek mreže) do repozitorija. Ta sposobnost sistemov, vse do vzpona interneta proti koncu leta 1982, ni bila predstavljiva, saj internet do takrat ni bil razširjen.
SCCS je bil posebej zasnovan za upravljanje programske opreme in je imel dobro opredeljeno pojmovanje zgodovine revizije z enolično identifikacijsko oznako za vsako revizijo. Ta funkcija še danes opredeljuje vse sisteme za nadzor različic.
16 SCCS je že zdavnaj izginil iz splošne rabe, vendar je razvil koncepte, ki so še vedno zelo navzoči v današnjih sistemih za nadzor različic. Mnogi današnji sistemi še vedno uporabljajo stil oštevilčevanja različic, ki izhaja iz SCCS sistema (glavna različica in revizija, ki sta ločeni s piko).
Revision Control System (RCS)
RCS, Revision Control System, je bil drugi najstarejši sistem za nadzor različic, ki pa je še vedno v splošni rabi. Napisal ga je Walter F. Tichy na Purdue University v zgodnjih 1980-ih.
Kot SCCS, na katerega je bil neposreden odziv, je RCS prav tako uporabljal metodo zaklepanja datotek za preprečevanje prepisovanja kode in je bil centraliziran. Prav tako ni imel zmogljivosti za oddaljen dostop do repozitorija.
Za razliko od SCCS, pa je RCS še vedno v precej široki uporabi. RCS je majhna in kompaktna aplikacija in ima malo odvečnih podatkov/informacij (low-overhead) v primerjavi z novejšimi in bolj sposobnimi sistemi za nadzor različic.
Razvijalci pogosto uporabljajo RCS za ohranjanje zgodovine posameznih dokumentov in manjših nezahtevnih programov.
RCS je od samega začetka odprtokodni sistem in je še vedno pogosto nameščen na današnjih Linux in Unix sistemih.
DSEE/ClearCase
DSEE (Domain Software Engineering Environment) je sistem za nadzor različic s pomembnimi funkcijami, ki vključujejo prevajalnik izvorne kode in sledilec opravil oziroma nalog. Prvič je bil izdan leta 1984, in sicer na delovnih postajah Apollo Domain. Apollo je bil kupljen s strani HP-ja leta 1989, ki je DSEE še vedno veliko uporabljal. Ekipi DSEE je bilo na koncu dovoljeno oditi in ustvariti sistem z imenom Atria. DSEE so izdali pod drugo znamko, poimenovali so ga ClearCase. Kasneje je sistem Atria pridobilo podjetje IBM in je še vedno v široki uporabi, vendar pod imenom Rational ClearCase.
17 2.2 Druga generacija
Glavni razlog za nadaljevanje razvoja sistemov za nadzor različic je postala vse večja uporaba interneta. Dotedanji sistemi so delovali le lokalno, torej na istem računalniku. Z uveljavitvijo interneta pa se je pojavila potreba po skupnem razvoju. Glavna značilnost druge genaracije sistemov za nadzor različic je podpora interneta, torej omogočanje skupnega razvoja.
Concurrent Versions System (CVS)
RCS je bil razvit pred uveljavitvijo/množično uporabo interneta/mreže in se ni uspel prilagoditi poterbi po skupnem razvoju.
CVS se je začel uporabljati okoli leta 1989-1990, vendar še vedno v lokalnem načinu (odjemalec in repozitorij na istem računalniku). Bolj množična uporaba se je začela šele po tem, ko sta Jim Blandy in Karl Fogel izdala nekatere popravke, s katerimi so omogočili dostop do CVS centralnega skladišča preko povezave TCP/IP. To se je zgodilo konec leta 1994, takoj po prvem velikem valu uporabe interneta.
CVS je bil še vedno datotečno usmerjen in centraliziran, tako kot njegovi predhodniki. Velika novost pa je bila ta, da je bil namenjen za skupen razvoj, torej je omogočal eno centralno skladišče za več razvijalcev. Namesto zaklepanja datotek je uporabljal pristop, ki temelji na združevanju datotek. Skoraj vsi nadaljnji sistemi so sledili temu novemu pristopu združevanja datotek. Prav tako so sprejeli tudi terminologijo CVS-ja in so celo vmesnik za ukazno vrstico prilagodili izgledu vmesnika, ki ga je uporabljal CVS.
Z vsemi temi novostmi in napredkom pa je prišlo tudi do velikih težav. Premikanje ali preimenovanje datotek v CVS repozitoriju je bilo slabo podprto in je lahko povzročilo resne težave. Do poznih 1990-ih je bilo jasno, da arhitektura CVS preprosto ni dovolj močna, da bi podpirala vse te željene novosti in tako je prišla potreba po njegovem nasledniku.
Od samega začetka je bil CVS odprtokodni sistem in je še dandanes nameščen na Linux in Unix sistemih.
18 Subversion (SVN)
V poznih 1990-ih je bilo več poskusov reševanja CVS-ja in njegove osnovne arhitekture.
Noben od teh poskusov ni uspel. Potreben je bil nov pristop.
Leta 2000 je skupina, vključno z nekaterimi prvotnimi razvijalci CVS jedra, začela projekt imenovan Subversion. Ta projekt je bil izrecno namenjen izboljšanju in nadomeščanju CVS- ja. Subversion je znan tudi kot SVN. Njihov prvi uradni proizvod je v javnost prišel leta 2004.
Eden od učinkov Subversion je bila reforma in do neke mere standardizacija žargona oziroma terminologije, ki se uporablja pri sistemih za nadzor različic. Standardizirali so tudi slog vmesnika ukazne vrstice. Terminologijo, ki se je uveljavila s CVS-jem, so nadgrajevali in izboljšali ter v nekaterih primerih tudi boljše opisali oziroma počistili.
SVN je najboljši centralizirani sistem za nadzor različic, vendar pa je zadnji svoje vrste. Z razvojem in vse večjo uporabo interneta, je prišla vse večja potreba po razvoju porazdeljenih sistemov za nadzor različic. Tako so porazdeljeni sistemi za razvoj programske opreme postali bolj pravilo kot izjema. Centraliziranim modelom za nadzor različic je tako zmanjkalo pare, prav tako kot se je to zgodilo datotečno usmerjenim sistemom leta 1990 z razvojem CVS-ja.
SVK
SVK je plast na vrhu Subversion (SVN) sistema. Je prav tako porazdeljen sistem za nadzor različic, vendar za razliko od Subversion-a ima implementiran močnejši algoritem za združevanje izvorne kode. Na skoraj enak način kot je CVS uporabljal RCS infrastrukturo za implementacijo bolj naprednega modela za nadzor različic pa SVK uporablja Subversion za implementacijo bolj zmogljivega modela za združevanje.
Vendar pa je prav tako kot CVS, tudi SVK nekakšna mešanica sistemov druge generacije. V to generacijo spada, ker ni čisto v celoti porazdeljen sistem. Prav tako kot CVS, je tudi ta sistem podedoval nekatere zasnovne omejitve v arhitekturi.
19 2.3 Tretja generacija
V tretjo generacijo sistemov za nadzor različic spadajo sistemi, ki so v celoti porazdeljeni.
The Arch family
Arch je bil pionir diagnostičnih lastnosti tretje generacije sistemov za nadzor različic. Temelji na združevanju in ne na zaklepanju datotek, shranjuje vse množice sprememb (Change set-e) datotek in je v celoti porazdeljen sistem.
Njegova zasnova je znana po briljantnih idejah, ki pa jih kvari uporabniški vmesnik. Ta je bil zelo slabo dokumentiran, zapleten in posledično zelo težek za uporabo.
Prva različica tega sistema je bila javnosti dostopna januarja 2002, toda do leta 2005 se je razvoj GNU Arch sistema ustavil. Kljub temu se je razvoj nadaljeval z drugimi vejami, ki so izšle iz tega sistema (ARX, Bazaar 1.x).
Monotone
Sistem Monotone je napisal Graydon Hoare in je bil prvič izdan v začetku leta 2003. Velik vpliv na njegov zgodnji razvoj je imel Arch. Kasneje pa je Monotone vplival na razvoj in oblikovanje sistema Mercurial ter najverjetneje tudi na razvoj sistema Git.
Prav tako kot Arch, je imel Monotone pomemben vliv na razvoj ostalih sistemov za nadzor različic tretje generacije. Sam pa ni nikoli pridobil veliko uporabnikov in niti ni dosegel kakšne večje oblikovne zmage. Performančne težave niso bile nikoli povsem rešene. Zaradi tega je bil njegov avtor leta 2007 primoran podjetju Mozilla priporočiti sistem Mercurial za potrebe njihovih projektov.
BitKeeper (BK)
BitKeeper je zasnoval Larry McVoy. Temelji na združevanju in ne na zaklepanju datotek, shranjuje vse množice sprememb (Change set-e) datotek in je v celoti porazdeljen sistem.
20 V zgodnjem razvoju sistema BitKeeper se je avtor odločil, da bo kot izhodiščno točko za razvoj uporabil jedro Linuxa ter da bo sistem prilagodil tako, da bo ustrezal in podpiral močno porazdeljen stil razvijalcev jedra Linux.
Leta 2002 je McVoy uspešno prepričal Linusa Torvaldsa (avtorja operacijskega sistema Linux), da sprejme BitKeeper, ne glede na številno skrb razvijalcev jedra zaradi nekaterih klavzul v McVoyjevi lastniški licenci. 1. julija 2005, po polemiki o domnevno prepovedanem obratnem inženirstvu, je McVoy umaknil brezplačno različico jedra Linux, na kateri so sloneli njeni razvijalci. Torvalds je po tem takoj opustil BitKeeper.
Najpomembnejši dolgoročni rezultat tega poloma je verjetno ta, da se je utrdilo odprtokodno stališče o licenciranju. Zdaj je dejansko nemogoče, da bi Linux ali druge širše odprtokodne skupnosti sprejele sistem za nadzor različic z zaprto-kodno (closed-source) licenco.
Ne glede na vse, je McVoy veliko pripomogel k razvoju sistemov za nadzor različic. Nastale so številne ideje, ki so postale pomembne v kasnejših modelih sistemov za nadzor različic.
Najbolj pomembni sta predvsem predstavitev zgodovine kot množice sprememb in operacija oddajanje pred združevanjem (commit-before-merge).
Med leti 2002 in 2005 so se razvijalci nekaterih odprtokodnih sistemov za nadzor različic odločili, da je potrebno premagati nabor funkcij BitKeeperja. Po polomu McVoya leta 2005, sta izšla dva druga odprtokodna sistema za nadzor različic (Mercurial in Git). Oba sta imela isti cilj, to je zadostiti potrebam razvijalcev jedra Linux, ki so imeli bogate izkušnje z BitKeeperjem.
Git
Linus Torvalds je razvil Git leta 2005. Nastal je z namenom, da bi si opomogli po polomiji v zvezi z BitKepeerjem. Tako kot drugi sistemi za nadzor različic tretje generacije, je tudi ta temeljil na združevanju kode, ne pa zaklepanju datotek in je bil popolnoma porazdeljen.
Vendar pa je način, s katerim Git pridobiva informacije o stanju projekta, nekoliko nenavaden. Usmerjen je proti sledenju vsebine celotnega projekta, ne obravnava pa posameznih datotek kot pomembne dele celote.
21 3. FUNKCIONALNOST SISTEMOV ZA NADZOR RAZLIČIC
Sisteme za nadzor različic lahko razdelimo dva na modela upravljanja izvorne kode:
- centraliziran model, - porazdeljen model.
3.1 Modela za upravljanje izvorne kode
3.1.1 Centraliziran model upravljanja
Tradicionalni sistemi za nadzor različic uporabljajo centraliziran model, kjer vse funkcije nadzora različic potekajo na skupnem strežniku.
Če dva razvijalca poskušata spremeniti isto datoteko ob istem času, ne da bi uporabljala kakšno metodo za upravljanja dostopa, se lahko zgodi, da razvijalci na koncu prepišejo delo drug drugega. Centralizirani sistemi za nadzor različic rešijo ta problem na enega od naslednjih dveh načinov: z zaklepanjem datotek ali pa z združevanjem različic.
Slika 2: Centraliziran model upravljanja
Zaklepanje datotek:
Najenostavnejši način za preprečevanje težav s sočasnih dostopom do iste datoteke temelji na zaklepanju datotek. Na ta način lahko le en razvijalec naenkrat piše v datoteko, ki se nahaja v centralnem skladišču kopij teh datotek.
Ko en razvijalec naredi "check out" datoteke, lahko drugi razvijalci le berejo to datoteko, vendar je nihče drug ne more spreminjati. Ustvarjanje novih sprememb na tej datoteki se
22 omogoči takrat, ko razvijalec, ki je prej naredil ''check out'' datoteke, naredi '' check in'' popravljene datoteke ali pa odpove obstoječi ''check out''.
Slika 3: Zaklepanje datotek [18]
Zaklepanje datotek ima prednosti in slabosti. Zagotavlja določeno zaščito pred konfliktnimi združitvami, v primeru, ko uporabnik (razvojnik) naredi kakšne korenite spremembe v datoteki (ali skupini datotek). Vendar pa v primeru, da so datoteke s strani razvijalca zaklenjene predolgo, lahko privede do upočasnitve razvoja. Druge razvijalce lahko prav tako zamika, da zaobidejo programsko revizijo nadzora datotek in spreminjajo datoteke na lokalni ravni, kar lahko vodi do bolj resnih težav.
Združevanje verzij:
Večina sistemov za nadzor različic omogoča večjemu številu razvijalcev urejanje/spreminjanje istih datotek ob istem času. V teh primerih prvemu razvijalcu "check in" spremembe v centralno skladišče vedno uspe. Za ostale razvijalce pa sistem omogoči možnost združevanja nadaljnjih sprememb v osrednjem skladišču in hkrati tudi ohrani spremembe prvega razvijalca, ko drugi razvijalci naredijo ''check in''.
23
Slika 4: Združevanje verzij [18]
Združevanje dveh datotek je lahko zelo občutljiva operacija in je običajno mogoča le v primeru, če je struktura podatkov enostavna. Enostavna struktura podatkov je na primer besedilna datoteka. Drugi razvijalec, ki naredi ''check in'' sprememb datotek, bo moral poskrbeti za pravilno združitev in se prepričati, da so spremembe združljive in da operacija združevanja ne uvaja lastno logiko napak znotraj datotek. Težave lahko omejujejo z avtomatsko ali polavtomatsko operacijo združevanja, ki pa ni vedno omogočena oziroma podprta s strani uporabljenega sistema za nadzor. V glavnem so takšne operacije združevanja mogoče le pri preprostih tekstovnih dokumentih.
Najbolj znani centraliziran sistem za nadzor različic je Subversion, čeprav velika podjetja pogosto uporabljajo bolj komercialne izdelke kot so ClearCase ali Perforce.
3.1.2 Porazdeljen model upravljanja
Porazdeljeni sistemi za nadzor različic uporabljajo pristop vsak z vsakim (peer-to-peer). V nasprotju s tem pa centralizirani sistemi uporabljajo pristop klijent-strežnik.
24 Namesto da bi se uporabljajo eno samo centralno skladišče za usklajevanje (sinhronizacijo) verzij, vsak razvijalec dobi delovno kopijo programske kode. Porazdeljeni sistemi za nadzor različic opravljajo sinhronizacijo sprememb z izmenjavo popravkov (množico sprememb) med vsemi razvijalci na način komunikacije vsak z vsakim (peer-to-peer).
Tu se pokažejo nekatere pomembne razlike s centraliziranim sistemom: [4]
- Ne obstajajo kanonične referenčne kopije izvorne kode, ampak samo delovna kopija.
- Operacije, kot so ''potrjevanje sprememb, pregled zgodovine in povrnitev sprememb'', so hitre, saj ni potrebe po komunikaciji s centralnim strežnikom.
- Komunikacija je potrebna le, kadar se nalaga (push) spremembe drugim razvijalcem ali pa se jemlje (pull) spremembe drugih razvijalcev.
- Vsaka delovna kopija deluje tako učinkovito kot varnostna kopija izvorne programske kode in vsebuje vse njene spremembe in zgodovino. Tako se zagotavlja zaščita pred izgubo podatkov.
Slika 5: Porazdeljen model upravljanja
Najbolj popularni porazdeljeni sistemi za nadzor različic so Git in Mercurial.
3.2 Združevanje
Združevanje (imenovano tudi integracija) v sistemih za nadzor različic je osnovna operacija, ki združuje spremembe na zbirki datotek shranjenih v sistemu za nadzor različic.
Najpogosteje je ta operacija potrebna, kadar datoteko hkrati spreminjata dve osebi na dveh različnih računalnikih. Rezultat združitve teh dveh datotek oziroma vej projekta je enotna zbirka datotek, ki vsebuje obe množici sprememb datotek.
25
Slika 6: Združevanje [11]
Operacijo združevanja je v nekaterih primerih mogoče opraviti avtomatično, torej brez pomoči uporabnika. To je možno izvesti le takrat, ko spremembe v datotekah, ki jih hočemo združiti niso v konfliktu. V drugih primerih pa se mora oseba, ki opravlja operacijo združevanja odločiti, katere popravke mora vsebovati datoteka, ki jo združuje. Npr.: če dva razvijalca popravljata isti dokument, a popravljata vsak na svojem koncu dokumenta, je združevanje mogoče opraviti avtomatično, brez posredovanja uporabnika. Če pa oba razvijalca popravljata dokument na istem koncu oziroma popravljata isto metodo, potem pri združevanju velikokrat nastane konflikt in je potrebno posredovanje uporabnika. Združevanja tako ni mogoče opraviti avtomatično. [2]
Orodja za združevanje so dandanes prisotna v vseh novejših sistemih za nadzor različic.
Opisali bomo različna načina združevanja, ki sta danes najpogosteje uporabljena v sistemih za nadzor različic. Sledil bo pa še opis vrst združevanja.
26 3.2.1 Načini združevanja (algoritmi združevanja)
Obstajata dve glavni vrsti združevanja [10], ki jih izvajajo avtomatizirana orodja za združevanje:
- (2-way) dvosmerno združevanje, - (3-way) trosmerno združevanje.
(Two-way) dvosmerno združevanje
Dvosmerno združevanje izvaja avtomatizirano analizo razlik med datoteko 'A' in datoteko 'B'.
Ta metoda oceni oziroma primerja razlike med datotekama in na podlagi teh razlik izvede združevanje. Rezultat združevanja se naredi na podlagi ("best-guess") analize najboljše ocene.
Zaradi tega je ta vrsta združevanja običajno najbolj nagnjena k napakam in zahteva posredovanja uporabnika. Ta mora preveriti in včasih tudi pravilno popraviti rezultat združevanja, preden se operacija združevanja dokončno zaključi.
(Three-way) trosmerno združevanje
Trosmerno združevanje se izvede po avtomatizirani analizi razlik med datoteko 'A' in datoteko 'B'. Pri tej analizi se upošteva tudi izvorna datoteka oziroma starš obeh datotek. Ta vrsta združevanja je bolj primerna za uporabo v sistemih za nadzor različic, saj zagotavlja obstoj in znanost matične datoteke obstaja. Orodje za združevanje ocenjuje razlike in vzorce med obema datotekama kot tudi spremembe teh dveh datotek v primerjavi s staršem (izvorno datoteko). Na podlagi tega se vzpostavi relacijski model za združevanje datotek 'A', 'B', in starša 'C', iz katerega se proizvede nova različica 'D'.
Ta vrsta združevanja je najbolj zanesljiva in se v praksi dobro obnese. Potreba po posredovanju uporabnika pa se močno zmanjša. V mnogih primerih se posredovanja sploh ne zahteva, zaradi česar je ta vrsta združevanja primerna za avtomatizacijo procesa združevanja.
3.2.2 Vrste združevanja
Tekstovno združevanje
Programska koda se pri tekstovnem združevanju šteje kot besedilna datoteka. Najmanjši objekti, ki se uporabljajo za združevanje, so vrstice v tej datoteki. To pomeni, da se pri
27 iskanju razlik med datotekami primerjajo posamezne vrstice. Primerja se, če so bile vrstice dodane, izbrisane ali spremenjene, vendar pa ta pristop ni dovolj natančen, saj v primeru večjega števila sprememb iste vrstice teh sprememb ni mogoče enostavno obravnavati.
Dve datoteki imata isto število vrstic in vsebino, npr.: "To je komentar." in "To je dober komentar.". Ti dve vrstici se lahko logično združita v eno vrstico: "To je dober komentar.".
Vendar pri tekstovni vrsti združevanja to ni tako enostavno, saj ta vrsta ne more ugotoviti razlike znotraj ene vrstice. Izbere se lahko samo ena sprememba, ne pa obe, zato mora uporabnik ročno združiti to spremembo v vrstici.
Kljub slabostmi, ki jih ima ta vrsta pa je tekstovno združevanje zelo koristno zaradi svoje učinkovitosti, razširljivosti in njene zadovoljive točnosti. [3]
Sintaktično združevanje
Orodja za združevanje, ki temeljijo samo na besedilu (besedilno združevanje), pogosto javljajo nepomembne konflikte v datoteki kot so to na primer prelomi vrstic ali komentarji.
Pri sintaktičnem združevanju pa konflikt pri združevanju datotek nastane samo takrat, ko se sintaksa datotek ne ujema.
Na splošno je takšna orodja združevanja mogoče razvrstiti glede na njihovo osnovno strukturo podatkov: drevesa ali grafi.
Primer sintaktičnega združevanja, ki uporablja drevesno strukturo, je mogoče najti, kjer so programi hierarhično razdeljeni v razrede, postopke in funkcije. Vsak program je predstavljen kot drevo, kjer vozlišča (listi) vsebujejo dejanske podatke in pot do vozlišča, ki predstavlja tip (razred, postopek, itd ..). [3]
Semantično združevanje
Ta vrsta združevanja temelji na semantični strukturi programske kode. Na ta način se ugotovijo tudi nekateri konflikti, ki se s sintaktičnim preverjanjem ne zaznajo.
Dva razvijalca, A in B, hkrati sodelujeta na razvoju programske kode. Razvijalec A se odloči, da spremeni ime spremenljivke count v cnt. B na drugi strani pa se na odloči za spremembo
28 funkcije fac v proceduro in doda drugo spremenljivko arg za optimizacijo te procedure. Pri združevanju teh sprememb je struktura procedure še vedno sintaktično pravilna, vendar pa se pojavi sintaktični konflikt. Končna združena različica procedure vsebuje pogoj (arg == 1), vendar spremenljivka arg v tej proceduri ne obstaja. Zaradi tega je končno združena različica semantično nepravilna.
Združevanje, ki uporablja drevesno strukturo, tega konflikta ne bi moglo odkriti, medtem ko pristop, ki temelji na grafu, ta konflikt uspešno odkrije, saj graf ohranja jasno povezavo med definicijo in klicem funkcije/procedure. Zaradi tega je zmožen odkrivati nezdružljivosti med njima. [3]
Slika 7: Semantično združevanje [3]
29 Strukturno združevanje
Refaktoriranje in prestrukturiranje sta pomembni tehniki, ki preprečujeta staranje programske opreme. Refaktoriranje ohranja lastnosti, ne spreminja pa obnašanja programske kode oziroma njene semantike, vendar bistveno spremeni strukturo programske kode. Strukturni konflikti pri združevanju se pojavijo, ko naredimo spremembe strukturnega značaja in algoritem združevanja ne ve, katere strukturne spremembe uporabiti oziroma upoštevati.
Primer:
Prvi razred, z imenom Vozila, je sestavljen iz treh podrazredov: avto, tovornjak in kolo.
Razvijalec A se odloči, da bo v ta razred vključil še en dodaten podrazred z imenom motorno kolo, razvijalec B se nato odloči, da bo razred Vozila refaktorial z namenom, da bi ga kategoriziral. Konflikt pri strukturnem združevanju se pojavi, ko se poskuša dodati ta nov razred motorni kolo v razred Vozila. Pojavi se vprašanje ali je treba dodati nov razred neposredno na razred Vozila ali pa ga je treba dodati kot podrazred razreda Motor. Ni težko ugotoviti, da je nov razred treba dodati kot podrazred razreda Motor. Te vrste konfliktov združevanja je treba ročno rešiti, na žalost pa večina komercialnih orodij za združevanje ne podpira strukturnega združevanja. [3]
Slika 8: Strukturno združevanje [3]
30 3.3 Trendi
Tehnični napredek, ki je prišel s trosmernim načinom združevanja, je med razvijalci programske opreme privedel do vse večje priljubljenosti uporabe vejanja projektov za lažje sočasno delo na njih, saj se je namreč vse do sredine 1990-ih vejanje v manjših skupinah za razvoj programske opreme odsvetovalo. To pa predvsem zaradi zapletenosti in konfliktov, ki so nastali kasneje s procesom združevanja nastalih vej in zaradi pomanjkanja stroškovno učinkovitih orodij, ki so podpirali trosmerno združevanje.
V začetku prejšnjega desetletja (leta 2000) se je povečala razpoložljivost zanesljivih orodij, ki podpirajo trosmerno združevanje. Nova orodja so zmanjšala čas, ki so ga razvojne programske skupine porabile za združevanje. Kljub temu pa združevanje še vedno pogosto povzroča težave. Celo inteligentna orodja za združevanje ne morejo rešiti vseh konfliktov samodejno. Za to je še vedno potrebna človeška interakcija, ki pa lahko privede do človeških napak.
Trosmerno združevanje je še vedno ena najbolj zahtevnih in časovno potratnih nalog katerekoli ekipe za razvoj programske opreme. Oseba, ki je zadolžena za združevanje, mora imeti predhodnje poznavanje izvorne kode, obveščena mora biti o vseh nastalih spremembah izvorne kode in mora vedeti, katere spremembe se želijo na novo uvesti.
31 4. SISTEMI ZA NADZOR RAZLIČIC DANES
Nadaljnje poglavje je v celoti posvečeno opisom današnjih najbolj uporabljenih sistemov za nadzor različic. Podane so tudi primerjalne tabele teh sistemov, kjer so navedene tehnične značilnosti oziroma razlike opisanih sistemov ter njihove tehnične informacije.
Del poglavja je namenjen tudi prednostim in slabostim, ki jih prinašajo sistemi za nadzor različic in napotki za izbiro ustreznega sistema.
4.1 Opis nekaterih sistemov za nadzor različic
Izmenjevanje datotek brez uporabe sistemov za nadzor poteka lahko po elektronski pošti, z nalaganjem datotek ali pa s pomočjo kakšne druge metode, vendar pa je takšen način izmenjevanja precej mučen in časovno potraten. Sistemi za nadzor revizij nam ponujajo odličen način za soočanje s težavo izmenjave datotek.
Nekateri sistemi za nadzor različic: [13]
- Microsoft Visual SourceSafe (VSS), - TFS (Team foundation server), - CVS,
- Git, - Bazaar,
- SVN (Apache Subversion).
V nadaljevanju so opisani zgoraj našteti sistemi za nadzor različic.
4.1.1 VSS (Visual SourceSafe)
Microsoft Visual Source Safe (VSS) je programski paket za nadzor različic. Usmerjen je v manjše projekte za razvoj programske opreme. SourceSafe ustvari virtualno knjižnico računalniških datotek. Najpogosteje se uporablja za nadzor izvorne programske kode, je pa lahko dejansko primeren za vse vrste datotek. [14]
32 SourceSafe sprva ni bil sistem za nadzor različic, ki bi deloval po arhitekturi odjemalec- strežnik, ampak samo lokalno nameščen sistem za nadzor različic. Arhitekturno gledano je bila tako prednost kot tudi slabost oblikovanja. Omogoča namestitev enouporabniškega sistema. Prednost tega je, da se ta namesti z manj konfiguracijami kot pa nekateri drugi sistemi za nadzor različic. Za namestitev okolja, ki podpira več uporabnikov pa mu vendarle manjka veliko pomembnih funkcij, ki jih najdemo v drugih proizvodih. Glavna slabost je pomanjkanje podpore za atomske (atomarne) potrditve (comit-e) večjega števila datotek.
SourceSafe podeduje funkcionalnost dajanja datotek v skupno rabo (share) z uporabo neposrednega daljinskega dostopa (remote access) do datotečnega sistema za vse datoteke v skladišču. VSS-ju je leta 2005 podjetje Microsoft uvedlo arhitekturo odjemalec-strežnik.
Datoteke so na VSS-ju dostopne prek VSS odjemalskega orodja.
Kritike: Stabilnost Visual SourceSafe je kritizirana zato, ker uporablja neposreden mehanizem za dostop do datotek, ki omogoča kateremu koli odjemalcu/uporabniku, da lahko potem, ko datoteko zaklene, le to tudi spremeni. Če se računalnik sredi posodabljanje datoteke sesuje (npr.: kot posledica velike napake), lahko to poškoduje spremenjeno datoteko.
Prihodnost: Posodobljena različica se imenuje Visual SourceSafe 2005 in je izšla novembra 2005. Obogatena je z izboljšano zmogljivostjo in stabilnostjo, boljšo združitvijo za Unicode in XML datoteke kot tudi možnostjo preverjanja datotek prek HTTP protokola.
Hkrati je Microsoft predstavil tudi sistem za nadzor in projektno upravljanje življenjskega cikla izdelka, ki se imenuje Team Foundation Server. Ta izdelek obravnava mnogo pomanjkljivosti Visual SourceSafea. Zaradi tega je tudi bolj primeren za večje skupine, ki zahtevajo visoko stopnjo stabilnosti in nadzor nad dejavnostmi.
Zgodovina: SourceSafe je bila prvotno ustanovljen z družbo imenovano One Tree Software.
One Tree SourceSafe je šel skozi več izdaj, od verzij 1.x in 2.x, ki so podpirale operacijske sisteme DOS, OS/2 (z Presentation Manager GUI), Windows, Windows NT, Mac in Unix. Ko je Microsoft leta 1994 kupil OneTree, je ta takoj prenehal z razvojem izdelka vseh različic, razen različice za operacijski sistem Windows. Microsoft "Visual SourceSafe 3.1", ki je bil izdan za 16-bitne Windowse, je bil le prenovljena različica One Tree 3,0 različice. Ta različica je bila na voljo le kratek čas, saj je Microsoft kmalu zatem izdal novo različico 4.0.
33 4.1.2 TFS (Team Foundation Server)
Team Foundation Server (pogosto skrajšano na TFS) je Microsoftov izdelek, ki ponuja nadzor nad določenim virom, zbiranje podatkov, poročanje in projekt sledenje ter je namenjena skupinskemu razvoju projektov in programske opreme. [16]
Team Foundation Server deluje v tri slojni arhitekturi: nivo odjemalca, aplikacijski nivo in podatkovni nivo. Nivo odjemalca se uporablja za ustvarjanje in upravljanje projektov in dostopa do elementov, ki so shranjeni in se upravljajo za projekt. TFS ne vključuje uporabniškega vmesnika za ta nivo, izpostavlja pa spletno storitev, ki jo lahko aplikacija odjemalca uporabljajo za povezovanje s TFS funkcionalnostmi. Zmogljivosti so izpostavljene prek spletnih storitev, ki jih nato uporabljajo odjemalske aplikacije kot je VisualStudio Team IDE sistem. Aplikacijski nivo vsebuje tudi spletni portal in skladišče za dokumente. Skladišče se uporablja za elemente projekta in sledenje sprememb kot tudi za zbiranje podatkov in ustvarjanje poročil. Podatkovni sloj pa je v bistvu SQL Server 2005 Standard Edition, ki zagotavlja trajne storitve za shranjevanje podatkov v skladišče dokumentov. Podatkovni nivo in aplikacijski nivo lahko obstajata tudi na različnih fizičnih ali virtualnih strežnikih.
Večina dejavnosti v Team Foundation Server se vrti okoli nalog/opravil. Naloga je ena enota dela, ki jo je treba izpolniti. Naloge so lahko različnih vrst kot na primer Bug, Task, Quality of Service, scenariji in tako naprej. Ogrodje (platforma) izbrano za katerikoli projekt v Team Foundation Server določa, katere vrste nalog so na voljo in kakšne lastnosti vsaka naloga vsebuje. Naloge so shranjene v XML formatu. Njihova shema se lahko prilagodi na primer z dodajanjem drugih atributov na različne naloge ali pa se ustvarijo novi elementi na podlagi določenega projekta. Vsaka naloga je povezana z nadzorno politiko, ki določa, kdo lahko dostopa do naloge in/ali lahko spreminja nalogo. To vključuje tudi obveščanje in beleženje sprememb pri nalogah. Po želji pa lahko določene uporabnike samodejno obvesti, ko se naloge spremenijo.
4.1.3 CVS
Sistem za nadzor vzporednih različic izvorne kode (CVS) je brezplačna programska oprema za revizijo na področju razvoja programske opreme. Beleži vse delo in vse
34 spremembe v naboru datotek in omogoča več sočasnih razvijalcev. CVS je postal priljubljen s komercialnimi razvijalci programske opreme ter tudi v odprtokodni skupnosti razvijalcev programske opreme. Izdan je pod licenco GNU (General Public License). [17]
CVS uporablja odjemalec-strežnik arhitekturo: strežnik shrani trenutno različico projekta in njegovo zgodovino ter uporabnike povezane s strežnikom. Tako se omogoči "check out"
celotne kopije projekta, delo na tem izvodu in kasneje "check in" vseh sprememb.
Programska oprema za nadzor je nameščena na strežniku. CVS odjemalci/uporabniki pa lahko uporabljajo odjemalsko opremo na katerikoli večji platformi oziroma operacijskem sistemu.
Več razvijalcev lahko dela na istem projektu hkrati, vsak ureja datoteke v svoji "delovni kopiji" projekta ter pošilja (ali ''check in-a'') svoje spremembe na strežnik. Da bi se izognili možnosti prepisovanja dokumentov, bo strežnik sprejel spremembe le na najnovejši različici datoteke. Od razvijalcev se zato pričakuje, da obdržijo svojo delovno kopijo usklajeno z zadnjo verzijo. To naredijo tako, da v svojo delovno kopijo na redni osnovi vključujejo spremembe drugih ljudi. To nalogo velikokrat samodejno ureja CVS odjemalec. Ročno posredovanje se zahteva le takrat, ko spor nastane med popravljeno datoteko (novo nastalo spremembo) in še nenadzorovano/nespremenjeno lokalno različico datoteke. Če ''check in'' uspe, potem se številka verzije vseh spremenjenih datotek poveča. CVS-server pa v svoje log datoteke zraven nove številke verzije doda še opis, ki ga je podal uporabnik ter datum in ime avtorja, ki je spremembe ustvaril.
Odjemalci datotek lahko tudi primerjajo različice, zahtevajo popolno zgodovino sprememb ali si ogledajo posnetek zgodovinskega projekta na določen datum ali pa od izbrane številke revizije.
Terminologija: CVS dodeli oznako projektu (torej naboru povezanih datotek) in jih nato upravlja kot modul. Module, ki jih upravlja strežnik CVS shranjuje v svojem arhivu, programerji pa kopije modulov pridobijo s ''check outom''. ''Check out'' datotek služi kot delovna kopija, peskovnik (nadzorovano okolje za razvoj in preizkus programja) ali delovno okolje. Spremembe v delovni kopiji se bodo odražale v skladišču po tem, ko jih uporabnik potrdi (comit-a). Ostali uporabniki lahko posodobijo svojo delovno kopijo s pridobitvijo oziroma združitvijo (merge) teh sprememb iz repozitorija (strežnika).
35 Zgodovina: CVS se je razvil iz prejšnje različice sistema imenovanega Revision Control System (RCS) (še vedno v uporabi), ki zna upravljati s posameznimi datotekami, ne pa s celotnim projektom. Trenutna različica CVS se je začela z Brianom Berlinerjem aprila 1989.
Kasneje pa je k razvoju veliko prispeval Jeff Polk in mnogi drugi uporabniki. CVS je uvedel vejanje (branching) v sisteme za nadzor različic: tehnike vejanja v drugih sistemih izhajajo iz implementacije vejanja, ki se je razvil v CVS sistemu. Ker sistemi za nadzor različic izvorne kode niso vključevali koncept vejitve, so bili primerni le za posamezne datoteke.
CVS je od vedno trdno podpiral porazdeljenost in nepovezani (offline) način delovanja. To pa predvsem zaradi nezanesljivosti računalniških omrežij, ki so obstajala v času razvoja CVS-ja.
Najnovejša različica CVS-ja je izšla maja 2008, od takrat naprej pa je bilo le nekaj vzdrževalnih popravkov.
4.1.4 Git
Git je sistem za nadzor revizij, ki temelji na porazdeljenem modelu in ima glavni poudarek na hitrosti. Git je sprva zasnoval in razvil Linus Torvalds, ki ga je uporabljal za shranjevanje programske kode pri razvoju Linux jedra. Vsak Gitov delovni direktorij je celotno skladišče s popolno zgodovino in celotno zmogljivostjo za sledenje revizij in ni odvisen od dostopa do omrežja ali osrednjega strežnika. [19]
Linus Torvalds se je pošalil o imenu "git", saj to v žargonu britanske angleščine pomeni neumna ali neprijetna oseba.
Zgodovina: Razvoj Gita se je začel, ko so se številni razvijalci Linux jedra odločili, da se odrečejo dostopu do sistema BitKeeper. Torvalds je želel porazdeljeni sistem, ki bi ga lahko uporabiljal kot BitKeeper, vendar noben od razpoložljivih brezplačnih sistemov ni izpolnjenval njegovih potreb, še posebej pa ne njegove potrebe po hitrosti delovanja.
Torvalds je imel več kriterijev oblikovanja:
- Vzeti CVS kot primer, kaj ne storiti, in če ste v dvomih, potem sprejeti ravno nasprotno odločitev kot je ta v CVS-ju,
- podpora porazdeljenemu poteku dela,
36 - narediti zelo močne zaščitne ukrepe proti korupciji, bodisi naključni ali zlonamerni, - zelo visoka zmogljivost sistema.
Razvoj Gita se je začel 3. aprila 2005 pod močnim vplivom BitKeeperja. Torvalds se je namenoma poskušal izogniti konvencionalnim pristopov, kar je privedlo do edinstvene zasnove. Sistem je razvijal do te mere, da je bil uporaben za tehnične uporabnike, nato pa je vzdrževanje 26. julija 2005 prepustil Juniju Hamanu. Hamano je bil odgovoren za izhod različice 1,0 21. decembra 2005 in od takrat naprej še vedno ostaja vzdrževalec projekta.
Implementacija: Git ne uporablja centraliziranega strežnika. Razvil je celoten nabor funkcij, ki se pričakujejo od tradicionalnih sistemov za nadzor različic.
Git ima dve podatkovni strukturi: spremenljivo indeksno strukturo, ki v predpomnilnik shranjuje informacije o delovnem imeniku in naslednji reviziji ter nespremenljiva objektna podatkovna baza. Objektna podatkovna baza vsebuje štiri vrste objektov (blob (zbirka binarnih podatkov angl. Binary Large OBject, krat. BLOB), ki je vsebina datoteke, drevo, ki je ekvivalentno imeniku (direktoriju), potrditveni (comit) objekt, ki povezuje drevo objektov skupaj v zgodovino in označevalni objekt, ki je posoda, ki vsebuje sklicevanje na druge objekte in lahko vsebuje dodatne meta-podatke v zvezi z drugimi objekti). Indeks služi kot povezovalna točka med objektno podatkovno bazo in delovnih drevesom.
Prenosljivost: Git je bil razvit predvsem za Linux, lahko pa se uporablja tudi na drugih Unix operacijskih sistemih, vključno z BSD, Solaris in Darwin. Je izjemno hiter na sistemih, ki temeljijo na POSIX-u kot je na primer Linux. Git prav tako lahko deluje tudina Microsoft Windows sistemih.
4.1.5 Bazaar
Bazaar je sistem za nadzor revizij, ki temelji na porazdeljenem modelu. Sponzorira ga podjetje Canonical. Namenjen je temu, da bi bilo vsakomur lažje prispevati k brezplačnim in odprtokodnim projektom, ki se ukvarjajo z razvojem programske opreme. [18]
Razvojna ekipa je dala poudarek na enostavnosti uporabe, natančnosti in prilagodljivosti s posebnim poudarkom na vejanje (branching) in združevanje (merging). Bazaar lahko
37 uporablja en sam razvijalec, ki dela na več vejah lokalnih vsebin ali pa skupine razvijalcev, ki sodelujejo prek omrežja.
Bazaar je napisan v programskem jeziku Python s paketi združljivosti z nekaterimi distribucijami GNU/Linux sistemov, Mac OS X in MS Windows.
Bazaar ukazi so zelo podobni tistim v CVS. V nasprotju s povsem porazdeljenimi sistemi za nadzor različic, ki ne uporabljajo centralnega strežnika, Bazaar podpira delo z ali brez osrednjega strežnika. Možno je celo uporabaljati obe metodi hkrati pri istem projektu. Bazaar ima podporo za delo z nekaterimi drugimi sistemi za nadzor revizij. To omogoča uporabnikom, da naredijo novo vejo projekta iz drugega sistema (kot na primer iz Subversion sistema), naredijo lokalne spremembe in jih nato shranijo nazaj na Bazaar vejo. Bazaar omogoča tudi povezljivost s številnimi drugimi sistemi (vključno s CVS, Darcs, Git, Perforce, Mercurial).
Zgodovina: Februarja 2005 je razvijalec Martin Pool, ki je prej opisal in pregledal številne sisteme za nadzor revizij, v pogovorih in v svojem spletnem dnevniku objavil, da je bil najet s strani podjetja Canonical z nalogo, da ustvari/razvije porazdeljeno različico sistema za nadzor, katero bodo odprtokodni razvijalci radi uporabljali. Verzija Bazaar 1.0 je izšla decembra 2007, februarja 2008 pa je Bazaar postal projekt z licenco GNU.
4.1.6 SVN (Apache Subversion)
Apache Subversion (SVN) je brezplačna programska oprema za revizijo, ki je osnovana na odprtokodni licenci. Razvijalci ta sistem uporabljajo za ohranjanje sedanjih in zgodovinskih različic datotek kot na primer izvorne kode, spletne strani in dokumentacije. Cilj SVN-ja je biti najboljši naslednik CVS-ja, ki je trenutno najbolj pogosto uporabljen sistem za nadzor različic. [21]
Odprtokodna skupnost na veliko uporablja SVN. Ta je recimo uporabljen v projektih kot so:
Apache Software Foundation, Free Pascal, FreeBSD. Google Code in CodePlex prav tako uporabljata SVN za gostovanje svojih odprtokodnih projektov.
38 Zgodovina: SVN je ustvarilo podjetje CollabNet Inc v letu 2000. Njihov namen je bil ustvariti odprtokodni sistem za nadzor različic, ki bi deloval podobno kot CVS, vendar z odpravljenimi napakami in dodanimi novimi funkcionalnostmi, ki CVS-ju manjkajo. SVN je tako napredoval do te mere, da gosti svojo lastno izvorno kodo.
SVN ponuja dve vrsti repozitorijev: Berkeley DB in FSFS. Prvotno je SVN uporabljal Berkeley DB pakete, vendar ima uporaba le-teh določene težave v primeru, ko se program, ki dostopa do baze podatkov zruši ali nepričakovano konča. V tem primeru ne pride do izgube podatkov, vendar je repozitorij nedosegljiv vse dokler sam ne počisti vse odprte povezave in zaklenjene datoteke. Nedosegljivost repozitorija pa lahko uporabnikom povzroči težave in onemogoči nadaljne delo. Leta 2004 so razvijalci SVN-ja razvili nov podsistem za shranjevanje, ki so ga poimenovali FSFS. Ta deluje hitreje kot prej omenjeni Berkeley DB in za hranjenje datotek porabi manj prostora na disku. Začenši z SVN verzijo 1.2 je FSFS postal privzeti repozitorij za hranjenje podatkov. FSFS shranjuje svojo vsebino neposredno v datotečni sistem operacijskega sistema, ne pa v strukturiran sistem kot to počne Berkeley DB.
Od tod tudi ime "Datotečni sistem na vrhu datotečnega sistema" ("FileSystem atop the FileSystem").
Razvoj in implementacija: Podjetje CollabNet nadaljuje svoje sodelovanje s SVN-jem, vendar projekt poteka v okviru samostojne odprtokodne skupnosti. Novembra 2009 je bil projekt sprejet v Apache Incubator [22], s ciljem, da postane del Apache Software Foundationa. Od marca 2010 se projekt formalno imenuje Apache Subversion in je del Apache projektov.
Projekt SVN ne vključuje uradnega grafičnega uporabniškega vmesnika. Obstajajo pa številni grafični uporabniški vmesniki za delo s SVN-jem, razviti s strani različnih razvijalcev.
Razvijalci sistema SVN imajo običajno v aktivnem razvoju le eno ali dve novi funkcionalnosti, ki so nato vključene v novo verzijo sistema.
Najnovejša različica tega sistema (različica 1.7.5) je izšla 17. maja 2012.
39 4.2 Primerjava funkcionalnosti nekaterih sistemov za nadzor različic
Tabela 1: Splošni pregled sistemov za nadzor različic [12]
Prog.
oprema Vzdrževalec Razvoj Model repozitorija
Model
upravljanja Licenca Podprte
platforme Cena CVS CVS ekipa
vzdrževano, venadar ni
novih funkcionalnosti
odjemalec- strežnik
združevanje
datotek GPL
Unix-like, Windows, Mac OS X
Brezplačno
Git Junio
Hamano aktivni razvoj porazdeljen združevanje
datotek GPL
POSIX, Windows, Mac OS X
Brezplačno
Bazaar Canonical
Ltd. aktivni razvoj porazdeljen združevanje
datotek GPL
Unix-like, Windows, Mac OS X
Brezplačno
SVN
Apache Software Foundation
aktivni razvoj odjemalec- strežnik
združevanje ali zaklepanje
datotek
Apache/
BSDstyle
Unix-like, Windows, Mac OS X
Brezplačno
VSS Microsoft samo popravki kritičnih napak
skupna mapa
združevanje ali zaklepanje
datotek
Lastništvo Windows
500$ na licenco oziroma posamezna
licenca na vsako prijavo v
MSDN
TFS Microsoft aktivni razvoj odjemalec- strežnik
združevanje ali zaklepanje
datotek
Lastništvo
Server:
Windows Server
2003;
Clients:
Windows and Web included
Direkten nakup ozirma posamezna
licenca na vsako prijavo v
MSDN
Razlaga Tabele 1:
- Programska oprema: ime opisane aplikacije.
- Vzdrževalec/razvijalec: podjetje oziroma skupina, ki je trenutno zadolžena za razvijanje ali vzdrževanje programske opreme.
- Status razvoja: pove nam trenutni status razvoja opisanega sistema za nadzor različic (torej, če se sistem še razvija ali je njegov razvoj že končan).
- Model repozitorija: opisuje odnos med različnimi kopijami izvorne kode, ki se nahajajo v repozitoriju. Pri modelu odjemalec-strežnik uporabniki dostopajo do centralnega skladišča preko odjemalca. Njihovi lokalni stroji (računalniki) imajo le dolovno kopijo izvorne kode. Če hočemo, da so spremembe vidne tudi drugim uporabnikom, moramo le-to oddati v centralni repozitorij. Pri porazdeljen modelu pa se skladišča obnašajo kot omrežni vrstniki (peers). Tako imajo uporabniki poleg
40 lokalne kopije izvorne kode, tudi lokalni repozitorij z vso zgodovino sprememb različic.
- Model upravljanja: opisuje, kako se upravljajo spremembe delovne kopije izvorne kode, da bi se preprečilo sočasno spreminjanje iste datoteke, kar bi lahko povzročilo nesmiselnost podatkov v skladišču. Pri modelu, ki uporablja zaklepanje datotek spremembe niso dovoljene, vse dokler uporabnik ne zahteva in pridobi pravice spreminjanja datoteke s strani centralnega skladišča. Pri modelu, ki pa uporablja združevanje pa lahko uporabniki prosto urejajo datoteke, vendar so pred oddajanjem sprememb v skladišče obveščeni o možnih konfliktih, ki so nastali s spremembami.
Sistem za nadzor različic lahko nato poskuša združiti spremembe ali pa v primeru konfliktov prepusti uporabniku odločitev, kaj bo storil. Porazdeljeni sistemi za nadzor različic skoraj vedno uporabljajo model združevanja datotek.
- Licenca: licenca, pod katero je opisan sistem za nadzor različic izdan.
- Podprte platforme: operacijski sistemi, ki jih sistem podpira in na katerih lahko deluje.
- Cena: cena lastništva programske opreme.
Tabela 2: Tehnične informacije opisanih sistemov za nadzor različic [12]
Prog. oprema Programski jezik Id različice Velikost izvorne kode
CVS C številka 3.3 MB
Git C, shell scripts, Perl SHA-1 vrednost 10.2 MB
Bazaar Python, Pyrex, C
številka, vendar se ustvari glede na obsežnost
sprememb (vedno je višja od predhodne številke)
4.1 MB
SVN C številka 5.2 MB
VSS C številka Neznana (ni podano)
TFS C++ in C# številka Neznana (ni podano)
Razlaga tabele 2:
- Programska oprema: ime opisane aplikacije.
- Programski jezik: jezik, v kateri se programska oprema razvija
- Id različice: uporabljajo se interno v sistemih za nadzor različic za indentifikacijo verzije datotek v skladišču. Sistemi za identifikacijo datotek lahko uporabljajo številke, kodirane vrednosti, ime datoteke vključno z neko zaporedno številko, ipd.
Različice v veliki večini primerov predstavljajo neko množico sprememb v datotekah, ne pa spremembo ene same datoteke.
- Velikost izvorne kode: v mega bajtih napisana velikost izvorne kode danega sistema.
