Henrik Bærbak Christensen1 Software Konfigurationstyring Datalogifagets sorte får…

Henrik Bærbak Christensen2 Spørgsmålene Software udvikles i teams. Det giver ofte nogle ”spændende” oplevelser: –Det virkede igår!!! Det gjorde det altså... –Kunden rapporterer en fejl, som jeg mener, at vi har rettet??? –Hvad er det egentligt, der kører ude ved kunden? –Er bug #37 fixet i release 2.4.9? –Hvem f….. har rettet i mine filer??? –Min rettelser forsvandt da Benny savede oveni!

Henrik Bærbak Christensen3 Versioner og varianter Det handler om identitet –’Hvilken version af comm-lib bruger du?’ –’Jeg skal bruge database interfacet, der passer til Oracle’ –Kunden har rapporteret en fejl i version –Hvilken version af comm-lib blev der brugt i version 2.4.9?

Henrik Bærbak Christensen4 Samarbejde Samarbejde vha. fil-organisering Alle arbejder på et ’shared’ directory –  ’omvendt race-condition’ – hvem save’r sidst? Hver arbejder på en kopi –  fletning af rettelser meget tidskrævende Veldefineret ansvar for individuelle kilde-tekster –Omstændeligt !

Henrik Bærbak Christensen5 Løsningen (!) Software konfigurationstyring (software configuration management SCM) er en af de få discipliner i software engineering som faktisk har formået at levere (store dele) af varen: –Teoretiske modeller for versions- og variant håndtering som er praktisk anvendelige –Værktøjer til at støtte praktisk arbejde Dog... Det fleste kommercielle værktøjer benytter modeller på ret lavt abstraktionsniveau...

Henrik Bærbak Christensen6 Centrale begreber Centralt for SCM er: –Et fælles lager hvori man gemmer (dele af) ens software som det så ud på et bestemt tidspunkt (snapshot) –Et skema for hvorledes atomare og sammensatte software-enheder defineres –Et skema for automatisk identifikation af sådanne snapshots –Et ubegrænset antal individuelle arbejdsområder hvortil man kan hente konfigurationer, videreudvikle dem, samt igen gemme dem i lageret –Et skema for hvorledes samarbejde foregår, oftest i form af en politik for hvorledes konfigurationer gemmes i lageret / arbejdsområderne.

Henrik Bærbak Christensen7 Terminologi VersionSpace (Repository) ProductSpace (Workspace) ProductSpace (Workspace) ProductSpace (Workspace) VID = check-in() check-out(VID) Check-in: Gem en kopi af den nuværende tilstand af arbejdsområdet i versionslageret, og returner en unik identifikation (VID) af det gemte. Check-out: Genskab en tidligere tilstand af arbejdsområdet, identificeret ved VID, i arbejdsområdet.

Henrik Bærbak Christensen8 Terminologi Atomare enheder: –Den mindste ’udelelige’ enhed som SCM systemet kan håndtere. –Typiske kommercielle systemer har filen som atomar enhed forskningsbaserede systemer har været helt nede på tegn niveau. Sammensatte enheder (konfigurationer): –Composite pattern: Veldefineret mængde af atomare og sammensatte enheder –Typiske kommercielle systemer har kataloget/mappen som sammensat enhed

Henrik Bærbak Christensen9 Terminologi Definition: En konfiguration er en navngiven samling af atomare enheder og andre konfigurationer. –(Design pattern: Composite). Eks.: –Windows98 er en veldefineret (?) mængde af programmer, dll’er, grafiske resourcer, osv.

Henrik Bærbak Christensen10 Terminologi Definition: En version, v i, repræsenter tilstanden af en softwareenhed under udvikling til tid i. Et SCM-systems fornemmeste opgave er at sikre –Automatisk identifikation af versioner dvs. at det er SCM systemet som egenhændigt bestemmer hvad version v i skal hedde –Organisere versioner i relation til hinanden dvs. at SCM systemet opretholder en fast struktur af versionerne. Denne struktur er fundamentalt baseret på det tidslige aspekt

Henrik Bærbak Christensen11 Versions identifikation Standarden for identifikation var i mange år de såkaldte dewey numre: –1. version kaldes 1.1 –derefter kaldes de 1.2, 1.3, 1.4, 1.5 osv. –Talparret kaldes major og minor revisionnumre –Version 1.3 er yngre end version 1.2. Basta! Major revision nummeret kan man også inkrementere: –1.256, 1.257, 2.0, 2.1, 2.2, 2.3, …

Henrik Bærbak Christensen12 Versions identifikation Dewey-nummeret bliver tildelt ved check-in. Kun hvis en softwareenhed faktisk er ændret bliver nummeret ændret! Dvs. hvis man står med version 1.4 og 1.5 af ens fil ’hans.txt’ så er man garanteret at der er sket ændringer imellem de to versioner.

Henrik Bærbak Christensen13 Versions organisering Dewey-numrene definerer en udvikling over tid af vores software enhed. Dette opfatter man ofte som en orienteret graf. Grafen kalder vi versionsgrafen. Her er den simpel men den kan hurtig blive meget kompliceret når vi får parallel udvikling af software enheder. hans.txt 1.1hans.txt 1.2hans.txt 1.3hans.txt 1.4

Henrik Bærbak Christensen14 Et eksempel: Et af de første † Tichy: RCS = Revision Control System (1982) c:\tmp>ci hans.txt hans.txt,v <-- hans.txt enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message! >> En beskrivelse af Hans >>. initial revision: 1.1 done c:\tmp>co -l hans.txt hans.txt,v --> hans.txt revision 1.1 (locked) done c:\tmp>ci hans.txt hans.txt,v <-- hans.txt new revision: 1.2; previous revision: 1.1 enter log message, terminated with single '.' or end of file: >> Beskrivelsen er detaljeret yderligere. >>. done RCS gemmer kun differencen mellem to versioner:  -storage. † Et endnu ældre system er SCCS

Henrik Bærbak Christensen15 RCS realisering Versionspace: Et subkatalog kaldet RCS med datafiler Atomar enhed: En tekstfil (speciel håndtering af binære) Konfigurationer: [ingen understøttelse] Productspace: Et vilkårligt katalog Identifikation: –Revision numre: 1.1, 1.2, 1.3 på atomart niveau –Etiketter på konfigurations niveau Samarbejde: Låsning = pessimistic concurrency Sidstnævnte er som en monitor abstraktion: Kun een udvikler kan rette ad gangen (men alle kan læse...)

Henrik Bærbak Christensen16 Pessimistic concurrency RCS’s låse model sørger for en streng sekventialisering af opdateringer på fil-niveau. Udviklere:ArneBirte Ofte er det for pessimistisk –Hvis de arbejder i hver sin ’del’ af filen –Hvis eks. Arne glemmer at slippe låsen... –Visse filer bliver let flaskehalsen i systemet hans.txt 1.1hans.txt 1.2hans.txt 1.3hans.txt 1.4

Henrik Bærbak Christensen17 Konfigurationer I de ’gode gamle’ dage da ’en fil = et program’ var RCS’s model tilstrækkeligt; men hvis et program består af mange kildetekster går det galt. RCS kan ikke håndtere konfigurationer særlig elegant! Eksempel: Et program bygges af kildeteksterne W, S, og senere også T

Henrik Bærbak Christensen18 The Selection Problem W 1.3 W 1.4 W 1.5 W 1.6 S 1.1 S 1.2 S 1.3 S 1.4 T 1.1 T 1.2 T 1.3 T 1.4 Application Release 1.0 Application Release 2.0

Henrik Bærbak Christensen19 Bunden versus generisk En konfiguration er enten bunden eller generisk: Bunden: –Identiteten af alle atomare versioner er fastlagt Generisk: –For mindst een atomar enhed gælder at dens versionsidentitet ikke er fastlagt

Henrik Bærbak Christensen20 Konfigurationer Øvelse: –Hvor vil man typisk ønske bundne konfigurationer? –Hvad er formålet med bundne konfigurationer? –Hvor har man typisk generiske konfigurationer?

Henrik Bærbak Christensen21 RCS’s løsning RCS løser ’selection problem’ vha. etiketter: Man definerer en etiket (=en streng) og den kan man klistre på alle de revisioner, man har liggende i sit workspace: Men: det virker kun i et katalog ad gangen! c:\tmp>rcs -nRel01: *.txt RCS file: hans.txt,v done c:\tmp>co -rRel01 *.txt hans.txt,v --> hans.txt revision 1.2 done Det vil sige at en bunden konfiguration defineres ved at sætte etikette på alle fil- versioner, der indgår i den.

Henrik Bærbak Christensen22 Problemer med RCS To umiddelbare problemer ved RCS: –Den pessimistiske låsning –Meget besværligt at håndtere komplekse konfigurationer (dvs. over flere kataloger)

Henrik Bærbak Christensen23 CVS CVS: Concurrent Version System –Versionspace: En katalogstruktur med rod i CVSROOT –Atomar enhed: En tekstfil (speciel håndtering af binære) –Konfigurationer: Kataloger (rekursivt!) –Productspace: En vilkårlig katalogstruktur –Identifikation: Revision numre: 1.1, 1.2, 1.3 på atomart niveau Etiketter på konfigurations niveau –Samarbejde: Optimistic concurrency - dvs ingen låsning CVS bygger faktisk ovenpå RCS…

Henrik Bærbak Christensen24 Optimistic concurrency Både Arne og Birte må nu rette i ’hans.txt’ i parallel. Den første til at checke ind får uden videre lov. Den næste skal først lave en fletning (merge) inden vedkommende kan få lov. Fletning: Ved en fletning skal mængden af rettelser siden sidste forgreningspunkt i versionsgrafen forenes.

Henrik Bærbak Christensen25 hans.txt 1.1hans.txt 1.2hans.txt 1.3hans.txt 1.4 Optimistic concurrency hans.txt 1.1+ hans.txt 1.2+  commit update En fletning kan naturligvis give en konflikt, som så først skal rettes. En konflikt opstår hvis mere end en person har rettet i det samme område af filen.

Henrik Bærbak Christensen26 Subversion –Versionspace: En rigtig database, flere protokoller for adgang (http, svn, file) –Atomar enhed: En vilkårlig fil (håndterer binær og tekst ligegodt) –Konfigurationer: Kataloger (rekursivt!) –Productspace: En vilkårlig katalogstruktur –Identifikation: Atomart: Eet globalt og unikt versionsnummer e.g. ’772’ Konfigurationer: Det samme! Hurra!!! –Samarbejde: Optimistic concurrency - dvs ingen låsning ‘A better CVS’

Henrik Bærbak Christensen27 Subversion Version nummeret er globalt på repository! –se springet fra

Henrik Bærbak Christensen28 Subversion Version nummer metafor –En fuld, dyb, kopi af projekt folderen med det given nummer “zip det hele fra roden og giv det navnet v772.zip” –Det vil sige at alle ændringer i filer og katalogstruktur bliver gemt det sidste kan etiketter slet ikke finde ud af –hvad betyder det at en fil IKKE har en etiket? »den er blev slettet? det er ikke tilføjet endnu? cvs fjerner ikke filer ved check-out Version nummeret er en entydigt specifikation!

Henrik Bærbak Christensen29 Subversion Subversion kan tale flere protokoller –HTTP og HTTPS: Med en apache server I kan f.eks. gratis hoste jeres gruppes projekt på code.google.com –file: brug et katalog på din lokale maskine (eller mounted drev) som repository. svn klienten kan selv opdatere database som ligger deri. –SVN: start en ‘svnserve’ process op på en maskine med reference til en eksisterende database.

Henrik Bærbak Christensen30 TortoiseSVN [Demo]

Henrik Bærbak Christensen31 Subversion versus CVS Subversion er en ‘better CVS’ –Stort set samme syntax –Samme gode optimistic concurrency model for samarbejde –Men en væsentlig bedre release og version control model (CVS stinker virkelig der) Så – skift til Subversion!!!

Henrik Bærbak Christensen32 Branching Ofte må et produkt vedligeholdes samtidigt i flere forskellige konfigurationer; f.eks. bug-fix releases Man kan så flette (merge) rettelser fra den ene gren ind i en anden (ofte under stor pine…). hans.txt 1.1hans.txt 1.2hans.txt 1.3hans.txt 1.4 hans.txt

Henrik Bærbak Christensen33 Varianter Versioner udelukker i en eller anden forstand hinanden: Enten bruger man version 1 eller 2. Varianter, derimod, lever et parallelt liv –Database model til Oracle, dBase,... –En lokal eller distribueret variant –Variant som får data fra rigtige instrumenter/en stub

Henrik Bærbak Christensen34 Varianter Varianter håndteres ofte med een af to teknikker –Single-source variant f.eks. #ifdef i C++ –Variant segregation Branches i SCM’ tool Variant segregation problemer –multiple-maintenance problem: Fælles kode i de forskellige branches skal holdes konsistente –kombinatorisk eksplosion af muligheder: Er der tre variationsdimensioner, hver med tre muligheder, er der ialt 27 branches at vedligeholde!

Henrik Bærbak Christensen35 Varianter Single-source problemer –Kildeteksten bliver overfyldt med meta-information –Svært at følge det logiske flow i kildeteksten Varianter er ofte karakteriseret ved at være på sætnings-niveau; derfor er SCM branches som regel alt for grovkornede. Endnu bedre: Brug design patterns til at isolere og afkoble variationspunkter (lav designet til et framework )