wiki.smarken.dk

En programmørs værktøjskasse bør indeholde: * Et versionsstyringssystem. For eksempel CVS (Afsnit 5.1). I virkeligheden bør man bruge et

   versionsstyringssystem til alle projekter der varer længere end
   et par dage, eller har flere deltagende forfattere.

Foreløbig er det desværre et ret begrænset udvalg af

   versionsstyringssystemer vi omtaler her i bogen, men »[http://better-scm.berlios.de/comparison/comparison.html|Version
   Control System Comparison]« gennemgår ligheder og forskelle
   mellem 14 forskellige versionsstyringssystemer (ikke alle til Linux, og
   heller ikke alle Open Source).
* Et tekstbehandlingsprogram. For eksempel **vi** ([[program:vaerktoej-vi|Afsnit 5.15]]), Emacs ([[program:vaerktoej-emacs|Afsnit 5.14]]), Grasp ([[program:vaerktoej-grasp|Afsnit 5.16]], mest til Ada, C og C++), Anjuta
   ([[program:vaerktoej-anjuta|Afsnit 5.12]], bl.a. til C, C++, Perl, PHP,
   Python og SQL) eller KDevelop ([[program:vaerktoej-kdevelop|Afsnit 5.13]], bl.a. til Ada, Bash, C, C++, Perl, PHP,
   Python, Ruby og SQL).
* Et udskriftssystem. Det kan for eksempel være **a2ps** ([[program:vaerktoej-a2ps|Afsnit 5.17]]) eller
   det der er indbygget i Grasp ([[program:vaerktoej-grasp|Afsnit 5.16]]).
* Et fejlsøgningsværktøj (GVD[[program:vaerktoej-gvd|Afsnit 5.6]]eller
   gdb[[program:vaerktoej-gdb|Afsnit 5.5]])

Derudover kan det være praktisk med: * En brugergrænsefladebygger (GLADEAfsnit 5.7).

• En kontrolstrukturplotter. Det kan for eksempel være Grasp

(Afsnit 5.16) der kan bruges til at få en

   grafisk oversigt over kontrolstrukturerne i Ada-, C- og
   C++-programmer.
* Et oversættelseskontrolsystem.  Det kan for eksempel være GNU
   Make ([[program:vaerktoej-make|Afsnit 5.10]]) der kan bruges til at
   holde styr på hvilke filer det er på tide at opdatere
   (automatisk).

Og hvis du programmerer i C, C++ eller C#, vil du temmelig sikkert

også få brug for en læksøger.  Det kan for eksempel være **efence** ([[program:vaerktoej-efence|Afsnit 5.9]]).

Og det ideelle ville selvfølgelig være hvis man kunne få hele sin værktøjskasse integreret i ét

udviklingsmiljø.  Emacs ([[program:vaerktoej-emacs|Afsnit 5.14]]) er nok
det mest populære integrerede udviklingsmiljø til Linux.  I
standardopsætningen snakker Emacs fint med CVS og en utroligt bred
samling oversættere, samtidig med at det giver syntaksfremhævning og
sprogspecifikke genvejstaster til langt de fleste
programmeringssprog.  Det at Emacs grundlæggende er et tekstbaseret
program, generer vist en del mennesker, men på den anden side kan
Emacs bruges til så meget at man hurtigt kommer til at undre sig
over hvordan man kan klare sig uden.  Hvis du har valgt at
programmere i C++, er KDevelop ([[program:vaerktoej-kdevelop|Afsnit 5.13]])
et andet muligt valg af integreret udviklingsmiljø.  KDevelop er et
decideret grafisk udviklingsmiljø og ser en del smartere ud end
Emacs.  Desværre er det begrænset til programmering i C++.  Anjuta
([[program:vaerktoej-anjuta|Afsnit 5.12]]) er et nyt integreret grafisk
udviklingsmiljø.  Anjuta kan håndtere adskillige
programmeringssprog, men dog ikke nær så mange som Emacs (det er
vist også en svær opgave).

Concurrent versioning system (CVS) er et

versionsstyringssystem.  Dette er godt nok en programmeringsbog, men
i virkeligheden bør man bruge et versionsstyringssystem til alle
projekter der varer længere end et par dage eller har flere end en
enkelt deltagende forfattere.  Versionsstyringssystemets opgave er
at holde styr på de forskellige udgaver en fil har eksisteret i,
hvilke ændringer der er foretaget, hvorfor, og af hvem.  Der holdes
styr på dette i et centralt fælles //CVS-arkiv// ,
hvor alle ændringer registreres.  En af de ting der gør CVS til
noget særligt blandt versionsstyringssystemer, er at det tillader at
flere forfattere samtidig arbejder på de samme filer.  Så længe der
ikke er flere der retter i de samme linjer, vil CVS flette de
forskellige ændringer sammen efterhånden som de bliver lagt ind i
det fælles arkiv.

Versionsstyringssystemer som CVS er en nødvendighed for

udviklingsprojekter der – som for eksempel Linux – foregår spredt
rundt omkring i verden.  Antag at et firma eller universitet har
behov for at kunne arbejde med udvikling af programmer 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 udgivelser som altid kan genskabes (til serviceformål), mens
man samtidigt videreudvikler, og dermed har behov for at kunne bakke
tilbage gennem opdateringerne i tilfælde af fejl.

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 i gang 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 versionsstyringssystemer der benyttes.

Styring af softwareprojekter er svært! Specielt svært bliver det

når mange arbejder på den samme kildetekst, og hvor samtidigt
kommunikationen mellem projektdeltagerne er ringe eller besværlig.
De krav der må stilles til versionsstyringssystemerne i sådanne
projekter, er at alle ændringer let skal kunne tilgå andre på
projektet, alle ændringer skal kunne hives ud af kildeteksten 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 samme kildetekst uden at man bruger et versionsstyringssystem, 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 skal være muligt at opnå et
tilfredsstillende resultat.  En mulighed for at øge produktiviteten
er at gøre brug af et versionsstyringssystem.

CVS er et multi-platform versionsstyringssystem som har alt det man

kan ønske sig af et sådant system.  Det er frit tilgængeligt under
GNU-licensen (GPL).
Du kan læse mere om CVS på[http://www.linux.ie/articles/tutorials/managingaccesswithcvs.php|http://www.linux.ie/articles/tutorials/managingaccesswithcvs.php],[http://www.cvshome.org/docs/blandy.html|http://www.cvshome.org/docs/blandy.html],[http://www.ibiblio.org/mdw/REF/CVS-BestPractices/html/index.html|http://www.ibiblio.org/mdw/REF/CVS-BestPractices/html/index.html]eller[http://cvsbook.red-bean.com/cvsbook.html|http://cvsbook.red-bean.com/cvsbook.html].

CVS er et forholdsvis nyt versionsstyringssystem, og dets håndtering

af konflikter mellem forskellige udvikleres arbejde regnes for at
være unik.

CVS bruges til at gemme den historie som ens kildetekster (af den

 ene eller den anden slags) gennemløber.  Grundprincippet i CVS er
 at alle brugere har deres egen lokale kopi af kildeteksten 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 kopi af kildeteksten er stabil og
 fungerende, kan alle de opdaterede filer lægges ind i CVS-arkivet
 igen, eventuelt først efter at være blevet flettet sammen med andre
 udvikleres ændringer af de samme filer.  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å sin lokale kopi af
 kildeteksten, uden alvorlig risiko for at der opstår problemer når
 rettelserne lægges ind i det fælles arkiv.

CVS understøtter at arkivet (samlingen med

 versionsstyringssystemets information, inklusive kildeteksterne)
 kan gøres tilgængelig på nettet uden at man behøver at montere
 diske fra andre maskiner.  Almindeligvis anvendes **ssh** til at håndtere sikker udveksling af data
 mellem programmørernes maskiner og det centrale arkiv.

CVS udmærker sig ved at have et sæt af

 kommandoer til at pakke distributionen ud, at opdatere ens egen
 distribution med andres ændringer, at lægge ens egne ændringer i
 arkivet, 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 er værd at bemærke at

 tekstbehandlingsprogrammet Emacs automatisk vil bemærke det hvis
 du redigerer filer der ligger i et CVS-arkiv. Det vil så vise en
 ekstra menu der giver adgang langt de fleste af de daglige
 CVS-funktioner. Fra Emacs kan man bl.a. lægge filer ind i CVS,
 hente senere udgaver af de enkelte filer, og få sammenlignet
 forskellige udgaver af samme fil.

Hvis vi går ud fra at andre har taget sig af at lægge filerne fra

 et projekt du skal til at arbejde på i et CVS-arkiv (se[[program:vaerktoej#opsaet-cvs|Afsnit 5.1.3]], hvis du selv skal gøre det), er det
 forholdsvis enkelt at komme i gang.  Du skal blot kende CVS-arkivets
 adresse og projektets navn i arkivet.  De første tre af de følgende
 eksempler viser hvordan du går i gang med at arbejde med filer der
 ligger i et CVS-arkiv, afhængigt af hvilken form for adgang du har
 til det ([[program:vaerktoej#cvs-kom-i-gang-lokalt|Eksempel 5-1]],[[program:vaerktoej#cvs-kom-i-gang-anonym|Eksempel 5-2]]og[[program:vaerktoej#cvs-kom-i-gang-ssh|Eksempel 5-3]]).  Dernæst følger eksempler der
 viser hvordan du opdaterer din personlige kopi af arkivet ([[program:vaerktoej#cvs-kom-i-gang-update|Eksempel 5-4]]), hvordan du lægger rettede filer
 tilbage i det fælles arkiv ([[program:vaerktoej#cvs-kom-i-gang-commit|Eksempel 5-5]]), hvordan du tilføjer filer ([[program:vaerktoej#cvs-kom-i-gang-add|Eksempel 5-6]]), hvordan du sletter filer ([[program:vaerktoej#cvs-kom-i-gang-rm|Eksempel 5-7]]), og hvordan du lægger en rettet fil
 tilbage i det fælles arkiv direkte inde fra Emacs ([[program:vaerktoej#cvs-commit-emacs|Eksempel 5-9]]).

Eksempel 5-1. Gå i gang med at bruge et lokalt CVS-arkiv

hven%cvs \
-d /usr/local/CVSROOT checkout webspell

• “-d /usr/local/CVSROOT” betyder at det CVS-arkiv projektet skal

hentes fra, ligger i kataloget/usr/local/CVSROOTpå den maskine du

    arbejder på.
* checkoutbetyder at du vil have oprettet en kopi af et
    projekt der ligger i det førnævnte CVS-arkiv.
* Og endelig er "webspell" navnet på det projekt vi vil have en
    kopi af.

Eksempel 5-2. Anonym brug af et CVS-arkiv på nettet

hven%echo "update -dP" >> ~/.cvsrchven%cvs -d :pserver:anonymous@cvs.sf.net:/cvsroot/tuxpaint loginCVS password:(enter)hven%cvs -d :pserver:anonymous@cvs.sf.net:/cvsroot/tuxpaint checkout tuxpaintU tuxpaint/Makefile
U tuxpaint/README.txt
U tuxpaint/data/brushes/round_03.png
...hven%

Den første kommando er ikke strengt nødvendig, men sørger for at cvs automatisk henter nye underkataloger (og ikke kun dem man allerede har), når man senere

  opdaterer sin lokale kopi af CVS-arkivet.

Den næste kommando sørger for at »logge ind« på CVS-serveren. Det

  er kun noget man behøver gøre en gang for anonyme adgang til et
  CVS-arkiv.  Anonym adgang til et CVS-arkiv fungerer normalt med en
  blank adgangskode, så det er nok at taste <enter>, når **cvs** skriver »CVS password:«.

Den sidste kommando er den der henter en lokal kopi af CVS-arkivet ned,

  så du kan arbejde med filerne (også uden at have netforbindelse til
  CVS-serveren).

• “-d :pserver:anonymous@cvs.sf.net:/cvsroot/tuxpaint” betyder at

det CVS-arkiv projektet skal hentes fra, ligger i

    kataloget/cvsroot/tuxpaintpå maskinen
    "cvs.sf.net", og at du vil hente det som en anonym bruger.
* checkoutbetyder at du vil have oprettet en kopi af et
    projekt der ligger i det førnævnte CVS-arkiv.
* Og endelig er "tuxpaint" navnet på det projekt vi vil have en
    kopi af.  I dette konkrete tilfælde er det oversættelser af KDE
    (menutekster og brugsanvisninger) til forskellige sprog.

Eksempel 5-3. Brug af et CVS-arkiv på nettet over SSH

hven%export CVS_RSH=ssh

Denne kommando sætter en variabel der fortæller cvs at kommunikation over nettet skal kunne ske

  med SSH-protokollen (der er krypteret og dermed sikrer mod
  aflytning af adgangskoder og data).  Bemærk at variablen også skal
  være sat når du senere vil opdatere din kopi af projektet eller
  vil lægge en rettet fil ind i CVS-arkivet.  Det kan du hurtigt
  sikre med kommandoen **echo "export CVS_RSH=ssh" >>
  ~/.zshrc** .

hven%cvs \
-d tyge@cvs.sslug.dk:/usr/local/CVSROOT checkout linuxbog

• “-d tyge@cvs.sslug.dk:/usr/local/CVSROOT” betyder

at det CVS-arkiv projektet skal hentes fra, ligger i kataloget/usr/local/CVSROOTpå maskinen

    "cvs.sslug.dk", og at du vil hente det som brugeren "tyge".
* checkoutbetyder at du vil have oprettet en kopi af et
    projekt der ligger i det førnævnte CVS-arkiv.
* Og endelig er "linuxbog" navnet på det projekt vi vil have en
    kopi af.  I dette konkrete tilfælde er det hele bogserien "Linux
    – Friheden til at vælge".

Eksempel 5-4. Opdatér din personlige kopi af et CVS-arkiv

hven%cd webspell/hven%cvs update -d

• Du skal stå i kataloget med din lokale kopi

af CVS-arkivet for at kunne opdatere filerne. Ovenfor bliver

    det gjort med kommandoen **cd webspell** .
* Argumentet "update" betyder at du vil have //opdateret// den personlige kopi af et
    CVS-arkiv der allerede ligger i det katalog du står i.
    Argumentet "-d" gør at også nye underkataloger bliver opdateret.
    Tilføj yderligere "-C" hvis eventuelle egne rettelser skal
    overskrives af CVS-arkivets version.

Eksempel 5-5. Læg en rettet fil tilbage i det fælles CVS-arkiv

Vi antager nu at vi som efter forrige eksempel står i kataloget

  med den personlige kopi af CVS-arkivet, og at vi har rettet en
  HTML-syntaksfejl i filentjek.php.

hven%cvs commit \
-m 'validator.w3.org brokkede sig' tjek.php

• “commit” betyder at du vil kopiere din rettede udgave af en fil

ind i det fælles CVS-arkiv.

• “-m 'validator.w3.org brokkede sig'” betyder at rettelserne i

CVS-arkivets logbog skal have kommentaren “validator.w3.org

    brokkede sig".
* Og endelig er "tjek.php" navnet på den fil du har rettet og vil
    kopiere ind i det fælles arkiv.

Eksempel 5-6. Tilføj en ny fil til et CVS-arkiv

Hvis vi nu har skrevet en ny fil ved navn “tak.html”, og den ligger

  sammen med vores personlige kopi af projektet, kan vi tilføje den
  med kommandoerne:<code>hven%cvs add tak.htmlhven%cvs commit -m 'lidt almindelig høflighed' tak.html</code>

• “add” betyder at du vil føje din rettede udgave af en fil til

det fælles CVS-arkiv.

• Og endelig er “tak.html” navnet på den fil du har skrevet og vil

føje til det fælles arkiv.

• Efter at “tak.html” er blevet føjet til arkivet, bruges “cvs

commit” til at aktivere tilføjelsen.

Eksempel 5-7. Fjern en fil fra et CVS-arkiv

Vi har nu eksperimenteret lidt med en fil “tjek-eksp.php” og

  fundet ud af at der alligevel ikke er brug for den i projektet, så
  vi vil fjerne den fra den synlige del af CVS-arkivet (arkivet
  husker alle ændringer, så du vil stadig kunne gå tilbage til en
  udgave hvor filen fandtes).  Det klares med kommandoerne:<code>hven%rm -f tjek-eksp.phphven%cvs remove tjek-eksp.phphven%cvs commit -m 'det gik ikke' tjek-eksp.php</code>

• CVS vil ikke fjerne en fil fra arkivet hvis du stadig har en

kopi af den i din personlige kopi af CVS-arkivet, så vi starter

    med kommandoen **rm -f tjek-eksp.php** der
    fjerner filen fra kataloget.
* "remove" betyder at du vil fjerne filen fra det fælles CVS-arkiv.
* Og endelig er "tjek-eksp.php" navnet på den fil der skal fjernes
    fra det fælles arkiv.
* Efter at "tjek-eksp.php" er blevet slettet fra
    arkivet, bruges
    "cvs commit" til at aktivere sletningen.

Eksempel 5-8. Fjern et helt katalog i et CVS-arkiv

CVS er ikke ret god til at slette kataloger. Måden at håndtere

  sletning af hele underkataloger er at slette alle filer i 
  kataloget og derefter køre **cvs update -d -P** .
  Her vil-dgøre at kataloger opdateres med, og-Per at fjerne ("prune") tomme kataloger.

I nedenstående eksempel fjerner vimit_katalogsom er et underkatalog afprojekt.

hven%cd mit_kataloghven%lsCVS      Makefile    prg.c      prg.hhven%rm prg.c prg.h Makefilehven%cvs remove prg.c prg.h Makefilehven%cvs commit -m "Farvel til gamle filer"hven%cd ..hven%cvs update -d -P

Eksempel 5-9. Læg en rettet fil tilbage i det fælles arkiv direkte inde fra Emacs

Hvis du har rettet i en fil fra et CVS-arkiv i Emacs, kan du lægge

  den rettede fil tilbage i arkivet direkte inde fra Emacs.  Det kan
  for eksempel være praktisk hvis du løbende vil lave
  sikkerhedskopier af en rapport du er i gang med at skrive, så du
  uden problemer kan gå tilbage til tidligere udgaver af filen.  For
  at lægge filen tilbage i arkivet taster du førstCtrl-XVV.
  Hvis filen ikke allerede er gemt, får du nu mulighed for
  det. Dernæst kommer der et vindue i Emacs hvor du kan indtaste en
  bemærkning om de seneste ændringer. Når du har indtastet
  ændringerne, taster duCtrl-CCtrl-C, og så er filen lagt tilbage i CVS-arkivet.

Hvis forbindelsen til CVS-arkivet går over en SSH-forbindelse, vil

  du blive bedt om løsen eller adgangskode både før og efter du
  indtaster bemærkningerne til ændringerne.

Hvis det er en ny fil du vil oprette i CVS-arkivet, er det først

  anden gang du tasterCtrl-XVVat filen rent faktisk bliver lagt ind i arkivet.
  I første omgang bliver filen blot registreret (svarer til **cvs add** ).

Hvis der er konflikter mellem en fil i din personlige kopi af CVS-arkivet

  og den samme fil i det fælles CVS-arkiv fordi en anden bruger i
  mellemtiden også har opdateret filen, så vil du skulle flette de to
  opdateringer sammen før du kan lægge dine rettelser ind i det fælles
  arkiv. Det gøres ved at du først "opdaterer" din lokale kopi af filen
  ( **cvs update<filnavn>** ).
  CVS vil så markere forskellene mellem de to udgaver, så du i dit
  tekstbehandlingsprogram kan vælge hvilke udgaver af rettelserne du
  foretrækker. Når du har valgt mellem rettelserne og i øvrigt tjekket
  at filen er i orden, kan du lægge den sammeflettede opdatering ind i
  det fælles CVS-arkiv på sædvanlig vis
  ( **cvs commit<filnavn>** ).

Hvis en fil er blevet rettet i en helt forkert retning, er det muligt at

  hente en gammel udgave af filen ud af det fælles CVS-arkiv og arbejde
  videre ud fra den. Det gøres med kommandoen **cvs update -r
  <udgavenummer><filnavn>** .

Det kan være meget praktisk at kunne sætte et mærke på en fil for

  at man til hver en tid kan gå tilbage til netop den version af filen.
  For at sætte et mærke (engelsk "tag") kører man **cvs tag MÆRKE fil_liste** hvorMÆRKEer et navn (desværre må man ikke anvende mellemrum) a laefter_indfletning_af_SSLUG_kodeellerfoer_Peters_sommerferie.

Hvis man har brug for at gå tilbage til et givet mærke køres cvs update -r MÆRKE . Samme teknik anvendes også

  til at håndtere forskellige grene af koden.

Enhver kan og bør principielt tjekke status for de enkelte filer før

  opdateringer bliver lagt ind i det fælles arkiv. Det gøres med kommandoen **cvs status<filnavn>** .
  CVS vil så vise udgavenummeret for den fil du har liggende, såvel som
  udgavenummeret for den fil der ligger i det fælles arkiv.

Anvend tilsvarende cvs status -v<filnavn> til at få endnu mere information om filen inklusive forgreninger.

Tip: En meget effektiv måde at få styr på status for alle filer er at

  anvende **cvsstat** eller **cvschk** det kan findes på[http://cvs.sslug.dk/cvs2html/|http://cvs.sslug.dk/cvs2html/].

Hver gang du lægger ændringer ind i det fælles CVS-arkiv, kan du skrive

  en besked i logbogen om //hvorfor// du har lavet de
  ændringer. I[[program:vaerktoej#cvs-kom-i-gang-commit|Eksempel 5-5]]bruger vi
  kommandolinjeflaget "-m" til at angive teksten til logbogen. Hvis du ikke
  bruger "-m"-flaget, vil CVS i stedet starte det tekstbehandlingsprogram
  systemvariablen "EDITOR" peger på, så du kan skrive
  teksten der.

Hvis du på et tidspunkt vil se hvad der for eksempel står i logbogen

  om filentjek.php, bruger du kommandoen:<code>hven%cvs log tjek.php</code>

Den vil give dig en liste med de forskellige udgaver af filen, hvem der

  har lavet ændringerne, og hvad der står om dem i logbogen. Selve
  ændringerne bliver dog ikke vist.

Logbogen ( cvs log ) viser ikke selve ændringerne

  i en fil.  For at se dem skal man bruge tilvalget ''diff'' .  Den helt enkle brug af tilvalget ''diff'' er:<code>hven%cvs diff tjek.php</code>

der viser forskellene mellem den udgave aftjek.phpder ligger i CVS-arkivet og den der

  arbejdes med.

Hvis man vil se forskellene mellem to udgaver af en fil i

  CVS-arkivet, bruger man tilvalget ''-r'' til at
  identificere de to udgaver:<code>hven%cvs diff -r 1.21 -r 1.22 vaerktoej-cvs.sgml</code>

Hvis CVS-arkivet ligger på en maskine der står bag en dørvogter,

  eller hvis SSH af andre mystiske omstændigheder ikke kører på port
  22, er det lidt sværere at få **cvs** til at
  kontakte arkivet.  Problemet kan klares ved at man fortæller SSH
  hvilken port SSH kører på //uden// at fortælle
  CVS det. Det gør man i SSH's opsætningsfil$HOME/.ssh/confighvor man for eksempel kan
  tilføje:<code>Host cvs.saltholm.oresund.dk
 Hostname skatkammeret.saltholm.oresund.dk
 Port     4444</code>

hvilket betyder at når CVS – og dermed SSH – bliver bedt om at kontakte

  "cvs.saltholm.oresund.dk" (underforstået at det er på port 22), så vil SSH
  i virkeligheden kontakte "skatkammeret.saltholm.oresund.dk" på port
  4444.

Nu kan du altså kontakte CVS-arkivet bag dørvogteren ganske som i

  eksempel[[program:vaerktoej#cvs-kom-i-gang-ssh|Eksempel 5-3]]:

hven%export CVS_RSH=sshhven%cvs \
-d cvs.saltholm.oresund.dk:/usr/local/CVSROOT checkout hemmeligt_projekt

Endelig skal nævnes hvordan man opretter et fælles CVS-arkiv, og hvordan

 man lægger en samling filer ind i det fælles arkiv.

Hvis du ikke allerede har adgang til et CVS-arkiv, du kan lægge dine

  filer ind i, må du oprette et. Hvis du har systemadministratorrettigheder
  bør du oprette et katalog med navnet/usr/share/CVSROOTog lægge det der. Alternativt
  kan du for eksempel lægge det i$HOME/.CVSROOT.
  Det er vigtigt at alle der skal kunne lægge filer ind i og rette
  filer i CVS-arkivet, har adgang til at skrive i kataloget. Vi går her
  ud fra at de alle er med i brugergruppen "cvsusers" (se
  systemadministratorbogen for information om brugergrupper). CVS-arkivet
  oprettes med kommandoen:<code>hven%cvs -d $HOME/.CVSROOT init</code>

Når en bruger vil oprette sin egen arbejdskopi af CVS-arkivet, skal

  han/hun blot kende navnet på det katalog du valgte at lægge det fælles
  centrale CVS-arkiv i (husk at "$HOME" refererer til //dit// hjemmekatalog; **echo $HOME/.CVSROOT** vil give dig det fulde navn på
  det katalog der blev brugt i ovenstående eksempel). Se i øvrigt
  eksemplerne[[program:vaerktoej#cvs-kom-i-gang-lokalt|Eksempel 5-1]],[[program:vaerktoej#cvs-kom-i-gang-anonym|Eksempel 5-2]]og[[program:vaerktoej#cvs-kom-i-gang-ssh|Eksempel 5-3]]for flere detaljer. Vi kommer ikke
  ind på hvordan man giver anonym adgang til et CVS-arkiv her.

Lad os komme videre. For at du kan lægge dine filer i CVS for første

  gang, skal du flytte dig til hovedbiblioteket for kildeteksten (vi antager
  at det – og projektet – hedderwebspell, og at du
  oprettede CVS-arkivet som beskrevet i forrige afsnit) og importere
  filerne, fjerne filtræet og til sidst trække det ud af CVS-arkivet igen
  (denne gang //med// udgavehåndteringsinformation):<code>hven%cd webspellhven%cvs -d $HOME/.CVSROOT import webspell Tyge foerste-udgave-i-cvshven%cd ..hven%mv webspell webspell-før_cvshven%cvs -d $HOME/.CVSROOT checkout webspell</code>

Tyge er et felt der af CVS kaldes “vendor tag”

  (leverandørmærke), og **foerste-udgave-i-cvs** er et
  felt der af CVS kaldes "release tag" (udgavemærke).

Det kan også nævnes at en række ekstra værktøjer fås til CVS, se[http://freshmeat.net/|http://freshmeat.net/]under

  CVS. Et af disse er cvs2html der findes fra[http://cvs.sslug.dk/cvs2html/|http://cvs.sslug.dk/cvs2html/].
  cvs2html anvendes til at reformattere den loginformation 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 ved alle

  programmerings- eller skriveprojekter i øvrigt med mere end en person vil
  CVS tjene dette overhead ind i hundredefold.

Når flere folk arbejder sammen på et software-projekt, er det

  nødvendigt at man nemt kan se hvad andre personer har ændret i
  filerne. Med **cvs watch add FILNAVN** vil du
  modtage breve når andre kører **cvs commit
  FILNAVN** , men her vil du ikke se hvad de har ændret. Du
  kan få en bedre føling med ændringerne ved at bruge et lille
  programlogder følger med cvs. Med det
  program kan du få et brev om hvilke filer som er ændret, og du får
  også den log-meddelelse brugeren skrev, med i brevet. Hvis man
  inden for projektet holder en god stil med at skrive ordentlige
  log-meddelelser, så er dette super.

Lad os se på opsætningen af dette. Først skal du lave en logfil i

  CVSROOT-kataloget som alle deltagere i dit projekt kan læse og
  skrive. //I det følgende skal du erstatte
  STI_TIL_CVS-RODEN med den fulde sti til dit
  CVSROOT-katalog.// <code>hven%touch STI_TIL_CVS-RODEN/CVSROOT/commitloghven%chgrp PROJEKTGRUPPE STI_TIL_CVS-RODEN/CVSROOT/commitloghven%chmod g+rw STI_TIL_CVS-RODEN/CVSROOT/commitlog</code>

Dernæst skal vi rode i noget af de “helligste” af cvs-opsætningen.

hven%cvs -d STI_TIL_CVS-RODEN checkout CVSROOThven%vi CVSROOT/loginfo

Indsæt følgende linje til sidst hvistyge@hven.oresund.dkskal modtage breve. Er der flere

  som skal modtage breve, så tilføj gerne flere "-m modtager@maskine"
  efter hinanden:<code>DEFAULT /usr/share/cvs/contrib/log -m tyge@hven.oresund.dk -f STI_TIL_CVS-RODEN/CVSROOT/commitlog</code>

hven%cvs commit -m "Man kan modtage logbeskeder per post" CVSROOT/loginfohven%cvs release -d CVSROOT

De sidste linjer vil regenerere CVSROOT (sted hvor CVS-opsætningen

  er gemt), og derefter sletter man den CVSROOT-kopi man har tjekket
  ud.

Lad os se lidt mere på starten, da vi lavede projektet.

hven%cd MODUL_DIRhven%cvs -d STI_TIL_CVS-RODEN import MODUL VENDOR_TAG RELEASE_TAG

Dette genererer med det samme to grene (engelsk: “branches”) som

 man altid kan komme tilbage til.

* 1.1.1 – VENDOR_TAG

• 1.1.1.1 – RELEASE_TAG

Går man i gang med at tjekke filerne ud, rette og køre cvs commit , så kommer de enkelte versioner til at hedde

 version 1.1, 1.2, 1.3 osv.

Ofte vil alle bruge samme gren af filerne, men hvad gør man hvis

 man nu har brug for at kode et stykke tid på noget som lammer
 resten af udviklerne på samme projekt. I dette tilfælde kan man
 oprette en gren til dette – de andre udviklere kommer ikke til at
 se noget anderledes, og to adskilte udviklingsgrene kan køre.

Lad os antage at vi arbejder med et modul i CVS med navn

 "sslugkode" som er importeret i CVS ved at skrive **cvs
 import sslugkode start version0** . Da der ikke er nogen
 naturlig "vendor" sættes leverandør-tag blot til "start" og
 start-version til "version0".

For at skabe “gren1” ud fra hovedgrenen “version0” skriver man

 (uden at man nødvendigvis har koden tjekket ud):<code>hven%cvs rtag -b -r version0 gren1 sslugkode</code>

Tilsvarende kunne man måske have en anden udvikler som skal

 arbejde samtidig på en anden gren, "gren2":<code>hven%cvs rtag -b -r version0 gren2 sslugkode</code>

For at isolere sig selv i grenen “gren1” skrives:

hven%cvs -d STI_TIL_CVS-RODEN checkout sslugkodehven%cd sslugkodehven%cvs update -r gren1

eller direkte

hven%cvs -d STI_TIL_CVS-RODEN checkout -r gren1 sslugkode

Det normale er derefter at udvikleren retter, laver cvs commit som vanligt. Fordelen er at de andre udviklere

 ikke ser dette. Grenene er totalt afkoblede indtil der laves en
 "merge"

Hvis det skulle ske at vores udvikler fra “gren1” skal hjælpe ham

 som arbejder i "gren2"-grenen, så kan han lave **cvs
 commit** på egne filer og derfter skifte direkte over til
 "gren2":<code>hven%cvs update -r gren2</code>

Endelig kan man skifte ud til hoved-sporet (komme ud af henholdsvis

 "gren1" og "gren2" ved at skrive:<code>hven%cvs update -A</code>

Antag at to udviklingsgrene som hver for sig har udviklet sig, på

  et tidspunkt skal flettes sammen. Du har været så smart at du
  kørte **cvs tag TAG1** da du startede med din
  "gren1", og du har også gemt et mærke TAG2 ved slutningen af
  "gren1" – dvs. du har lige kørt **cvs tag
  TAG2** i "gren1".

I “gren2”-grenen kan du opdatere samtlige ændringer fra “gren1”-grenen

  mellem TAG1 og TAG2 ved at skrive:<code>hven%cvs update -j TAG1 -j TAG2</code>

Hvis man ikke var i “gren2”, skal man først sikre at man er i

  "gren2"-grenen:<code>hven%cvs update -r gren2hven%cvs update -j TAG1 -j TAG2</code>

Der er lidt mere information om emnet på[http://groups.yahoo.com/group/info-cvs/message/12246|http://groups.yahoo.com/group/info-cvs/message/12246].

Det kan nævnes at hvis Emacs indlæser en fil der er koblet ind i

 CVS, vil Emacs automatisk genkende dette og indsætte en ekstra
 menu, hvorfra du på enkel vis kan sende tilføjelser til den fælles
 database (selve ændringerne skal du ikke selv styre – det klarer
 Emacs og CVS).

Skal man anvende en “export” version til distribution, eller blot

 ikke ønsker at lave en "checkout", så er **cvs export
 PROJEKT** også en mulighed. Den henter kun filerne, men
 ikke CVS-informationsfilerne. Meget praktisk til at skelne mellem
 udgivelse af filer ("export") i forhold til udvikler-version med
 fuld CVS-information ("checkout").

Vi har tidligere vist at projekt/kildetekst hentes med:

hven%cvs STI_TIL_CVS-RODEN checkout projektnavn

Hvis man ser efter iprojekt-katalog/CVS, så

 finder man der tre filer som tilhører CVS:  * Repositoryindeholder projekt-navn på CVS-serveren.
* RootindeholderCVSROOTfor det
    pågældende projekt.
* Entriesindeholder listen over de filer og
    kataloger som er registreret i CVS.

Næste trick er for dem som anvender SSH til at kommunikere med CVS.

 Man kan få ssh til at understøtte komprimering i~/.ssh/config:<code>Compression      yes

CompressionLevel 6</code>

Men vær opmærksom på at visse servere ikke kan finde ud af at

 anvende komprimering, så er der uforklarlige problemer med at få
 forbindelse, så slå det fra.