^ Linux – Friheden til at programmere: Version 2.5.20050330 – 2020-12-31 ^|
| [[program:deklarativ|forrige]] | | [[program:vaerktoej-diff|næste]] |
----
==== Kapitel 5. Programmørens værktøjskasse ====
En programmørs værktøjskasse bør indeholde: * Et versionsstyringssystem. For eksempel CVS ([[program:vaerktoej#vaerktoej-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 (GLADE[[program:vaerktoej-glade|Afsnit 5.7]]).
* En kontrolstrukturplotter. Det kan for eksempel være Grasp
([[program:vaerktoej-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).
==== 5.1. Concurrent versioning system (CVS) ====
//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.
=== 5.1.1. CVS' funktionalitet ===
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.
=== 5.1.2. Daglig brug af CVS ===
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 , 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:hven%cvs add tak.htmlhven%cvs commit -m 'lidt almindelig høflighed' tak.html
* "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:hven%rm -f tjek-eksp.phphven%cvs remove tjek-eksp.phphven%cvs commit -m 'det gik ikke' tjek-eksp.php
* 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** ).
== 5.1.2.1. Konfliktløsning ved "dobbelt-opdatering" ==
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** ).
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** ).
== 5.1.2.2. Gamle udgaver af filer i CVS-arkivet ==
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
** .
== 5.1.2.3. Sætte huskemærker (tags) i CVS ==
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.
== 5.1.2.4. Filers status ==
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** .
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** 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/].
== 5.1.2.5. Logbogen ==
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:hven%cvs log tjek.php
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.
== 5.1.2.6. Forskelle mellem forskellige udgaver af en fil ==
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:hven%cvs diff tjek.php
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:hven%cvs diff -r 1.21 -r 1.22 vaerktoej-cvs.sgml
== 5.1.2.7. CVS med SSH på en alternativ port ==
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:Host cvs.saltholm.oresund.dk
Hostname skatkammeret.saltholm.oresund.dk
Port 4444
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
=== 5.1.3. Opsætning af CVS ===
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.
== 5.1.3.1. Oprettelse af et CVS-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:hven%cvs -d $HOME/.CVSROOT init
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.
== 5.1.3.2. Opret et projekt i CVS-arkivet ==
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):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
**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.
== 5.1.3.3. Få breve med log-meddelelser ved cvs commit ==
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.// 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
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:DEFAULT /usr/share/cvs/contrib/log -m tyge@hven.oresund.dk -f STI_TIL_CVS-RODEN/CVSROOT/commitlog
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.
=== 5.1.4. Forgreninger i udviklingen ===
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):hven%cvs rtag -b -r version0 gren1 sslugkode
Tilsvarende kunne man måske have en anden udvikler som skal
arbejde samtidig på en anden gren, "gren2":hven%cvs rtag -b -r version0 gren2 sslugkode
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 direktehven%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":hven%cvs update -r gren2
Endelig kan man skifte ud til hoved-sporet (komme ud af henholdsvis
"gren1" og "gren2" ved at skrive:hven%cvs update -A
== 5.1.4.1. Flette grene sammen igen ==
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:hven%cvs update -j TAG1 -j TAG2
Hvis man ikke var i "gren2", skal man først sikre at man er i
"gren2"-grenen:hven%cvs update -r gren2hven%cvs update -j TAG1 -j TAG2
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].
=== 5.1.5. Diverse med CVS ===
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:Compression yes
CompressionLevel 6
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.
----
| [[program:deklarativ|forrige]] | [[program:index|hjem]] | [[program:vaerktoej-diff|næste]] |
| Deklarativ programmering | | diff og patch |