Navn: E-NN

Fødselsdato: xx-xx-98

Skole: EUC Nordvestsjælland

Fag: Stud.pro, Større skr. opg (4937--)

Dato for prøveaflæggelse: 21-12-2016 Titelblad til SRP opgaveformulering

Elev: E-NN Klasse: 3.? Vejleder Studieretningsfag Teknologi A Georg Strøm på A-niveau: Andet fag og ITK B Erik Lund niveau:

Opgaveformulering Titel: Open Source softwareudvikling - central og decentral versionskontrol

Der ønskes en undersøgelse af fordele og ulemper, når udviklingen af software går fra centraliseret til decentraliseret versionsstyring.

Når softwareudvikling går ”Open Source” skaber det nogle udfordringer med hensyn til at styre udviklingsprocessen og især styringen af, hvilke versioner der er aktuelle, hvilke der ikke er og hvilke, der afhænger af ændringer andre steder i softwaren. Disse problemer er ikke de samme, når udviklingen foregår inden for en traditionel, hierarkisk organiseret virksomhed, hvor styringen kan være mere centraliseret.

Der skal laves en IT baseret teknisk gennemgang af de principper for source management, der anvendes i de analyserede systemer til versionskontrol, herunder en analyse af de fejl der kan opstå i forbindelse med revisionskontrol, risikoen for dem og håndteringen af dem ved central og decentral versionskontrol i de analyserede systemer.

Der skal laves en teknologianalyse, som sammenligner mindst et system til central versionskontrol med mindst et system til decentral versionskontrol. Analysen skal omfatte en beskrivelse af ligheder og forskelle i produktet eller resultatet af de to typer af revisionskontrol.

Til slut skal det diskuteres og konkluderes, på hvilke måder overgangen fra centraliseret til decentraliseret revisionskontrol kan øge eller mindske hastigheden og antallet af fejl ved udvikling af software, og hvilken perspektiver det kan have for Open Source softwareudvikling.

Det centrale system til versionskontrol og det decentrale system Hub kan bruges som case eller eksempler til belysning af problemformuleringen.

Forventet omfang Omfang svarende til 10-16 A4 sider (2.400 anslag pr. side) ekskl. forside, indholdsfortegnelse, fodnoter, litteraturfortegnelse og bilag samt eventuelle tabeller eller illustrationer, uanset om disse er placeret i selve teksten. Evt. fordybelsesfag Evt. note til bedømmere Opgavebesvarelsen afleveres senest d. 21. december kl. 10.00 i "Netprøver.dk". Opgaveformuleringen (hele denne side) indsættes forrest i besvarelsen. Elias Z. Jørgensen 3z SRP – Teknologi A og ITK B 21/12 - 2016

Open Source Softwareudvikling Slotshaven Gymnasium Teknologi A: Georg Strøm Central og Decentral Versionskontrol ITK B: Erik Lund

Anslag: 31201

E-NN 21/12 – 2016 kl. 10:00 SRP – Teknologi A og ITK2/14 B Kommentarer til opgavebeskrivelsen I opgaveformuleringen står der at “… det decentrale system Git Hub kan bruges…”, hvilket er ukorrekt. ”Git Hub”, eller ”GitHub” som det staves korrekt, er en platform til at opbevare, dele og administrere kildekoden til software projekter. ”Git” derimod, er det decentrale versionskontrolsystem, som er hvad min vejleder må have ment. Abstract This report examines the use of centralised and decentralised models used in the software industry and Open Source software development. It will explain why version control is being used, how it works, and how the two models differentiate, using the popular Subversion and Git version control systems as an example.

This will be followed by an explanation and analysis of common Source Management principles used in software development, and how they solve common problems.

Thereafter it showcases a comparative technology analysis of the two version control models, again using Subversion and Git as examples, which will determine the strengths and weaknesses of each model.

Lastly it will discuss and conclude, how the transition from a central to a decentral version control model can impact the speed and amount of errors in software development, along with a view of the two models seen from the Open Source perspective, using Linux as an example. Indholdsfortegnelse 1. Afgrænsning ...... 1 2. Indledning ...... 1 3. Redegørelse af versionskontrolsystemer ...... 1 3.1 Centraliseret versionskontrol - Apache Subversion ...... 3 3.2 Decentraliseret versionskontrol - Git ...... 4 4. Source Management ...... 5 4.1 Atomiske Operationer ...... 5 4.2 Fil låsning ...... 5 4.3 Version Merging ...... 5 4.4 Tags ...... 6 4.5 Mulige fejl og håndtering deraf ...... 6 5. Teknologianalyse af versionskontrolsystemer ...... 7 5.1 Apache Subversion ...... 7 5.1.1 Viden ...... 7 5.1.2 Organisation ...... 7 5.1.3 Teknik...... 8 5.1.4 Produkt ...... 8 5.2 Git ...... 9 5.2.1 Viden ...... 9 5.2.2 Organisation ...... 9 5.2.3 Teknik...... 9 5.2.4 Produkt ...... 10 5.3 Centraliseret kontra Decentraliseret versionskontrol ...... 10 6. Overgangen fra Centraliseret til Decentraliseret ...... 11 7. Konklusion ...... 12 8. Litteraturliste ...... 13 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

1. Afgrænsning Jeg vil i denne rapport fokusere på versionskontrolsystemer der bruges til at administrere softwareprojekter, og ikke andre typer af versionskontrol der f.eks. bruges til at holde styr på forskellige versioner af dokumenter, rapporter, billeder, osv.

Jeg vil fokusere på de to mest brugte versionskontrolsystemer Subversion (Apache, 2016) og Git (Git, 2016), i min redegørelse og analyse. Dette har jeg valgt eftersom at det er dem der bedst afspejler brugen af versionskontrol i softwareindustrien, og samtidig repræsenterer både de centrale og de decentrale versionskontrolsystemer.

Da målet med denne rapport er, at være forståelig for både tekniske og mindre tekniske personer, vil jeg ikke gå i dybden med de mere avancerede dele af versionskontrolsystemer, såsom ’rebasing’, da det ville gøre mere skade end gavn, og samtidig ikke er behøvet viden, for at kunne sammenligne de to forskellige typer af arkitekture.

2. Indledning Når en gruppe af mennesker har brug for at udvikle på samme softwareprojekt, så er der nogle forskellige måder at gøre det på.

Én måde man kunne gøre det på ville være, at alle udviklere skiftedes til at redigere i projektet. Det fører dog til, at alle skal vente til at det bliver deres tur, hvilket spilder en masse dyr udvikler tid.

En anden måde at gøre det på er, at alle har en kopi af projektet, og indbyrdes blev enige om hvilke filer, man hver især måtte redigere i. Det skaber dog problemer, når de skal til manuelt at stykke al koden sammen igen, og senere når de begynder at have forskellige versioner af projektet, og måske ikke kan blive enige om, hvem det er, der har den nyeste version.

En bedre løsning kunne derfor være at bruge et versionskontrolsystem. Det sparer udviklerne for en masse unødvendige frustrationer og øger effektiviteten, da det gør det muligt for alle udviklerne at redigere i projektet på samme tid, og slippe for at have forskelige mapper liggende med forskellige versioner af projektet. Versionskontrol gør det derudover muligt for udviklerne at have forskellige versioner af et projekt uden obskure mappestrukturer, der øger chancen for fejlhåndtering (Git-Tower, 2016).

I denne rapport vil jeg diskutere hvordan overgangen fra centraliseret til decentraliseret versionskontrol har påvirket effektiviteten for softwareudvikling, i lukket såvel som Open Source software. Der vil derudover indgå en komparativ teknologianalyse af de to versionskontrolsystemer Subversion og Git samt en teknisk gennemgang med udgangspunkt i analysen.

3. Redegørelse af versionskontrolsystemer Det underliggende mål med versionskontrolsystemer er, at tillade udviklerhold at have en komplet historie af alle ændringer, der er blevet foretaget, og på samme tid gøre det muligt at arbejde på forskellige versioner samtidig og uafhængig af hinanden.

1/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

Det opnår versionskontrolsystemer ved at opbevare projektet i en grafstruktur (Wikipedia, 2016).

Grafen er opbygget som et omvendt træ med sammensættelige grene. Til højre ses et eksempel. I midten af træet har vi stammen, markeret med grøn, som er standard grenen i versionskontrolsystemer. Man kalder den stammen, fordi det er den del af grafen, man oftest forgrener ud fra.

Hver gang en udvikler har lavet et sæt ændringer, laver personen et ”” (markeret med gul), som er en samling af ændringer, ved hjælp af versionskontrolsystemet. Derfor indeholder et commit kun de ændringer som udvikleren har lavet og ikke alle de forskellige filer i projektet. Alle commits får en unik identifikator, ofte i form af en såkaldt ”hash” af commitet. En hash er en funktion, der transformerer en mængde data om til et unikt hexadecimal tal, der repræsenterer al indholdet i dataen (Wikipedia, 2016). I eksemplet til højre bruges der dog små hele tal, for at hjælpe med forståelsen af strukturen. Når en udvikler har lavet et commit, indsætter versionskontrolsystemet det som en node i grafen.

Grene laves for at undgå konflikter, som der opstår hvis flere forskellige udviklere har lavet ændringer det samme sted i kodebasen. De laves også Figur 1 - Eksempel på en historie- for at tillade udviklere at arbejde på nye features, bugfixes (rettelse af graf af et projekt, der gør brug af fejl), eller andet, der er/skal være isoleret fra resten af versionskontrol (Wikipedia, 2016). projektudviklingen, så de ikke skal tænke på hvordan de andre udvikleres ændringer påvirker deres egne. Når man er færdig med sin gren, kan man ”” med en anden gren eller stammen, for at forene ens gren med den anden gren.

Et eksempel på dette ses også til højre, hvor at commit nr. 2 er forgrenet ud fra commit nr. 1, commit nr. 3 forlænger grenen som commit nr. 2 dannede og commit nr. 4 indeholder alle ændringerne fra grenen, som commit nr. 2 startede.

Når udviklerholdet så er færdig med alt, der skal laves til en ny version af deres projekt, kan de lave et ”tag”, kendt i dagligdags tale som en udgivelse. Et tag opfører sig lidt som en gren, med den undtagelse at den aldrig ændrer sig. Man kan se på det som at være en mærkat, der fortæller hvilken version man er nået til, på det givne sted i projektets historik.

Ved at versionskontrolsystemet holder styr på ændringer i projektet på denne måde, gør den det muligt at spole tilbage i projektets historie, hvis en udvikler får lavet et forkert commit, eller hvis udviklergruppen bliver enige om at de er gået i den forkerte retning med projektet.

For at det er muligt for et udviklerhold at arbejde på deres projekt samtidig ved hjælp af et versionkontrolsystem, er der dog brug for en måde for udviklerne at dele deres ændringer med resten af holdet. Derfor gik man fra at bruge lokal versionskontrol, hvor at versionkontrolsystemet opbevarede al

2/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016 dataen på den individuelle udviklers system, til at bruge netværksopkoblede versionskontrolsystemer. Iblandt disse er Subversion og Git. 3.1 Centraliseret versionskontrol - Apache Subversion Subversion blev udgivet i 2004, som en efterfølger til det populære centraliserede versionskontrolsystem CVS (Wikipedia, 2016). Subversion blev udviklet for at rette de fejl som CVS havde, og for at tilføje nogle at de funktioner som det manglede. I november 2009 tog Apache projektet under deres vinger, hvor fra det er blevet videreudviklet og vedligeholdt lige siden.

Med centraliseret versionskontrol har man en enkelt server, der indeholder versionskontrolsystemet, samt alle ændringer, grene ol. som udviklerne laver. Dertil har hver udvikler et program på deres system, en versionskontrol klient, der kan kommunikere med serveren (Git, 2016). Her kan udviklerne igennem deres klient hente den nuværende version af projektet, på den givne gren.

Når de så skal lave et commit, bruger de deres klient til at sende det til serveren, som tilføjer det til historie-grafen. Herefter kan en anden udvikler bruge sin klient til at synkronisere med serveren, for at få de nyeste ændringer ned på hans eget system, så han kan arbejde videre med dem der. Centraliserede versionskontrolsystemer, som Subversion, bliver ofte brugt i større softwarefirmaer, der typisk følger en lidt mere lineær udviklingsproces.

Til højre ses et eksempel på dette, hvor både Computer A og Computer B kan hente de samme filer fra en fælles versionskontrol server.

Denne struktur har en masse fordele. Blandt andet giver den et overblik over, hvad udviklerne hver især Figur 2 - Eksempel på strukturen i et centraliseret arbejder på, hvilket gør det nemt for versionskontrolsystem. administratorerne at have fin kontrol med projektet. Derudover er det langt nemmere at administrere et centraliseret versionskontrolsystem end at administrere lokale versionskontrolsystemer på alle udviklernes systemer (Git, 2016).

Der er dog også visse ulemper, såsom at man med et centraliseret versionskontrolsystem har ét enkelt punkt, hvor, hvis der er noget galt, så er hele udviklerholdet ude af stand til at arbejde, før problemet er løst. Hvis serveren er nede i en time, er udviklerne ikke i stand til at gemme ændringer hele den time, og hvis harddisken, der ligger på serveren, bliver korrupt eller går ned, og man ikke har et ordentligt backup system sat på plads, så mister man al den data som serveren indeholdte (Git, 2016). Der er også den ulempe at man typisk har en administrator ansat til at administrere ens versionskontrolserver, da det ikke er muligt for udviklerne at udrede potentielle problemer, f.eks. ved at sende ændringer, fra deres eget system. Et andet typisk problem er hastigheden, da udviklerens system skal vente på at serveren bliver færdig med hvad den laver, før den kan sende et commit afsted.

3/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

3.2 Decentraliseret versionskontrol - Git Git blev udgivet i år 2005 og blev udviklet af Linux Torvalds (Wikipedia, 2016), til brug under videreudviklingen af Linux (Wikipedia, 2016). Git blev udviklet, da BitKeeper (Wikipedia, 2016), versionskontrolsystemet der førhen blev brugt til videreudviklingen af Linux, stoppede med at tilbyde en gratis licens til ikke-kommerciel brug, hvilket resulterede i at mange af de frivillige udviklere måtte stoppe med at bidrage til projektet.

Med den decentraliserede versionskontrol model som Git bruger, har man ofte en server, der indeholder al versionskontrol dataen fra ens projekt – dette er dog ikke påkrævet. Forskellen på Subversion er dog her, at udviklerne, i stedet for at hente de filer som Subversion laver ud fra historie- grafen, henter al versionskontrol dataen ned på deres eget system (Git, 2016).

Dette har nogle umiddelbare fordele ved, at hvis serveren dør, så har alle udviklerne en komplet kopi af hele projektets historik, som de kan bruge til at sætte en ny server op. Det er derudover markant hurtigere at lave et commit, da det bliver lavet direkte på udviklerens system, og ikke skal sendes til den centrale server. I stedet kan udvikleren lave en serie af commits, og sende dem til serveren på én gang, når han er færdig.

En anden fordel er, at udviklerne ikke kun kan sende commits til den centrale server, men også til hinanden. Dette tillader udviklerholdet at opsætte udviklings workflows, som ikke er mulige med centraliserede versionskontrolsystemer (Git, 2016). Et berømt eksempel på en sådanne type af workflow er ’Dictator and Lieutenants’ modellen, som bliver brugt til videreudviklingen af Linux (Git, 2016).

Denne fleksibilitet har resulteret i at Git er blevet et utroligt populært værktøj, især i Open Source verdenen. En undersøgelse fra 2015, udført af Stack Overflow, har vist at 69% af softwareudviklere bruger Git (Stack Overflow, 2015).

Figur 3 - Eksempel på strukturen i et decentraliseret versionskontrolsystem.

4/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

4. Source Management For at sikre sig at udviklingen af et stykke software forløber med en minimal mængde af problemer, har man igennem tiden udviklet en serie af principper og teknikker, der kan hjælpe et udviklerhold med at opnå dette (Wikipedia, 2016). 4.1 Atomiske Operationer Atomiske operationer er en velkendt teknik der bliver gjort brug af alle steder i softwareindustrien, for at sikre sig at et givent projekts historik er klar, kortfattet, og overskuelig. Teknikken går ud på at alle udviklere skal bygge deres ændringer op omkring atomiske ændringer.

En atomisk ændring er en ændring, der kun drejer sig omkring én enkelt opgave, som at rette en fejl i koden, eller lave en ændring i et layout på en brugergrænseflade. Man kalder disse ændringer atomiske, da det ikke er muligt at splitte ændringen ud i flere forskellige ændringer, da ændringen kun berør en enkelt del af systemet (Wikipedia, 2016).

Dette tillader udviklere at gå tilbage i projektets historik uden at påvirke andre ændringer, samtidig med at det gør det lettere at merge funktioner, og andre ændringer, med andre grene. 4.2 Fil låsning Fil låsning er en funktion der oftest findes i centraliserede versionskontrolsystemer som Subversion, hvor at forgrening er mindre normalt. Fil låsning bliver brugt til at begrænse adgangen til at ændre i en given fil, til én udvikler ad gangen (Wikipedia, 2016).

Grunden til at dette bliver gjort, er for at sikre sig at det ikke er muligt, at én udvikler gemmer en ændring i en fil, som en anden udvikler senere overskrider. Dette gøres muligt, ved at versionskontrolsystemet går ned på et filsystem niveau og markerer filerne som ’read-only’.

Hvis en udvikler ønsker at lave en ændring i en fil, bliver den givne udvikler nødt til at udføre en ’unlock’ operation. Indtil at udvikleren er færdig med sine ændringer, eller beslutter at han ikke vil lave en ændring i filen alligevel og gør filen tilgængelig igen, er det ikke muligt for de andre udviklere at lave ændringer i filen.

4.3 Version Merging ’Version merging’ er en teknik, der er indbygget i de fleste moderne versionskontrolsystemer. Som navnet fortæller går teknikken ud på, at udføre en ’merge’ operation på forskellige versioner, af en given fil (Wikipedia, 2016). Teknikken eksisterer for at tillade udviklere at samle flere forskellige versioner af en fil, til en fil der indeholder ændringerne fra de givne versioner.

Hvis en udvikler laver ændringer i en fil og sender dem til den centrale server, eller en anden udvikler, som i den samme fil har ændringer, som udvikleren ikke havde, vil der være et problem med modstridende versioner af filen. Her kan udvikleren igennem versionskontrolsystemet udføre et ’merge’ af de modstridende filer, for at samle dem.

5/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

Der vil dog opstå det man kalder ”konflikter”, hvis de forskellige versioner har introduceret ændringer de samme steder i koden. Her er det udviklerens opgave at bestemme hvilke ændringer der skal være i den endelige version af filen, for at sikre at softwaren virker efter hensigten.

4.4 Tags I løbet af (videre)udviklingsforløbet af et stykke software, er det meget normalt at have et behov for at udgive nye versioner, til f.eks. retning af fejl eller nye funktioner. Til dette har de fleste moderne versionskontrolsystemer en ’tag’ funktion, der tillader udviklere at markere en specifik version af projektet (Wikipedia, 2016). Denne funktion findes også under andre navne, heriblandt ’baseline’ og ’label’.

Dette opnår udvikleren, ved at udføre tag operationen, og fortælle versionskontrolsystemet hvilket commit, det skal sætte ”tagget” fast på. Ved at gøre det på denne måde, ved versionskontrolsystemet at det givne ’tag’ er resultatet af det givne commit, samt alle foregående commits.

Efter at denne operation er udført, er det muligt at eksportere denne version fra versionskontrolsystemet, som man derefter kan distribuere til sine brugere. 4.5 Mulige fejl og håndtering deraf Som med alle andre avancerede værktøjer, er der et utal af ting der kan gå galt, hvis ikke man passer på. Og som med alle andre avancerede værktøjer, er størstedelen af disse menneskelige fejl, der opstår når brugeren ikke er tilstrækkeligt uddannet i brugen af værktøjet.

Man skulle tro at centraliserede versionskontrolsystemer som Subversion var den største synder her, da alt hvad udviklerne gør gennem deres klient, har en effekt på den centrale server. Men, da Subversion er bygget op omkring ideen af udviklere og administratorer, er der ikke meget en udvikler kan gøre, som administratoren ikke kan lave om. Dette sikkerhedsnet findes dog ikke for administratoren, hvor det er forventet at man ved præcis hvad ens aktioner har, af konsekvenser.

Et eksempel på dette kunne være, hvis en udvikler har set sig sur på deres chef, og beslutter sig for at lave et commit, hvor at personen sletter alle filerne i kodebasen. Da alle commits bliver opbevaret i en historie graf, kan administratoren fikse problemet, ved at spole tilbage på historie grafen, til før udviklerens commit blev lavet. Vælger administratoren at lave om på historikken, og sletter commitet i stedet, kan en del af projektets historik gå tabt, hvis administratoren ved et uheld kommer til at slette mere end det enkelte commit.

Her er Gits decentraliserede model dog farligere, da det spreder ansvaret ud kollektivt blandt udviklerne, hvilket betyder at alle har mulighed for at skrive historien om, hvis de ønsker det. Den decentraliserede model løser dog selv samme problem, da alle udviklerne har en komplet lokal kopi af historien, hvilket betyder at hvis én udvikler får omskrevet historien i projektet, kan en anden udvikler rette det, relativt smertefrit.

Som nævnt tidligere, opstår størstedelen af disse problemer dog oftest, på grund af manglende viden. Derfor er det selvfølgelig i alles interesse, hvis nye udviklere sætter sig godt ind i brugen af systemet, før de begynder at have med den rigtige kodebase at gøre.

6/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

5. Teknologianalyse af versionskontrolsystemer I denne analyse vil jeg anvende puslespilsmodellen, da det er den bedst passende model, fra Teknologi A faget. 5.1 Apache Subversion Viden Organisation Viden omkring brug af Subversion Administrator(er) Viden omkring administration af Subversion Udviklere IT-folk Teknik Produkt Server software (Subversion) Centraliseret struktur Klient software Lineære udviklingsworkflow Server maskine ’Single point of failure’ Backup system For ufleksibelt til store Open Source projekter

Jeg vil tage udgangspunkt i et softwarefirma, da brugen af Subversion i Open Source verdenen er minimal.

5.1.1 Viden For at være i stand til at bruge Subversion er der et behov for, at alle ens udviklere er i stand til at udnytte systemet. Dette kan betyde, at hvis man har udviklere der ikke har erfaring med Subversion, bliver de nødt til at blive uddannet i det. Hertil har fællesskabet omkring Subversion kreeret en bog, som blandt andet har en gratis e-bog version, til at uddanne nykommere såvel som erfarne brugere, omkring alle Subversions funktioner, samt brug af dem (Pilato, Collins-Sussman, & Fitzpatrick, Version Control with Subversion: Next Generation Open Source Version Control, 2008).

Det er dog ikke kun udviklerne, der har behov for en hvis viden, firmaets Subversion administrator bliver nødt til at være en ekspert i de værktøjer som Subversion stiller til rådighed, for at sikre at firmaets software forbliver i god stand, og for at hjælpe udviklere med at udrede de problemer, der kan opstå i løbet af et udviklingsforløb (Pilato, Collins-Sussman, & Fitzpatrick, Repository Maintenance, 2008).

5.1.2 Organisation Ved at bruge Subversion på en større skala er det en præmisse for firmaet at ansætte mindst en administrator til at administrere Subversion systemet. Der er derudover brug for en IT-afdeling, hvis firmaet ønsker at have Subversion serveren internt i firmaet. De fleste større softwarefirmaer har dog en IT-afdeling i forvejen, så det er ikke sikkert, at dette er en ekstra udgift.

Der findes dog også firmaer der tilbyder infrastruktur til Subversion, hvis man ikke ønsker at investere i den nødvendige hardware. En af de store distributører er Assembla, som adskillige softwaregiganter gør brug af (Assembla, 2016). Hvad der giver mest mening, intern eller ekstern infrastruktur, afhænger af det individuelle firmas krav til sikkerhed, tilpasning og service.

Til sidst er der brug for udviklere med kompetencer indenfor Subversion, for at kunne gøre brug af versionskontrolsystemet i udviklingsprocessen.

7/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

5.1.3 Teknik For at indføre Subversion i et firma, er der nogle essentielle ting som man bliver nødt til at indføre, på managementsiden, såvel som udviklersiden.

Som der blev nævnt tidligere, er det muligt at leje serverplads, hvorpå at Subversion er præ-installeret, hos blandt andet Assembla. Hvis man ønsker at have en intern løsning, er det muligt at hente Subversion fra Apaches hjemmeside, som man kan installere direkte på en server (Apache, 2016).

Administrerings værktøjer er indbygget i Subversion installationen i form af en serie af kommando værktøjer, ønskes der dog en løsning med en grafisk brugerflade findes der adskillige løsninger, lavet af fællesskabet omkring Subversion, samt kommercielle løsninger.

Et aktivt backup system er yderst vigtigt, for at sikre sig at man ikke mister data fra Subversion. Grundet Subversions centraliserede natur er dette essentielt, da det er muligt at miste historikken fra alle de projekter der ligger i systemet, i tilfælde af harddisk korruption eller at serveren dør. Bruger man en ekstern service som Assembla, er dette allerede gjort for en.

Uden en Subversion klient er det ikke muligt for udviklerne at interagere med Subversion serveren. Subversion klienter findes i mange former både kommando baserede og med grafiske brugerflader, gratis og kommercielle. Der er ikke et rigtigt svar på, hvad man skal bruge. Det er op til den individuelle virksomhed at tage en beslutning i samarbejde med deres udviklere.

5.1.4 Produkt Subversion bruges bredt i softwarefirmaer, der gør brug af et centraliseret versionskontrol workflow. Det gør brug af en striks centraliseret model, hvilket har den fordel, at alt kan findes ét sted. Det har dog også nogle store ulemper, da det ikke er muligt for udviklerne at hente/sende commits, medmindre de er koblet på internettet, og at Subversion serveren kører uden problemer. Her er det som udgangspunkt vitalt for firmaet at tage regelmæssige backups for at sikre, at de ikke mister værdifuld software historik.

Subversion passer bedst ind i virksomheder med lineære udviklingsprocesser i form af f.eks. vandfaldsmodellen (Wikipedia, 2016), grundet dens ufleksible natur, der spænder ben for eksperimentering og udvikling i regioner med suboptimal internetopkobling. Af denne grund bliver Subversion sjældent brugt til Open Source projekter, da de kræver langt større fleksibilitet og skalerbarhed, da det som Figur 4 - Vandfalds modellen (Wikipedia, 2016) udgangspunkt skal være muligt for alle at foreslå ændringer i projektets kildekode, uden at lave ændringer direkte i projektets historie (Samsung Open Source Group, 2016).

8/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

5.2 Git Viden Organisation Viden omkring brug af Git Udviklere Valgfri IT folk Teknik Produkt Versionskontrol software (Git) Fleksibel Decentraliseret/Distribueret struktur Valgfri Server maskine Bred mulighed for udviklingsworkflow Valgfrit Backup system Hastighed

Jeg vil tage udgangspunkt i et generelt udviklerhold, da brugen af Git er populær i softwarefirmaer, såvel som Open Source verdenen.

5.2.1 Viden For at et udviklerhold kan tage Git i brug, har de brug for uddanne sig i brugen af det, hvis ikke de har tidligere erfaring med det. Git har en officiel bog, der er gratis tilgængeligt på deres hjemmeside, som alle kan læse for at få en forståelse omkring brugen af Git og dets mange muligheder (Chacon & Straub, 2014). Git er dog det mest populære versionskontrolsystem i softwareindustrien, hvilket resultere i at det er hvad de fleste udviklere lærer at bruge, på deres første udviklerjob.

5.2.2 Organisation Grundet Gits decentraliserede natur er der ikke behov for administratorer til Git servere, da al dataen afspejles på alle udviklernes maskiner, hvilket gør det til et fælles ansvar blandt udviklerne at have orden i projektets historik. I tilfælde af Open Source projekter, der gør brug af Git, vil man typisk have brug for et sted at opbevare sin kode. Det er for at give nye udviklere et bedre overblik og for at fremvise sit projekt til omverdenen, dertil fungerer det som en backup.

Til det formål er der services som GitHub, der både giver udviklere mulighed for at skabe et ’image’ i Open Source verdenen, og samtidig tillader det virksomheder at opbevare deres kode et sikkert sted, kun tilgængeligt for ansatte (GitHub, 2016). GitHub tilbyder derudover en business løsning, der lader firmaer have en version af GitHub kørende på egne servere.

I tilfælde af at en løsning som GitHub køres på egne servere, er der typisk behov for en systemadministrator til at vedligeholde serverne GitHub kører på. Dette skal dog ikke forveksles med vedligeholdelse af GitHub som produkt, da det vedligeholdes af firmaet af samme navn.

5.2.3 Teknik Det eneste, der skal bruges for at komme i gang med Git, er Git i sig selv. Da Git er decentraliseret, kan det bruges på en server på samme måde, som det kan bruges lokalt på en udviklers computer. Dette tillader udviklere at dele deres lokale projekthistorik direkte med andre udviklere, uden at være tvunget til at bruge en central server.

Grundet Gits store fleksibilitet er det også muligt at have en server, der kan bruges til at have en autoritær version af projektets historik, samtidig med at virke som et fælles adgangspunkt for projektet.

9/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

Et backup system er valgfrit, dog altid en god ide, når man bruger Git. Grunden til dette er, at alle udviklere på et projekt har en fuldstændig kopi af dataen, hvilket gør det muligt at hente dataen fra en anden udvikler i tilfælde af at man mister sig egen kopi.

5.2.4 Produkt Grundet Gits store fleksibilitet passer det perfekt til Open Source verdenen. Med Git er det muligt for udviklere at udføre operationer gennem versionskontrolsystemet på trods af mangel på internetforbindelse, og helt uden en central server, hvis man ikke har brug for det.

Git brillerer især på sin hastighed, som det opnår ved at have en lokal kopi af al dataen, hvilket medfører at det slipper for at sende ændringer over netværket for at lave ændringer i historikken, som er utroligt tidskrævende for systemet. Gits hastighed er essentiel for blandt andet Linux, hvor en rapport fra 2012 viser, at Linux i gennemsnit har fået tilføjet 3509 linjer kode om dagen, i løbet af projektets levetid (Pingdom, 2012).

Git passer ind i de fleste projekter, Open Source såvel som lukkede, som resultat af dets fleksible struktur. Git er lige så komplekst som man har brug for, hvilket betyder at man kan opnå et workflow med det, som passer perfekt ind i ens udviklingsproces.

Et godt eksempel på dette er den førnævnte ’Dictator and Lieutenants’ model, som folkene bag Linux udnytter, hvilket gjorde det muligt, at der i 2013 var omkring 10.000 Figur 5 – ‘Dictator and Lieutenants’ modellen. forskellige individer, der hjalp til med at videreudvikle Linux (The Linux Foundation, 2013).

Dog er det stadig muligt at bruge en centraliseret struktur, hvis det bedre passer til ens behov.

5.3 Centraliseret kontra Decentraliseret versionskontrol Gits decentraliserede model gør det langt mere fleksibelt end Subversions strikte centraliserede model, hvilket har den betydning for en udviklergruppe at de kan tilpasse det til, hvordan de arbejder bedst. Derudover opbevarer Git en kopi af al dataen, hvilket gør det muligt for Git at være langt hurtigere end Subversion, som har kæmpe betydning for hold der arbejder med store kodebaser. Samtidig med dette, er det muligt at arbejde uden internetadgang, hvilket Subversion ellers kræver.

Da Git overdrager alt ansvar til udviklerne, er der her ikke et behov for at have en administrator. Det er derudover heller ikke et krav at opbevare dataen på en server, da Git gør det muligt at dele dataen direkte mellem udviklerne. Det vil sige, at Git kan spare et firma/udviklerhold for en ekstra person, samt server infrastruktur, hvilket hurtigt kan spare dem en masse penge.

10/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

Alt dette gør, at Git er langt mere attraktivt for store Open Source projekter, der kræver fleksibilitet og hastighed, samt lave omkostninger. Den decentrale model gør dog Git mere kompliceret end Subversion, hvilket kan føre til menneskefejl hos især nye udviklere. Dette gør Gits fleksibilitet dog delvist op med, da det også er muligt at sætte en centraliseret workflow op, hvilket gør det nemmere for nye udviklere, samtidig med at virke bekendt for tidligere Subversion brugere.

Alt dette viser at Git har langt flere fordele end Subversion, som kun er mere attraktivt på sin simplicitet. Git kan bruges i samme scenarier som Subversion tidligere er blevet brugt, dog med en højere hastighed og mulighed for at arbejde offline, samtidig med at være utrolig attraktiv for Open Source verdenen, der her behov for alternative workflows.

Dette bekræfter Google Trends, der viser at interessen i Git har været højere end Subversion siden oktober 2011, og har vokset i takt med at interessen i Subversion har faldet (Google, 2016).

6. Overgangen fra Centraliseret til Decentraliseret Når man går fra at bruge en centraliseret versionskontrolmodel til at bruge en decentral, er der adskillige faktorer der kan spille ind, for at bestemme hvordan udviklingshastigheden, kodens kvalitet og mængden af fejl bliver påvirket. En undersøgelse fra Oregon State University fra 2014 viste, at udviklere der gjorde brug af et decentralt versionssystem i gennemsnit producerede commits med ¾ af størrelsen af commits produceret af udviklere der gjorde brug af et centraliseret versionskontrolsystem (Brindescu, Codoban, Shmarkatiuk, & Dig, 2014).

Dette tyder på at udviklere der gør brug af et decentraliseret versionskontrolsystem er bedre til at følge princippet for atomiske operationer, hvilket kan stamme fra, at de ikke er nødt til at vente på den centrale server hver gang at de laver et commit, men kan gå direkte videre til næste opgave. Ventetiden som disse udviklere slipper for, kan også påvirke deres produktivitet positivt, da de ikke mister fokus, i den tid der bruges på at vente på den centrale server. Her er det også muligt at antallet af fejl bliver gjort mindre, da man må gå ud fra at udviklere producere kode af højere kvalitet, når de holder fokus.

Store softwarefirmaer, der før i tiden typisk har gjort gavn af den centraliserede model, kan også have set muligheden for større produktivitet, og derved udviklingshastighed. Dette kan være grundlag nok i sig selv, for at skifte, da den decentraliserede model bedre skalerer sig ud til mange udviklere, ved hjælp af modellens mere udbredte brug af forgrening, der formindsker chancen for at udviklere skal vente på at kunne danne deres commits og dele dem med resten af gruppen.

Overgangen fra centraliseret til decentraliseret versionskontrol har haft kæmpe betydning for store Open Source projekter som Linux, der ikke ville have muligheden for at operere på deres kæmpe skala, hvis ikke det var for den decentrale models fleksible natur.

Set fra Linux’ perspektiv ville det heller ikke have været muligt på samme måde, for nye udviklere at komme til uden at kende nogen der i forvejen bidragede til projektet, ved brug af et versionskontrolsystem som Subversion. Dette har kunnet være tilfældet, da den individuelle udvikler ville blive nødt til at blive godkendt af Subversion administratoren, for at kunne hente og sende

11/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

ændringer til Linux’ kodebase. Hvis dette var realiteten, ville det nok ikke være muligt for Linux at blive så stort som det er i dag.

7. Konklusion De decentrale versionskontrolsystemer har taget software verdenen med storm, set fra både den kommercielle industri og Open Source bevægelsen. De tillader udviklere at arbejde hurtigere og med større sikkerhed end nogensinde før, samtidig med at de tillader udviklere fra hele verdenen at arbejde sammen om kæmpe projekter som Linux, der er vitale for internettet, smartphones, og dagligdagen som vi kender den.

12/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

8. Litteraturliste Apache. (2016). Apache Subversion. Retrieved from Apache Subversion: https://subversion.apache.org/

Apache. (2016). Download Apache Subversion. Retrieved from Download Apache Subversion: https://subversion.apache.org/download/

Assembla. (2016). Assembla - Subversion. Retrieved from Assembla: https://www.assembla.com

Brindescu, C., Codoban, M., Shmarkatiuk, S., & Dig, D. (2014, May). How Do Centralized and Distributed Version Control. Hyderabad, Telangana, India: Oregon State University.

Chacon, S., & Straub, B. (2014). Pro Git. Apress. Retrieved from https://git-scm.com/book/en/v2

Git. (2016). Git. Retrieved from Git: https://git-scm.com/

Git. (2016, December 18). Git - About Version Control. Retrieved from Git: https://git- scm.com/book/en/v2/Getting-Started-About-Version-Control

Git. (2016, December 18). Git - Distributed Workflows. Retrieved from Git - Distributed Workflows: https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows

GitHub. (2016). How People Build Software - GitHub. Retrieved from GitHub: https://github.com/

Git-Tower. (2016, December 16). Why use version control? Retrieved from Why Use a Version Control System?: https://www.git-tower.com/learn/git/ebook/en/command-line/basics/why-use- version-control

Google. (2016, December 20). Google Trends - Git, Apache Subversion. Retrieved from Google Trends - Git, Apache Subversion: https://www.google.com/trends/explore?date=all&q=%2Fm%2F05vqwg,%2Fm%2F012ct9&hl =en-US&tz&tz

Pilato, C. M., Collins-Sussman, B., & Fitzpatrick, B. W. (2008). Repository Maintenance. Retrieved from SVN Repository Maintenance: http://svnbook.red- bean.com/en/1.6/svn.reposadmin.maint.html

Pilato, C. M., Collins-Sussman, B., & Fitzpatrick, B. W. (2008). Version Control with Subversion: Next Generation Open Source Version Control. O'Reilly.

Pingdom. (2012, April 16). Linux Kernel development by the numbers. Retrieved from Linux Kernel development by the numbers: http://royal.pingdom.com/2012/04/16/linux-kernel- development-numbers/

Samsung Open Source Group. (2016, March 2016). An Introduction to the Open Source Development Model - Samsung Open Source Group Blog. Retrieved from An Introduction to the Open Source Development Model - Samsung Open Source Group Blog: https://blogs.s- osg.org/introduction-to-open-source-development-model/

13/14 E-NN SRP – Teknologi A og ITK B 21/12 - 2016

Stack Overflow. (2015). Stack Overflow Developer Survery 2015. Retrieved from Stack Overflow Developer Survery 2015: Stack Overflow Developer Survery 2015

The Linux Foundation. (2013). Linux Kernel Development. Retrieved from Linux Com: https://www.linux.com/publications/linux-kernel-development-how-fast-it-going-who-doing- it-what-they-are-doing-and-who-0

Wikipedia. (2016, November 30). Apache Subversion. Retrieved from Apache Subversion: https://en.wikipedia.org/wiki/Apache_Subversion?oldformat=true

Wikipedia. (2016, October 23). Atomic commit. Retrieved from Atomic commit: https://en.wikipedia.org/wiki/Atomic_commit?oldformat=true

Wikipedia. (2016, November 7). BitKeeper. Retrieved from BitKeeper: https://en.wikipedia.org/wiki/BitKeeper?oldformat=true

Wikipedia. (2016, November 12). File Locking. Retrieved from File Locking: https://en.wikipedia.org/wiki/File_locking?oldformat=true#Version_control_systems

Wikipedia. (2016, December 18). Git. Retrieved from Git: https://en.wikipedia.org/wiki/Git?oldformat=true

Wikipedia. (2016, December 17). Hash function. Retrieved from Hash function: https://en.wikipedia.org/wiki/Hash_function?oldformat=true

Wikipedia. (2016, December 16). Linux. Retrieved from Linux: https://en.wikipedia.org/wiki/Linux?oldformat=true

Wikipedia. (2016, September 17). Revision tag. Retrieved from Revision tag: https://en.wikipedia.org/wiki/Revision_tag?oldformat=true

Wikipedia. (2016, December 1). Version Control - Graph Structure. Retrieved from Version Control: https://en.wikipedia.org/wiki/Version_control?oldformat=true#Graph_structure

Wikipedia. (2016, December 1). Version Control - Wikipedia. Retrieved from Version Control: https://en.wikipedia.org/wiki/Version_control?oldformat=true

Wikipedia. (2016, December 18). Waterfall Model. Retrieved from Waterfall Model: https://en.wikipedia.org/wiki/Waterfall_model

14/14