Versionshantering Sami Nevalainen Institutionen för informationsbehandling Åbo Akademi, FIN-20520 Åbo, Finland e-post: snevalai@abo.fi Abstrakt Denhär texten handlar om versionshantering av mjukvara. Först motiveras behovet för versionshantering och sedan förklaras de mest centrala begreppena och metoderna. Därefter tas det en närmare titt på hur de flesta versionshanteringsprogrammena idag fungerar och vilka brister som de har. Klassificering Klassificering enligt ACM klass: D.2.7 Version Control Klassificering enligt ACM SIG: SIGSOFT 1 Introduktion Det uppstår ständigt behov av förändringar vid utveckling av mjukvara. De fyra fundamentala källorna för förändringsbehov är [Pre97]: nya företagsstrategier eller marknadsförhållanden som kräver förändringar i produkt specifikationerna eller affärsreglerna (business rules) kundens förändrade behov som kräver modifiering av data producerat av ett informationssystem, funktionaliteten hos produkten eller tjänster producerat av ett datorbaserat system
omorganisering och/eller nedskärning av affärsverksamhet som förorsakar förändringar i projektets prioriteringar eller utvecklingsgruppens sammansättning begränsningar i budget eller tidtabell som förorsakar en omdefiniering av systemet eller produkten Ett modernt programvaruprojekt består av en mängd komponenter. Till komponenterna i ett program kan räknas saker som: specifikationer, modeller, dokumentation, användarmanualer, programkod och liknande. Dessa komponenter har en sak gemensamt. De utvecklas och förändras ständigt på grund av ovan nämnda orsaker. Dethär leder till att det kan finnas flera versioner av samma komponent som är i bruk samtidigt. Till exempel kan kunden använda en version medan en annan version är under testning för senare leverans åt kunden och en tredje fortfarande endast är i utvecklingsskede. Om förändringar av komponenterna inte görs behärskat kan det introduceras problem eller fel i produkten. Orsaker som kan leda till brister är t.ex. samtidig modifikation av en komponent där den ena utvecklarens modifikationer av en fil skriver över den andra utvecklarens förändringar, förändringar i en gemensam komponent som inte meddelas åt alla användare av komponenten och korrigeringar av fel i en version av en komponent som inte uppdateras till andra versioner av samma komponent. Trenden inom utvecklingen av programvara är att projektena blir allt större. Dethär betyder att allt fler personer är inblandade i ett projekt. Då varje person är en källa till möjliga förändringar ökar risken för att fel skall introduceras i systemet som är under utveckling. Det här leder till att det behövs en strategi för att hantera förändringar vid utvecklingen av programvara. 2 Konfigurationsledning Begreppet konfigurationsledning av mjukvara (Software Configuration Management, SCM) uppstod under sena 70 talet och början av 80 talet, då man börjat inse att programmering inte är den enda aktiviteten som är av betydelse vid utveckling av programvara[est00]. Babich definierar konfigurationsledning på följange sätt [Bab86]: Configuration management is the art of identifying, organizing, and controlling modifications to software being built by a programming team. The goal is to maximize productivity by minimizing mistakes. Fritt översatt till svenska betyder dethär att målet med konfigurationsledning är att maximera produktiviteten hos ett grupp programmerare genom att identifiera och hantera förändringar som uppstår under tiden som mjukvara utvecklas. Ser man på konfigurationsledning ur utvecklarperspektiv kan man identifiera följande
områden [Ask99]: Versionshantering möjligheten att lagra olika versioner och varianter av ett dokument för att senare kunna hämta och jämföra dem. Konfigurationer/Urval funktionalitet för att skapa respektive välja ut sammanhörande versioner (eller grenar) av olika dokument. Synkronisering hanterar samtidig åtkomst från flera användare, dvs. parallell utveckling, antingen genom att förhindra sådan, eller genom att stödja den. Systemgenerering mekanismer för att hålla genererade filer aktuella, t.ex. vid kompilering. Rapportering, status rapportering av aktuellt status med listor över vilka filer som ändrats under än viss tid, vem som ändrat, skillnader mellan produkter, etc. Processtöd verktyg som hjälper utvecklaren att följa den utvecklingsmodell och utföra de moment som modellen och CM planen föreskriver. Ändringshantering system som stöd för hantering av insamling av ändringsbegäran, t.ex. i samarbete med kundstöd, generering av felrapporter, konkreta ändringsbegäran, utförande av ändringarna, dokumentation av problemet och lösningen samt när den blir tillgänglig. Produktdatahantering hantering av struktur på produkten, ingående komponenter, programvara, dokumentation. Åtkomstkontroll att förhindra otillbörlig åtkomst till information utan att det försvårar normalt arbete. De konfigurationsledningsverktyg, som en systemutvecklare använder, stöder ofta flera av ovanstående funktioner. 3 Versionshantering Ovan nämndes att konfigurationsledningen har ett delområde versionshantering, vars uppgift är att lagra olika versioner och varianter av ett dokument för att man senare skall kunna hämta och jämföra dem. En vanlig orsak till att man vill jämföra två versioner av en komponent är bland annat då man söker svar på frågor som: Dethär programmet fungerade igår. Varför fungerar det inte idag? eller Varför har dethär felet återuppstått? Jag har ju redan korrigerat det..
3.1 Versionshanteringens beståndsdelar Den centrala beståndsdelen i ett versionshanteringssystem är konfigurations objektena (Software Configuration Item, SCI), alltså komponenterna som är under versionskontroll. I inledningen nämndes att komponenterna kan vara programkod, dokumentation, modeller och motsvarande. Pressman definierar konfigurations objektena som information som skapas som en del av programvaru-utvecklingsprocessen [Pre97]. Den minsta komponenten ett versionshanteringssystem känner till kallas atom. Versionshanteringen ser en atom som ett ostrukturerat objekt, en helhet. Trots det har atomen oftast en intern struktur. De ända sakerna som versionshanteringssystemet kan urskilja för en atom är t.ex. om atomen raderats, om den bytt namn eller om den har modifierats. Komponenter som inte är atomer kallas konfigurationer. En konfiguration består av andra komponenter och har en struktur som versionshanteringssystemet känner till. Eftersom versionshanteringssystemet förstår sig på konfigurationens struktur kan det inte endast upptäcka förändringar i den utan också förstå sig på dessa förändringar. Med hjälp av regler kan versionshanteringen av konfigurationer därför automatiseras. 3.1.1 Typer av versioner En version representerar ett tillstånd av en komponent under utveckling [CW98]. Alla komponenter som är versioner av varandra delar på en del gemensamma egenskaper. Dessa egenskaper kallas invariant och de måste uppfyllas för att två komponenter skall kunna anses vara versioner av varandra. Hur omfattande invarianten är varierar. Den enklaste invarianten innehåller endast ett sätt att identifiera en komponent t.ex. ett namn på komponenten. I det här fallet kan två versioner av en komponent förutom vad gäller namnet ha helt godtyckliga egenskaper och funktionalitet. Beroende på hur två versioner av en komponent är relaterade till varandra kan man dela upp versionsförhållandet i två olika typer: revisioner och varianter. Som nämndes tidigare förändras komponenter hela tiden. Ofta är orsaken till dethär att man vill förbättra komponenten, rätta ett fel i den eller lägga till någon ny egenskap. Den nya versionen, som uppstår genom en förändring av den tidigare komponenten, kallas för revision. Revisioner beskriver alltså en komponents utveckling. I figur 1 ser vi utvecklingen av en komponent. Längst till vänster har vi komponenten som den såg ut i början av utvecklingen, till höger har vi komponenten som den ser ut idag och
däremellan är olika revisioner som uppstått under utvecklingens gång. Vi ser att av revision 1.2 har det skapats två nya revisioner 1.3 och 1.2.1.1 vars modifikationer har sammanslagits till revision 1.4. Tidigare nämndes att kunden kan ha en version av en komponent medan utvecklarna jobbar på en annan. Om kunden upptäcker en brist i sin komponent och anser att felet måste fixas omedelbart, men utvecklarna håller på med en ny revision som innehåller större förändringar av komponenten och därför inte omedelbart kan tas i bruk, kan man skapa en ny tillfällig revision, som 1.2.1.1 i figur 1, där korrigeringen kan göras så att kunden kan ta den i bruk omedelbart. När utvecklarna är färdiga med sina förändringar skapas en ny revision där man sammanslår utvecklarnas revision med revisionen som innehåller lösningen på kundens problem. Genom att skapa två revisioner av en komponent och senare sammanslå förändringarna möjliggjordes alltså parallell utveckling av en komponent. 1. 1 1. 2 1. 3 1. 4 1. 5 1. 2. 1. 1 Figur 1. Revisioner beskriver en komponents historia Revisionen var alltså en version som ersatte den tidigare versionen av en viss komponent. Ibland vill man dock ha flera versioner av en komponent som existerar i ens system samtidigt. Till exempel kanske man behöver två versioner av en komponent för att stöda olika operativsystem. I så fall kommer versionerna att ha samma funktionalitet, men de kommer att användas i olika omgivningar och därför ha olika implementation. Versioner som har samma funktionalitet och som utvecklas och underhålls parallellt kallas varianter. I figur 2 ser vi hur varianterna 1.3 1.5 och 1.2.1.1 1.2.1.3 utvecklas parallellt. Man kan t.ex. tänka sig följande situation: Den ursprungliga komponenten 1.1, som är en specifikation har vidareutvecklats i revision 1.2 varefter man har börjat implementera komponenten. Om vi tänker oss att det är en databas man tillverkar kanske man har gjort en variant av databasen där man prioriterar snabb access av data och en variant där man prioriterar effektiv lagring av data genom att man minimerat användandet av diskutrymme. Att dessa varianter av databasen delar samma funktionalitet är lätt att inse eftersom de är implementationer av samma specifikation.
1. 1 1. 2 1. 3 1. 4 1. 5 1. 2. 1. 1 1. 2. 1. 2 1. 2. 1. 3 Figur 2: Varianter har samma egenskaper och utvecklas parallellt 3.1.2 Identifikation av versioner Varje version av en komponent måste gå att identifiera. Dethär görs med en så kallad versionsidentifikator (version identifier, VID) [CW98]. Ofta används olika numreringssätt på revisioner och varianter. Många versionshanteringssystem genererar automatiskt unika versionsnummer. I figur 1 och figur 2 används samma numreringssystem som The Revision Control System (RCS) använder[tic82]. Man kan se på figurerna som ett träd av versioner av en komponent. Då kommer stammen att numreras med 1.1, 1.2, 1.3,, 2.1, 2.2 osv. Om trädet grenar på sig kommer varje gren att tilldelas ytterligare två nummer. Det första numret berättar vilken i ordningen grenen är och den andra vilken revision av grenen som det är frågan om. Således kommer den första revisionen som grenat på sig från version 1.2 att få versionsnummer 1.2.1.1, som i figurerna. 3.1.3 Skillnader mellan versioner Skillnaden mellan två versioner kallas delta. Om man har två versioner av en komponent kan man om känner till den ena versionen och deltat mellan versionerna räkna ut den andra versionen. Dethär är en viktig egenskap. Det har nämligen visat sig att förändringarna eller deltat mellan två versioner oftast är mycket mindre till storlek än versionerna själva. Därför kan man utnyttja deltat till att spara lagringsutrymme genom att endast spara en fullständig version och de olika deltas med vars hjälp alla versioner kan räknas ut. Speciellt viktig blir denhär egenskapen om man har ett versionshanteringssystem som fungerar över ett nätverk, som åtminstone ännu idag är en flaskhals när det gäller effektiviteten hos ett versionshanteringssystem.
3.1.4 Modeller Det vanligaste sättet att beskriva en komponents utveckling med versioner visuellt är med hjälp av en versionsgraf som i figurerna 1 och 2. Pilarna representerar skapandet av en ny revision eller variant. Varianter skapas om en version delar på sig i flera grenar som inte sammanslås i ett senare skede. Man kan alltså inte direkt skilja om en version är en variant eller revision ur en versionsgraf då en förgrening skapas i grafen, utan först en senare då grafen utvecklats. Det finns också nyare modeller som t.ex. den ortogonala versionshanteringsmodellen (orthogonal version management) var komponenter, varianter och revisioner utgör en tredimensionell kub. Genom att ta projektioner av kuben kan man välja grupper av komponenter, varianter eller revisioner. 3.1.5 Repository Versionshanteringen sparar alla komponenter och deras versioner i en plats som vanligtvis kallas repository. Utöver versionerna sparas också ofta tilläggsinformation, som datum för när en komponent har ändrats, vem som har gjort förändringen samt en logg med en kort beskrivning av förändringen. Dethär underlättar då man vill utforska en komponents utveckling. Repositoryt är ofta implementerat med en databas som kärna. Till exempel Subversion använder en Berkley databas som lagringsplats [CFP04]. Tidigare nämndes att man ofta använder deltas för att spara plats och göra hämtandet av versioner över ett nätverk effektivare. Det finns två typer av deltas som ett repository kan använda: bakåtvända (backward) och framåtvända (forward). Används framåtvända deltas betyder det att repositoryt sparar hela den första versionen av en komponent. Senare versioner sparas som deltas som läggs till föregående version. För att få den senaste versionen måste alltså den ursprungliga versionen och alla deltas hämtas och slås samman. När man använder bakåtvända deltas gör man precis tvärtom. Man sparar den senaste versionen komplett och generar äldre versioner genom att applicera deltas på den nyaste versionen. Fördelen med bakåtvända deltas jämfört med framåtvända deltas är att den senaste versionen, som är den som oftast söks, är snabbt tillgänglig då man inte behöver utföra några delta beräkningar [Tic82]. Ett problem som uppstår när man använder bakåtvända deltas är hur man skall spara varianter.
En lösning skulle vara att man sparade hela den sista versionen av varje variant, men en sådan lösning slösar med minnesutrymme. I RCS har man löst problemet genom att man sparar bakåt deltas för revisioner men framåt deltas för varianter. I figur 3 visas samma situation som i figur 2 med deltas. För att hämta den senaste varianten 1.2.1.3 applicerar man bakåt deltas på den senaste versionen 1.5 tills man når versionen 1.2 varifrån varianten grenat på sig. Därefter appliceras framåtvända deltas tills man når den sökta versionen 1.2.1.3. 1. 1 1. 2 1. 3 1. 4 1. 5 1. 2. 1. 1 1. 2. 1. 2 1. 2. 1. 3 Figur 3: Sparande av revisioner och varianter med deltas 3.2 Parallell utveckling Programvaruprojekt utvecklas sällan idag av endast en person. Oftast går det inte heller att fördela arbetet så att projektets utvecklare skulle jobba på sin egen del av projektet, utan det uppstår ofta ett behov där flera utvecklare behöver göra modifikationer i samma fil. I ett vanligt filsystem leder dethär till problemet som nämndes i det inledande stycket där två utvecklare öppnar en fil för samtidig modifikation. Den ena utvecklaren blir först färdig och sparar sin version. Då den andra utvecklaren en stund senare blir färdig med sina modifikationer och sparar sin version kommer den att skriva över den första utvecklarens förändringar, som på så vis går upp i rök. Det behövs alltså en mekanism i versionshanteringen som tillåter parallell utveckling på ett kontrollerat sätt. Oftast har man implementerat stöd för parallell utveckling i versionshanteringssystemena. 3.2.1 Låsning av filer Det enklaste lösningen till problemet med parallell modifikation av filer är att inte tillåta det genom låsning av filer. I ett system som använder denhär metoden låses en fil då en utvecklare checkar ut filen för modifikation. Då filen är låst kan de övriga utvecklarna inte modifiera den utan endast läsa den. Efter att utvecklaren, som låste filen, för att modifiera den har gjort sina förändringar checkar han in den tillbaka till repositoryt och låsningen upphävs varefter följande utvecklare kan låsa filen för att modifiera den.
Boken Version Control with Subversion listar tre problem med låsning av filer: låsning kan skapa administrativa problem, låsning kan leda till onödig seriellisering och låsning kan skapa en falsk känsla av trygghet [CFP04]. Dethär är orsaker till varför man menar att det behövs bättre metoder för parallell utveckling. Med låsning kan skapa administrativa problem menar man situationer som då en utvecklare låser en fil och glömmer bort eller är förhindrad att upphäva låsningen av filen, som någon annan utvecklare måste modifiera för att kunna fortsätta sitt arbete. Dethär kan vara speciellt problematiskt om personen som låst filen inte är anträffbar. Låsning kan skapa onödig seriellisering sker situationer där två utvecklare vill modifiera samma fil, men förändringarna inte påverkar varandra. Sådan kan situationen vara om en utvecklare vill ändra på några rader i början av en textfil och den andra på vill modifiera några rader i slutet av filen. I en sådan situation är det onödigt att den andra utvecklare måste vänta tills den första har gjort sina förändringar och brutit låsningen av filen eftersom båda kunde ha arbetat parallellt. Med låsning kan skapa en känsla av falsk trygghet menas att fastän man med låsning kan garantera att en fil modifieras av högst en utvecklare samtidigt och att ingens förändringar därför skrivas över, inte ändå kan garantera att det inte skulle introduceras oväntade fel i ett system vid parallell utveckling. Man kan t.ex. tänka sig att en utvecklare modifierar en fil som består av programkod som är beroende av en annan bit programkod som finns i en fil som utvecklas av en annan programmerare. Beroende på förändringarna den andra programmeraren gör kan det hända att systemet fungerar som tänkt eller inte. 3.2.2 Kopiera - modifiera - sammanslå En annan lösning på problemet med parallell utveckling är kopiera modifiera och sammanslå. I denhär lösningen tillåter man utvecklare att arbeta samtidigt på en och samma fil. Lösningen går ut på att då utvecklaren vill modifiera en fil checkar han ut filen vilket resulterar i att han får en kopia av filen, som han sedan arbetar med. När utvecklaren är färdig checkar han in den modifierade kopian till repositoryt vilket innebär att en ny version med de gjorda förändringarna skapas. Om någon annan har redan hunnit göra förändringar i samma fil som utvecklaren jobbat med och checkat in dem, kommer versionshanteringssystemet att märka det då utvecklaren försöker checka in sin version och förse utvecklaren med ett meddelande att hans version inte är uppdaterad. I så fall måste han sammanslå sin version av filen med versioner av filen som andra utvecklare har checkat in efter det att han börjat modifiera filen, förrän ändringarna kan
accepteras av versionshanteringssystemet. Sammanslagningen går till så att utvecklaren checkar ut versionerna som finns i repositoryt och antingen manuellt eller automatiskt sammanslår förändringarna i sin version av komponenten med versionen av komponenten som finns i repositoryt. Därefter då sammanslagningen är gjord kan utvecklarens version checkas in och en ny version skapas i repositoryt som innehåller allas förändringar. De flesta versionshanteringssystem använder denhär metoden för att möjliggöra parallell utveckling. Här kan nämnas Subversion och Concurrent Versions System (CVS)[BF03]. 4 Textbaserade versionshanteringssystem Idag är de flesta versionshanteringsprogram textbaserade. Programmena RCS, CVS och Subversion, vilka nämns i denhär texten, hör alla till denhär gruppen. Textbaserade versionshanteringssystem betraktar komponenterna som är under versionskontroll som text eller binära filer. Oftast används en rad som atomisk enhet i ett textbaserat system. Om textrader används som atomer betyder det att versionshanteringssystemet kan upptäcka gemensamma rader hos två parallella modifikationer av en komponent. Utöver gemensamma rader kan följande händelser upptäckas: rader som har blivit raderade, tillsatta rader, rader som har flyttats och modifierade rader. 4.1 Automatisk sammanslagning av versioner Om man endast jämför den senaste versionen i repositoryt med versionen som skall checkas in till repositoryt kan man endast identifiera vilka rader som skiljer sig mellan de två filerna. För att sammanslå filerna till en ny version måste utvecklaren manuellt välja hur filerna skall sammanfogas till en ny version. Denhär metoden kallas two-way merge eller översatt till svenska två-vägs sammanslagning. För att ett versionshanteringssystem skall vara så effektivt och användarvänligt som möjligt måste sammanslagningen av förändringar i versioner som skall checkas in till repositoryt automatiskt kunna sammanslås med versioner som redan existerar i repositoryt. Därför använder de textbaserade versionshanteringssystemena oftast en annan metod som kallas trevägs sammanslagning (three-way merge). I tre-vägs sammanslagning utnyttjar man informationen hos versionernas förälder vid sammanslagningen. Dethär gör att man kan automatisera en del situationer. Om t.ex. rad fem i en fil är lika i både föräldern och den ena versionen, men inte i den andra, kan man anta att
raden blivit modifierad i den andra versionen och därmed skall denna förändring tas med vid sammanslagningen av versionerna. På liknande sätt kan man hitta regler för de andra fallen som nämndes i introduktionen till textbaserade versionshanteringssystem. 4.1.1Konflikter Eftersom den atomiska enheten i textbaserade versionshanteringssystem är en rad kan inte modifikationer som görs på en och samma rad men i olika versioner sammanslås automatiskt. Dethär gäller också fallet där en utvecklare raderar en rad medan en annan modifierar samma rad. Situationer som versionshanteringssystemena inte klarar av att sammanslå automatiskt kallas konflikter. I en konfliktsituation behövs alltid ingrepp av en människa som gör beslutet om hur sammanslagningen skall göras. 4.1.2 Textbaserade versionshanteringssystemets begränsningar I undersökningar har man visat att tre-vägs radbaserade versionshanteringssystem kan klara av att automatiskt sammanslå 90 procent av förändringarna som görs under ett stort projekt [PSV98]. Trots det har textbaserade versionshanteringssystem sina begränsningar. Orsaken till de 10 procent som de textbaserade versionshanteringssystemena inte klarar av ligger oftast i att de inte förstår sig på syntaxen av filerna som lagras i dem. Till exempel situationer där en programmerare indenterar om ett antal rader kod för att göra koden läsbarare och en annan gör en modifikation av någon av raderna leder till en konflikt, fastän den ena programmeraren inte har ändrat på programmets funktion. Samma typ av konflikt kan åstadkommas genom att två programmerare modifiera en rad som endast innehåller en kommentar. Ett annat problem med textbaserade versionshanteringssystem är att de inte upptäcker konflikter som beror på komponenternas semantik. Om en programmerare modifierar en metods och dess parametrar och en annan lägger till ett anrop till metoden på en annan rad i koden kommer textbaserade versionshanteringssystem inte att upptäcka konflikten som introducerar ett fel i programmet. Ytterligare ett problem är att alla filer inte är textbaserade. Ordbehandlingsprogram t.ex. producerar ofta filer med en komplex struktur. Små logiska förändringar som man gör med ordbehandlingsprogrammet kan leda till att många rader av filen påverkas, vilket i sin tur leder till att det lätt uppstår konflikter. Dessa konflikter är mycket svåra om inte omöjliga att
lösa manuellt då man borde förstå sig dokumentenas struktur. För att klara av denhär typen av dokument ger en del versionshanteringssystem t.ex. CVS användaren möjligheten att ange att en fil är av binär typ. Då kommer varje ny version av filen att ersätta den gamla utan att några försök görs på att sammanslå förändringar med en tidigare version. Sammanfattning Mjukvaruprojekt är hela tiden utsatta för olika förändringar. Konfigurationsledningen består av aktiviteter som försöker kontrollera dessa förändringar så att de sker kontrollerat och inte introducerar fel i produkten som är under utveckling. Versionshantering är den del av konfigurationsledningen som lagrar komponenterna, som hör till ett mjukvaruprojekt, och alla versioner av dem. Versionshanteringen lagrar en komponents revisioner och varianter i ett repository. Revisioner beskriver hur en komponent har utvecklats medan varianter är alternativa implementationer som har motsvarande egenskaper och utvecklas parallellt. För att spara utrymme lagrar repositoryt endast en fullständig version och deltas med vars hjälp alla andra versioner kan räknas ut. En viktig uppgift som versionshanteringssystemena har är att stöda parallell utveckling. Dethär görs oftast genom en metod som kallas kopiera - modifiera sammanslå. Det går ut på att alla förändringar görs på en komponents kopia, som senare då förändringarna är gjorda sammanslås med versionen av komponenten som finns i repositoryt. Tre-vägs sammanslagning används ofta av versionshanteringsprogrammena för att automatisera sammanslagningen. Idag är de flesta versionshanteringssystem textbaserade med rader som atomiska objekt. Dethär tillåter utvecklare att arbeta parallellt med filer så länge de inte gör förändringar på samma rad. Vid modifikation av samma rad uppstår konflikter som måste lösas manuellt. Textbaserade system fungerar bra för filer som är textbaserade t.ex. programkod. Brister hos textbaserade system är att de inte förstår sig på dokumentenas syntax eller semantikvilket leder till problem med vissa filtyper där detta skulle vara viktigt. Binära filer leder också till en del problem. Det är en utmaning för framtiden att förse oss med versionshanteringssystem, som skulle vara lika accepterade som de textbaserade är idag och som även skulle klara av icke textbaserade filer.
Referenser [Ask99] Ulf Asklund, Distribuerad utveckling och Configuration Management, Lunds Tekniska Högskola 1999 [Bab86] Wayne A. Babich, Software Configuration Management : coordination for team productivity, Addison - Wesley 1986, ISBN 0-201-10161-0 [BF03] Moshe Bar and Karl Fogel, Open Source Developement with CVS 3 rd edition, Paraglyph Press 2003, ISBN: 1-932111-81-6 [CFP04] Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato, Version Control with Subversion: For Subversion 1.1, 2004 [CW98] Reidar Conradi and Bernhard Westfechtel, Version Models for Software Configuration Management, 1998, ACM 0360-0300/98/0600-0232 [Est00] Jacky Estublier, Software Configuration Management: A Roadmap, 2000 [Pre97] Roger S. Pressman, Software Engineering A Practitioner s Approach, McGraw-Hill 1997, ISBN 0-07-052182-4 [PSV98] D.E. Perry, H.P. Siy and L.G. Votta, Parallel Changes in Large Systems, 1998 [Tic82] Walter F. Tichy, Design, Implementation, and Evaluation of a Revision Control System, 1982, IEEE 0270-5257/82/0000/0058$00.75