Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Index   Calendar   Search
 

Revisionskontrolsystemet CVS

Ole Vilmann, (ov@danmar.dk), Dansk Maritimt Institut og SSLUG,
Peter Toft, (pto@sslug.dk), formand for SSLUG


Indledning

I denne artikel ses nærmere på revisions- og konfigurationskontrolsystemer. Emnet er helt nødvendigt for wide-area software samarbejde, som er en af grundpillerne i udviklingen af operativsystemet Linux. Antag, at et firma eller universitet har behov for at kunne arbejde med udvikling af software på kryds og tværs af geografi, hvor al kommunikation skal ske via internettet. To spørgsmål melder sig hurtigt til systemadministratoren: Hvad med sikkerheden og hvordan kan man styre softwareudviklingsprocessen, når der er mange mennesker involveret, på en sådan måde at man kan lave releases som altid kan genskabes (til service formål), mens man samtidigt videreudvikler, og dermed har behov for at kunne bakke tilbage i revisionerne i tilfælde af fejl. Emnet omkring sikkerhed beskrives i en Unix artikel i et af de kommende numre af DKUUG-Nyt, mens revisionshåndteringen beskrives i denne.


Baggrund

De fleste danske og udenlandske softwarefirmaer har foretaget deres udvikling baseret på udvikling i lokale netværk. Med den fortsatte ekspansion af udviklingen af internettet og med den fortsatte udvikling, hvor begreber som "hjemmearbejdsplads" og "distancearbejde" dukker op oftere og oftere, må det forventes at softwareudviklingsfirmaer allerede er igang med og i endnu højere grad vil foretage udviklingen af software baseret på utroligt mange computere bundet sammen af internettet. Dette stiller store krav til de revisions- og konfigurationskontrolsystemer, der benyttes.

Styring af software projekter er svært ! Specielt svært bliver det når mange arbejder på den samme kode, og hvor samtidigt kommunikationen mellem projektdeltagerne er ringe eller besværlig. De krav, der må stilles til revisionskontrolsystemerne i sådanne projekter er, at alle ændringer let skal kunne tilgå andre på projektet, alle ændringer skal kunne hives ud af koden igen, og man skal kunne se hvem der har lavet hvad på hvilket tidspunkt.

Når man en gang har prøvet at være to eller flere som fysisk retter i sammen kode, uden af man bruger et revisionskontrolsystem, er det indlysende at denne form for samarbejde er uproduktiv. På sådanne præmisser er megen kommunikation og dermed megen uproduktiv tid nødvendig, hvis det overhoved skal være muligt at opnå et tilfredsstillende resultat. En mulighed for at øge produktiviteten er at gøre brug af et revisionskontrolsystem.


Revisionskontrolsystemer

Der findes mange forskellige revisionskontrolsystemer i brug idag. I Unix verden har de mest anvendte været RCS (Revision Control System) og SCCS (Software Configuration Control System) som enten begge eller den ene af disse er del af standard softwaren på kommercielle Unix systemer. Indenfor Windows 3.11, Windows 95 og Windows NT verdenen findes der endnu flere, hvor en af de mest kendte er Microsoft Visual Source Safe (VSS). Disse revisionskontrolsystemer opfylder de fleste krav til den ønskede funktionalitet af et revisionskontrolsystem.

RCS og SCCS er bedst når man gennem flere år har fundet en arbejdsgang og har opbygget et bibliotek af shell scripts så den valgte arbejdsgang er implementeret igennem dette script bibliotek. RCS og SCCS i sig selv nærmer sig assembler programmering i sammenligning med CVS og nogle af de kommercielle produkter der findes. RCS og SCCS må samtidigt siges at høre Unix verden til og er beregnet til brug ved udvikling i et lokalt miljø hvor diske kan mountes uden sikkerhedsmæssige problemer. Der findes enkelte porteringer af RCS til Windows verden, såvidt vides.

For VSS er sagen en ganske anden. VSS er et fuldt moderne revisionskontrolsystem og fås også til diverse Unix platforme. VSS kan også benyttes til revisionshåndtering over store netværk (læs internettet). Det bør dog bemærkes, at VSS er rimeligt dyrt til Windows platformen, og endnu meget dyrere til Unix systemerne.

Et godt alternativ til de ikke tidssvarende Unix revisionskontrolsystemer og så Windows systemer er CVS (Concurrent Versions System). CVS er et multi-platform revisionskontrolsystemer som har alt det man kunne ønske sig af et sådant system. CVS er et af de systemer der er frit tilgængelige beskyttet under GNU license (GPL).

CVS findes som source kode i version 1.9 og kan også findes som oversatte programmer til de mest gængse Unix systemer på http://prep.ai.mit.edu/pub/gnu (og alle dens mirrors), samt til Windows 95 og Windows NT platformen, se http://www.cygnus.com/misc/gnu-win32 og ftp://ftp.cc.utexas.edu indeholdt i congruent's gnubin.tar.Z som CVS 1.3.

CVS er et nyere revisionskontrolsystem som oprindeligt er opstået som en række shell scripts baseret på RCS. Personen der havde denne store samling af shell scripts, Dick Grune, offentliggjorde disse shell scripts på USENET gruppen comp.sources.unix engang tilbage i 1986. Idag er hele CVS bygget op fra bunden i C, men det er stadig Dick Grunes ide omkring konfliktløsning der er en af hjørnestenene i CVS.

Rygterne vil vide, at Thinking Machine Coorporation (kendt for massivt parallelle supercomputere) benyttede CVS til revisionshåndtering. Thinking Machine Coorporation var aktive i udviklingen af CVS og den FAQ der findes idag er stadig et levn fra den tid.

Designet og implementeringen af CVS er blev udført af Brian Berliner i nogle tilfælde sammen med andre.


Funktionaliteten af CVS

Versionskontrolsystemer bruges til at gemme den historie som ens kildetekster (af den ene eller den anden slags) gennemløber. De fleste versionskontrolsystemer giver endvidere mulighed for at pakke (komprimere) kildekoden i versionskontrolsystemets database (repositorie). Endvidere benytter langt de fleste systemer sig af at kun gemme forskelle mellem versionerne.

Grundprincippet i CVS er, at alle brugere har deres egen version af koden, som kan modificeres uafhængigt af andre brugere. Dette kan ske med brugere på samme maskine eller på maskiner placeret vilkårligt langt fra hinanden. Når ens personlige distribution af koden er stabil kan distributionen med ændringerne lægges ind i CVS repositoriet eller sammensmeltes med de ændringer andre har lavet siden man pakkede distributionen af koden ud. På denne måde kan man uden at begrænse andre i deres arbejde, udføre meget arbejde (lang tids arbejde og/eller mange ændringer) på distributionen af koden, uden at der opstår problemer med sammensmeltningen af de lokale distributioner af koden.

CVS understøtter at repositoriet (samlingen af revisionskontrolsystemets informationer inklusivt kildetekster) kan lægges på nettet uden at man behøver at mounte (share) diske. Almindeligvis anvendes remote shell (rsh) eller secure shell kald mellem maskinerne til udveksling af kildetekster.

CVS udmærker sig ved at have et intuitivt let forståeligt sæt af kommandoer til at pakke distributionen ud, at opdatere ens egen distribution med andres ændringer, at lægge ens egne ændringer i repositoriet, at lave sideløbende grene af udviklingen af produktet, at samle sideløbende grene af udviklingen, at hente information om historien af ændringer osv.

Det CVS mangler i forhold til nogle af de kommercielle er en "slick" multi-platform GUI. Et stort plus er dog, at Emacs automatisk vil genkende, at filerne er lagt ind i CVS, og en ekstra menu giver langt de fleste af de daglige funktioner. Fra Emacs kan man bl.a. lægge filer ind i CVS, hente senere version af de enkelte filer, og få step-vis sammenligning af to versioner af kildekoden.


Brugen af CVS

Antag at CVS er sat op og koden er lagt ind i CVS (hvordan dette gøres vises senere). Koden kan være lagt i et bibliotek eller mange. Hyppigt vil man anvende flere biblioteker under et fælles start punkt, men dette er ikke nødvendigt.
Til at starte laves

cvs checkout REPOSITORYNAME

hvor "REPOSITORYNAME" er et navn som man selv har given den samling kode, f.eks. signaltoolbox eller lignende. Man vil se, at alle biblioteker som CVS kontrollerer har et nyt underbibliotek med navnet CVS, som indeholder en smule databaseinformation, men ellers er der intet specielt med koden.
Antag at man laver en ændring af koden som så skal kunne tilgå de andre på projektet. Dette gøres ved at skrive

cvs commit FILENAME

hvor "FILENAME" er den fil man har rettet i. Dette starter automatisk brugerens default teksteditor, hvor man kort skriver, hvad der er blevet ændret, og denne log information gemmes med filen. Hvis filnavnet undlades vil CVS lægge alle ændrede filer ind i CVS. Nu kan de andre på projektet få den nye kode ved at skrive

cvs update FILENAME

Og igen kan FILENAME udelades og de filer som ikke er ajour, vil blive opdateret. Bemærk, at dette ikke sker automatisk, men først når man selv vil det. På denne måde gøres det til et særskilt operation at få opgraderes koden, hvor man må lægge mærke til hvilke ændringer som er foretaget. CVS kan også automatisk sende en email ud til projekt gruppen når filer bliver opdateret, så man ved hvornår dette sker (anvend cvs watch).

Hvis der er konflikter mellem den lokale kode og den kode som er senest i CVS databasen, må den som har konflikten løse den (måske med hjælp fra den som lavede ændringen) og lægge endnu en version ind hvor problemet er løst. Faktisk foregår denne proces langt mere smidigt end man skulle tro, og med en smule styring af hvem der laver hvad, så vil man finde meget få problemer med projektstyringen. Hvis koden er blevet meget ødelagt ved f.eks. en helt forkert kodeændring, så er der mulighed for at bakke tilbage til en ældre version af koden (cvs update -r REVISIONNUMBER FILENAME), hvorfra der arbejdes videre.

Enhver kan og bør checke status for den enkelte fil før koden skal lægges ind i CVS databasen. Dete gøres med

cvs status FILENAME

Dette vil vise versionsnummer på egen fil og det versionsnummer som CVS har. Et felt for hver fil vil vise om andre har committet kode, eller om filen lokalt er ændret i forhold til CVS databasen.
Nye filer lægges ind i CVS med to operationer, først

cvs add FILENAME

efterfulgt af

cvs commit FILENAME

På denne måde er der en ekstra sikring imod at forkerte filer kommer i CVS databasen.
Tilsvarende kan filer fjernes fra CVS databasen med

cvs remove FILENAME

efterfulgt af

cvs commit FILENAME

Hver af disse "cvs commit" ordrer vil starte en editor op, hvor brugeren skal skrive (kortfattet) hvilke ændringer der er lavet siden sidst. Dette skaber en log historie for hver fil som er guld værd, hvis man er lidt væk fra koden og skal arbejde videre senere. For at se alle beskeder for en fil i loggen anvendes

cvs log FILENAME

hvilket vil vise, hvem der har lavet de enkelte versioner og hvad der i korte træk er sket (se også sidst i artiklen om CVS2HTML). Selve kode ændringerne vises ikke her. Disse fås ved at skrive

cvs diff FILENAME

og her kan et revisionsnummer tilføjes, så man kan se, hvordan den lokale kode afviger fra koden med den valgte revision.
Endelig skal nævnes hvordan man lægger et kodetræ ind i CVS databasen. Lav cd til hovedbiblioteket for koden. Derfra laves

cvs import REPOSITORYNAME VENDORTAG RELEASETAG

hvor REPOSITORYNAME (se checkout) er et beskrivende navn for kode samlingen. VENDORTAG er en streng som beskriver den som koden kom fra og RELEASETAG er en streng som beskriver koden status nu. Tit har disse ikke stor betydning og kan begge sættes til f.eks. "start".
Når koden er lagt ind i CVS databasen skal den fjernes (ja fjernes) og der laves en CVS checkout for at få gendannet kodetræet incl. de ekstra CVS biblioteker som skal være der.

Det kan også nævnes at en række ekstra værktøjer fås til CVS, se http://www.loria.fr/~molli/cgi-bin/wilma.cgi/rel. Et af disse er CVS2HTML, der findes fra http://www.sslug.dk/cvs2html. CVS2HTML anvendes til at reformattere den log information, der er skrevet ind for hver fil ved "cvs commit", til HTML filer. For internetbaserede samarbejdsprojekter er dette virkeligt smart.

Det tager et par timer at komme ind i denne måde at arbejde på, men alle kodearbejder med mere end en person vil CVS tjene dette overhead ind i hundredefold.

 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2004-03-07, 21:25 CET .
 

Denne side vedligeholdes af Peter Toft (<pto@sslug.dk>)