Versionskontrol

Hvad er versionskontrol?

Versionskontrol betyder, at ændringer mellem to udgaver af en fil journaliseres og håndhæves af “nogen eller noget”. Dette nogen eller noget er versionskontrolsystemet - dvs. software som fungerer lidt a´la en politibetjent, der styrer trafikken i et lyskryds. Der findes et hav af værktøjer/systemer til at håndtere kildekodekontrol. Et af de mere populære er SubVersion – eller SVN som det også kaldes - og det vil være udgangspunktet i dette indlæg.

Udover de fordele der er ved at kunne sammenligne revisioner af filer og/eller hele systemer, håndtering af kildekodekonflikter, tilbagerulning, fremadrulning m.v. er der flere andre forhold i versionskontrol, der har betydning for hvor godt og effektivt vi kan udvikle software. F.eks. branching, authentication, authorization, continuous integration og deployment for slet ikke at tale om tilstedeværelsen af det audit trail man får, når man kan spore, hvem der ændrer hvad, hvornår og hvorfor.

Andre populære alternativer til SVN er f.eks. Mercurial og git som begge er systemer, der understøtter udviklingsteams som er distribuerede. Linus Torvalds startede med at udvikle git ud fra tankegangen – hvor svært kan det være – nå, ja og så fordi Linux kernel udviklingen har specielle udfordringer med et world-wide distrubueret miljø. Han er endog meget begejstret for git. Torvals kan ikke rigtigt lide SVN (eller noget som helst andet der ikke hedder git – med en lille undtagelse ift. Mercurial) dels fordi SVN kommer fra CVS, dels fordi man er afhængig af en server, dels fordi man ikke selv har håndsret over, hvem der er med i ens "Trust Network" og dels fordi man ikke har sikkerhed for, at den fil man har lagt under versionskontrol i SVN nu også er 100% mage til den med står med i hånden.

Til de fleste ting er SVN ikke så tosset endda; men det er givet, at git og Mercurial er klart overlegene systemer set fra et puristisk og strengt teknisk synspunkt. Her beskæftiger vi os med virkelighed og virkeligheden er, at SVN bliver brugt i stor stil verden over med en vis succes.

Branching og valg af en passende strategi vil vi ikke beskæftige os med lige nu.

Hvorfor skal man bruge et versionskontrolsystem?

Et versionskontrolsystem giver ikke kun mening for teams - også for enkeltindivider er der værdi at hente. Netop fordi man kan gå vilkårligt lang tid tilbage i tiden, branche, tagge, flette ændringer, rulle frem og tilbage og i det hele taget har nogle gode værktøjer til at håndtere, hvad der sker med ens kodebase.

Desværre er der stadig mange virksomheder, som ikke bruger et versionskontrolsystem; men forfalder til f.eks. at tage en kopi af kildekode, der er udviklet på én pc over i en dato stemplet folder på netværket, usb stick e.l., hvorfra andre så må kopiere koden og så fremdeles.

Så er der styr på sagerne, ikke? Nej, det er der desværre slet ikke. Der er begrænsede muligheder for at genbruge kode, der er begrænsede muligheder for at spore krav til kode, der er begrænsede muligheder for at spore ændringer mellem version 1 og version 1.1. Der er begrænsede muligheder for at beregne metrikker (som bl.a. kan bruges til at vurdere kodens konstruktive kvaliteter). Ja, der er i det hele taget meget dårlige muligheder for at arbejde med koden på et abstrakt niveau.

Det er sjældent så grelt; men det er omvendt heller ikke noget særsyn, at det foregår efter lignende opskrift. Så, hvis man er ramt af den slags problemer, kan det kun gå for langsomt med at få gjort noget ved det.

Er der frit valg på alle hylder når man skal vælge versionskontrolsystem?

Ja, stort set.

Jamen er det så ligegyldigt hvad man vælger?

Næppe!

Valg af versionskontrolsystem afhænger helt af behov (og pengepung). SVN, git og Mercurial er gratis systemer, som du kan installere på dit eget IT udstyr - og til prisen er de fremragende og stikker i mange tilfælde dyre, komplekse produkter med flere længder. Ønsker du ikke at stå med administrationsbyrden selv findes der masser af hostede løsninger til alle 3 systemer.

SVN skalerer fint til medium størrelse systemer; men kan ikke anbefales til meget store systemer eller til distribuerede miljøer.

Perforce klarer med lethed rå mængder af digitale aktiver, f.eks. video, 3D materiale, store fotofiler m.v.. Dér knækker f.eks. git halsen idet git sikrer data integritet ved at lave hash beregning på alt.

git er til gengæld en schweizerkniv til klartekst, distribuerede miljøer, 3-vejs merge og hvad ved jeg.

ClearCase – tja, der kan skrives tykke bøger om alt det ClearCase gør dårligt. En ting det sammen med ClearQuest gør ganske godt - omend omstændeligt - er at øge sporbarheden fra krav til kørende system. Tilsvarende sporbarhed kan opnås med stort set alle versionskontrolsystemer ved også at integrere krav- og bugtrackingværktøjer.

Så valget af versionskontrolsystem beror i høj grad på, hvilket behov det skal løse. Lige som alle andre forhold ift. softwareudvikling bør man træffe et oplyst valg. Dvs. et valg, hvor man har undersøgt, hvad konsekvensen er for ens forretning.

Visual SourceSafe må I den forbindelse dømmes helt ude som seriøst versionkontrolsystem ift. den måde vi ønsker at udvikle software på.

Der er rigtig mange problemer med Visual SourceSafe. F.eks. låses filer ved checkout hvorved andre ikke kan ændre i den eller de filer, der er checket ud. Går udvikleren på ferie eller bliver syg er det bare ærgeligt. Filerne er låste og en administrator (hvis man kan finde ham) må låse dem op igen.

Teamfaciliteterne (f.eks. merge) i VSS meget dårlige - grænsende til ikke-eksisterende - og man risikerer tit og ofte at en VSS database korrumperes og derfor med jævne mellemrum må renses op med et kommandoliniebaseret værktøj (det følger ligefrem med VSS).

Hvordan fungerer SubVersion / SVN?

SVN er delt op i en server- og en klientdel. Serverdelen er porteret til mange platforme eller man kan bruge en hosted service i skyen. Klientdelen kan også anvendes på mange platforme herunder Windows, Mac og Linux.

Til Windows findes desuden TortoiseSVN som er en Windows Explorer extension. Det betyder, at man kan interagere med SVN serveren direkte i Windows’ fil explorer.

Til Mac er man sandsynligvis nødt til at betale noget for en SVN klient.

Til Linux – say hello to the command line client.

Hvis man udvikler i Visual Studio og foretrækker en integreret oplevelse kan man bruge den plug-in, der hedder AnkhSvn.

Begreber som Repository, Checkout, Commit (checkin), Update, Merge, Revision er noget enhver SVN bruger bliver mødt med og skal forstå, for at kunne bruge systemet effektivt.

Et repository er det sted, hvor filerne opholder sig, når de er under versionkontrol. Den typiske SVN struktur er trunk, branches og tags. Trunk er den baseline man arbejder på. Branches og tags behandles i et senere indlæg.

I SVN er det sådan, at man per definition har checket en fil ud, når man har trukket en kopi ned på sin maskine. Man checker ind, når man committer sine ændringer til SVN.

SVN serveren ved ikke noget om, at man har en kopi – man arbejder så at sige off-line indtil man checker ind. Inden checkin laver man gerne en update og evt. en merge, hvis der er ændret i de samme linier af en anden udvikler og SVN ikke automatisk kan merge disse ændringer.

Inden man går i gang med at rette i en source-fil sørger man gerne for, at man har den seneste revision til rådighed. Er det første gang laver man en Checkout fra et repository. Er det ikke første gang laver man en Update.

Når man committer til SVN får hele træet et nyt revisionsnummer. Vi tager den lige igen: Hele træet stemples med et nyt nummer! Derudover er ethvert commit atomart, hvilket betyder, at enten går hele svineriet godt eller også går det skidt. Ikke noget med, at nogle filer er checket ind og andre er ikke. Alt hvad man sender med i et commit er med i transaktionen som godkendes eller afvises i sin helhed.

Eksempler

Det vil føre for vidt med en komplet gennemgang af SVN og TortoiseSVN her – kig på nettet, der er masser af eksempler. Jeg vil dog vise 2 faciliteter, hvor SVN giver os god værdi. Det ene er loggen og det andet er håndtering af konflikter mellem ændringer i samme fil.

Loggen

Loggen findes i TortoiseSVN

- og giver os mulighed for at se, hvad der er sket med en given fil over tid. De underligt udseende ikoner er TortoiseSVN’s overlay icons, som viser hvilken tilstand en given fil under versionskontrol befinder sig i. En grøn ikon betyder, at filen ikke har ændret sig siden den blev checket ud / opdateret.

Her er loggen for style.css

Jeg kan f.eks. sammenligne ændringer mellem version 103 og version 109 ved at vælge disse to filer i listen, højreklikke og vælge “Compare revisions”.

På den måde har vi fuldstændig sporbarhed ift. hvem der har ændret hvad hvornår. Når vi kobler krav- og bugtracking systemer på, får vi også mulighed for at besvare spørgsmålet: Hvorfor er denne linie ændret?

Håndtering af konflikter

Konflikter opstår f.eks. når to udviklere retter i de samme linier i den samme fil uafhængigt af hinanden. Det er helt ok. Det er op til de fremherskende processer på stedet at fastlægge, hvad der skal ske, når man bliver ramt af en konflikt i versionkontrollen. Lad os bare for nemheds skyld antage, at vi skal løse konflikten.

Lad os sige, at udvikler 1 har tilføjet noget tekst til style.css linie 43 og checket denne ind i et SVN repository.

Nu kommer udvikler 2 (os) på banen. Vi tilføjer (eller retter) også noget tekst i style.css linie 43. Idet vi forsøger at checke ind eller lave en update bliver vi ramt af en konflikt, som vi må tage stilling til.

Vi kan lave en kvalificeret undersøgelse af konflikten ved at kigge på forskellene i indholdet og derefter tage stilling til, hvad der skal ske eller vi kan lave en blind accept af enten "vores egen" eller “de andres” ændringer. Vi laver til at starte med det vi kalder en “Compare with working copy” ved at klikke på filen i dialogen og derefter højreklikke (brug f.eks. WinMerge, BeyondCompare, K-Diff e.l. til merge opgaver) .

Efter at have kigget på konflikten ved at sammenligne de to revisioner beslutter vi os i dette tilfælde for, at vi bedre kan lide de andres ændringer, hvorfor vi forlader merge programmet og vælger Resolve conflict using ‘theirs’.

Hvis vi havde merget ændringerne til én konsolideret helhed ville vi i stedet have valgt Mark as resolved.

Ved en merge handling skal vi checke ind igen og håbe på, at der ikke er opstået nye konflikter i mellemtiden.

git håndterer konflikter og 3-vejs merges en del bedre end SVN. Behovet for 3-vejs merges opstår når man brancher. Det er ikke så farligt endda og det er en disciplin man er nødt til at udøve for at kunne supportere systemer i drift samtidig med at man udvikler videre – måske endda i flere parallelle spor.

Add comment

Loading