CVS-kræsjkurs ============= CVS er et mye brukt versjoneringssystem for kildekode. Det kan også nyttes til andre typer filer enn kilde. Systemet støtter flere samtidige utviklere ved å la hver enkelt utvikler arbeide mot en lokal avspeiling av det såkalte CVS- repositoriet og deretter flette resultatene av arbeidet tilbake i CVS-treet. I faget I122 bruker vi CVS for å nyttiggjøre oss av historikk-funksjoner (man kan enkelt bla seg tilbake for å se hvordan kilden så ut på et tidligere tids- punkt) og for å legge til rette for parallellutvikling mellom flere grupper av utviklere. 1. Hente ut det eksisterende kildetreet --------------------------------------- For å hente ut den eksisterende kilden må man gi CVS en peker til det såkalte repositoriet. Vårt repositorium ligger under /Home/user/KURS/I122. Den enkleste måten å gjøre CVS oppmerksom på dette på, er å skrive setenv CVSROOT /Home/user/KURS/I122 hvis man bruker csh (som er standarden på Undervisningsanlegget), eller export CVSROOT=/Home/user/KURS/I122 under (ba)sh, som er de to mest brukte skallene under UNIX-aktige system. Andre kommandoskall vil ha lignende syntaks som de nevnte skallene. De videre- komne vil være interessert i å merke seg at CVS er svært nettbevisst og gjerne lar deg arbeide mot et CVS-repositorium på en annen maskin; i så fall kan du oppgi CVSROOT på følgende form: [[brukernavn@]maskinnavn:]sti CVSROOT vil som standard prøve å bruke den gamle og gebrekkelige RSH- protokollen, og det er ikke mulig på II sine maskiner. Sett istedet variabelen CVS_RSH til "ssh", så bruker CVS SSH. Det kan da være en fordel å ha bruke autentisering med offentlige nøkler og en nøkkelagent, men det er en annen historie. Man henter deretter ut repositoriet ved å gi CVS kommandoen "checkout" og navnet på en modul. (Ett CVS-repositorium kan utmerket godt inneholde flere moduler.) Vår modul heter i122 (merk liten i), så kommandoen blir som følger: cvs checkout i122 (De fleste CVS-kommandoer kan forkortes. "checkout" forkortes simpelthen "co".) Denne kommandoen henter ut et komplett katalogtre med nyeste versjon av alle kildefiler, akkompagnert av en kakofoni av skjerm-output som viser hvilke filer som undersøkes og oppdateres. Denne operasjonen er ganske idiotsikker, men hvis det oppstår en feil, skyldes den mest sannsynlig at du ennå ikke er registrert som I122-student. Send mail til Magne og si fra hva som har skjedd hvis dette er tilfelle. Nå har du hentet ned kilden, og kan godt hoppe av dette kræsjkurset inntil videre og begynne å sette deg inn i den :) 2. Forfriske kildetreet ----------------------- Hvis andre har gjort endringer etter at du hentet ned kildetreet, vil din lokale kopi være usynkronisert. Løsningen på dette er selvfølgelig å oppdatere kildekoden, og CVS lar deg gjøre dette med kommandoen cvs update (forkortet "cvs up"), som inspiserer lokale filer og prøver å forene dem med filer i repositoriet. Filer som du ikke har forandret, men som er blitt oppdatert i repositoriet, overskrives med nyeste versjon. Filer som du selv har forandret, men som ingen har sjekket inn nye utgaver av, står urørte. Filer som er blitt forandret både i repositoriet og lokalt hos deg vil bli forsøkt flettet (ikke en garantert vellykket operasjon); se "Fletting" under for noen nyttige tips om fletting. 3. Legge arbeidet ditt inn i CVS -------------------------------- Etter at du har gjort såpass med endringer at du kan si deg fornøyd, er det på tide å legge endringene inn i CVS-treet så de blir synlige for andre og kan spores. Hvis du simpelthen har redigert eksisterende filer, og disse ikke samtidig er blitt modifisert av andre, er oppgaven enkel; du kan simpelthen skrive cvs commit ("cvs ci"), og CVS bekrefter at filene er blitt lagt inn i repositoriet. CVS vil be deg skrive en liten logg-oppføring som legges inn sammen med fila; dette skal være en svært konsis melding om hva som er blitt gjort siden sist. CVS starter en egen editor for å skrive loggoppføringen, og dette kan være avskrekkende hvis du ikke har tatt dine forholdsregler -- CVS starter nemlig som standard editoren "vi". Hvis du ikke føler deg vel med vi, kan du med fordel enten sette miljøvariabelen CVSEDITOR til en editor du kjenner godt, eller foregripe begivenhetens gang ved å gi opsjonen "-m 'Dette er en melding'" etter "cvs commit". Det er tre haker ved denne operasjonen. For det første vil CVS kun sjekke inn filer som "har en versjon", altså at CVS eksplisitt er blitt fortalt at fila ikke er søppel. Gjør dette med kommandoen cvs add filnavn og påse at fila blir lagt inn neste gang du sjekker inn filer. CVS vil dessuten nekte å sjekke inn en katalog hvis det finnes utdaterte filer under denne katalogen; løs problemet enten ved å eksplisitt oppgi navnet på fila som skal sjekkes inn, eller ved å gjøre en "cvs update" først. Den tredje eventualiteten er at fila er blitt forandret samtidig med du selv forandret den, og at den eller de andre som arbeidet på den sjekket den inn før deg. I så fall må du gjøre fletting -- en operasjon som har fått sitt eget avsnitt under. 4. Fletting og forgreining -------------------------- Hvis du forsøker å legge inn en fil som er blitt endret av deg selv samtidig som andre har lagt inn en ny versjon, blir du nødt til å gjøre fletting. I visse tilfeller rapporterer CVS at det selv klarte å gjøre flettingen, men som oftest vil du bli nødt til å inspisere fila selv. For å effektuere en fletting, må du først kjøre en "update" for å få de nye opplysningene fra arkivene inn i din lokale kopi. Etter dette kommer fila til å inneholde noen nye, lett gjenkjennelige linjer som gjerne ser slik ut: <<<<<<< Dette er linjer som ble lagt til i arkivet etter at du sjekket ut din lokale kopi. ======= Her kommer noen linjer som skiller seg ut fra linjene over, og som du skrev inn i den lokale kopien mens arkivet ble endret. >>>>>>> 1.3 Poenget er selvsagt å velge ut de linjene som skal fortsette å være i arkivet. Etter at du er fornøyd med utseendet på fila, er det bare å prøve å sjekke den inn på nytt. I noen tilfeller er endringene så omfattende at CVS ikke tar noen sjanser, men inkluderer begge versjonene i sin helhet, fortsatt på samme format som vist over. Fletting brukes også når du forgreiner kildetreet. Under vanlig bruk vil CVS legge inn kode langs en rett linje, der versjoner følger umiddelbart etter hverandre. Forgreining vil si at du tar en eksisterende versjon og starter en ny slik koderekkefølge -- en ny grein. Forgreining kan brukes hvis en forfølger det samme prosjektet langs ulike linjer, for eksempel at en raffinerer statisk kode langs kodegreina og legger til eksperimentell kode langs en parallell grein. Det kan også brukes når en ønsker å la ulike utviklergrupper arbeide uavhengig av hverandre, med det formål for øye å til slutt flette disse inn i hverandre. La oss anta at du allerede har sjekket ut kildetreet, og at dette er à jour med arkivet. Motivet for å forgreine på dette punktet er å effektivisere nettverkskoden mens resten av utviklergruppa legger til nye funksjoner. Skriv cvs tag -b nettverk-1 og CVS gir kilden din en såkalt branch-tag. Revisjonsnummeret ditt inneholder plutselig to ekstra ledd på enden -- for eksempel vil første forgreining ut fra revisjon 1.4 få revisjonsnummer 1.4.1.1. CVS vil nå vite å holde koden din adskilt fra hovedgreina, og du kan jobbe som om kildetreet ditt var adskilt fra resten. Andre utviklere kan hente ut greina di ved å skrive cvs checkout -r nettverk-1 eller gå fra en annen grein til din med cvs update -r nettverk-1 Den siste biten av puslespillet er å flette greiner sammen igjen. Dette gjør du ved å ta utgangspunkt i en revisjon på den greina som du vil flette inn i -- vanligvis nyeste revisjon på hovedgreina. Last nå inn den revisjonen som skal flettes inn med opsjonen -j ("join") og navnet på greina. Hvis vi for eksempel har arbeidet med fila "nettverk.java" i sidegreina og vil ha denne inn på hovedgreina, skriver vi (med utgangspunkt i siste revisjon på hovedgreina) cvs update -j nettverk-1 nettverk.java og CVS vil legge endringene fra sidegreina inn i den eksisterende kildefila. Rediger fila som resulterer fra dette i henhold til anvisningene over (dvs. at du velger ut det du er interessert i), og sjekk inn fila med "commit". Flettingen skal nå være gjennomført! 5. Andre småting ---------------- Det kan være nyttig å titte på CVS-loggen når man gjør slektsforskning på kildefiler. I tilfelle du ikke allerede har gjettet det, er kommandoen "cvs log filnavn". Filer kan fjernes fra repositoriet med kommandoen "cvs remove" (i beste UNIX-stil forkortet "rm"). CVS lar deg kun gjøre dette med filer som allerede er slettet fra repositoriet. For sikkerhetsformål nevner jeg også at dette ikke sletter en fil fullstendig, men snarere plasserer den i det såkalte CVS-loftet. Du må gå manuelt inn i repositoriet og fjerne fila for at den skal forsvinne helt. CVS forstår seg ikke på flytting og omdøping av filer. Disse operasjonen må effektueres ad omveier, ved å kopiere de aktuelle filene til de nye plasseringene, fjerne de gamle filene (med "rm" og "cvs rm") og så legge til de nye filene med "add". Den samme operasjonen på hele kataloger med gjøres med litt mer omhu, men med stort sett den samme framgangsmåten. Systemet lar deg heller ikke manuelt fjerne kataloger, selv om du har slettet dem og kaller opp "cvs rm". I CVS-metaforen er kataloger kun noder i et tre -- ikke filer i sin egen rett -- og skal beskjæres etter behov. Kall "cvs commit" og "cvs update" med svitsjen -P for å be CVS om automatisk å beskjære tomme kataloger. Filer i ikke-tekstlige format bør behandles med litt omtanke i CVS. Binærfiler (PDF-dokument, ferdig kompilert bytekode, bildefiler osv.) bør "add"-es med svitsjene "-kb", f.eks. "cvs add -kb ikon.png". Å bla seg bakover i revisjoner gjøres best ved å sjekke ut et separat kildetre. For å undersøke tilstanden på en gitt dato (det anbefalte, siden revisjonsnummer sjelden stemmer overens med hverandre på tvers av filer), gir du bare opsjonen "-D ååååmmdd" til "checkout", f.eks. "cvs checkout -D 20020101 i122". CVS kan instrueres til å sette inn revisjonsinformasjon i selve kildefilene. Disse oppdatere automatisk. Hvis du for eksempel legger til linja /* $Author$, $Date$ */ vil kildefila alltid vise hvem sist arbeidet på den og når. Dette kan være hjelpsomt for å holde orden på revisjonsinformasjon; CVS kan tilmed hjelpe deg med å holde orden på Javadoc hvis du bruker nøkkelordene fornuftig. Legg merke til at informasjonen omsluttes av kommentarsymboler; du ønsker deg antagelig ikke at CVS skal substituere inn i faktisk Java-kode. CVS har et uhorvelig antall funksjoner som er for plasskrevende å nevne her; skulle man være interessert i disse, kan man begynne med å skrive "info cvs" i et terminalvindu. Her ser du blant annet en komplett liste over nøkkelordene nevnt over.