CVS beheert een historie van een sourcetree, uitgedrukt in een serie wijzigingen. Het bestempelt iedere wijziging met de tijd dat het werd gemaakt en de naam van de gebruiker die het maakte. Bovendien voorziet de persoon die dit deed, de wijziging ook van wat tekst, welke beschrijft waarom de wijziging werd gemaakt. Gegeven die informatie, kan CVS ontwikkelaars helpen om vragen beantwoord te krijgen zoals:
Laten we eerst de essentiële CVS commando's eens bekijken, voordat we te veel vage termen en concepten gaan bespreken.
CVS neemt de wijzigingen van iedereen in een gegeven project in een
directory-structuur genaamd repository op.
Voordat je CVS kunt gebruiken, moet je de omgevingsvariabele
CVSROOT instellen naar het path van de repository. Degene
onder wiens toezicht het configuratiebeheer van het project staat, zal
weten welke dit is; misschien is er ergens een globale definitie voor
CVSROOT.
In ieder geval staat de CVS repository op ons systeem in `/u/src/master'. In dat geval zou je de volgende commando's in moeten voeren
setenv CVSROOT /u/src/master
als je shell csh of een afgeleide daarvan is, of
CVSROOT=/u/src/master export CVSROOT
als je shell Bash of een andere Bourne shell variant is.
Als je dit vergeet, zal CVS een foutmelding produceren, wanneer je het probeert te gebruiken:
$ cvs checkout httpc cvs checkout: No CVSROOT specified! Please use the `-d' option cvs [checkout aborted]: or set the CVSROOT environment variable. $
CVS werkt niet op gewone directory-structuren; je moet binnen een directory
werken die CVS voor je heeft aangemaakt.
Net als wanneer je een boek uit de bibliotheek uitcheckt voor je het naar
huis meeneemt om het te lezen, gebruik je het commando
cvs checkout om een directory-structuur van CVS te krijgen voor je
er aan gaat werken. Bijvoorbeeld: stel dat je aan het project werkt genaamd
httpc, een
alledaagse HTTP client:
$ cd $ cvs checkout httpc cvs checkout: Updating httpc U httpc/.cvsignore U httpc/Makefile U httpc/httpc.c U httpc/poll-server $
Het commando cvs checkout httpc betekent, "Haal de source tree
met de naam httpc op vanuit de repository aangegeven door de
omgevingsvaribele CVSROOT."
CVS plaatst de structuur in een subdirectory met de naam `httpc':
$ cd httpc $ ls -l total 8 drwxr-xr-x 2 jimb 512 Oct 31 11:04 CVS -rw-r--r-- 1 jimb 89 Oct 31 10:42 Makefile -rw-r--r-- 1 jimb 4432 Oct 31 10:45 httpc.c -rwxr-xr-x 1 jimb 460 Oct 30 10:21 poll-server
Van deze bestanden zijn de meeste je werkkopieën van de httpc sources.
De subdirectory met de naam `CVS' (bovenaan) is echter anders.
CVS gebruikt het om extra informatie over de bestanden in die directory
op te nemen, als hulp bij het vaststellen van de wijzigingen die je hebt
gemaakt, sinds je het ophaalde.
Zodra CVS een werkdirectory heeft aangemaakt, kun je de bestanden die erin staan op de gebruikelijke wijze wijzigen, compileren en testen -- het zijn gewoon bestanden.
Stel bijvoorbeeld dat we het package dat we zojuist hebben opgehaald, gaan proberen te compileren:
$ make gcc -g -Wall -lnsl -lsocket httpc.c -o httpc httpc.c: In function `tcp_connection': httpc.c:48: warning: passing arg 2 of `connect' from incompatible pointer type $
Het lijkt erop dat `httpc.c' nog niet naar dit besturingssysteem is
overgedragen. We zullen één van de argumenten aan connect moeten
toewijzen. Om dat te herstellen, moet regel 48 worden gewijzigd van:
if (connect (sock, &name, sizeof (name)) >= 0)
in dit:
if (connect (sock, (struct sockaddr *) &name, sizeof (name)) >= 0)
Nu zou het gecompileerd moeten kunnen worden:
$ make gcc -g -Wall -lnsl -lsocket httpc.c -o httpc $ httpc GET http://www.cyclic.com ... HTML text for Cyclic Software's home page follows ... $
Aangezien iedere ontwikkelaar zijn eigen werkdirectory gebruikt, zijn de
gemaakte wijzigingen aan je werkdirectory niet automatisch zichtbaar voor
de andere ontwikkelaars in je team. CVS publiceert je wijzigingen niet
totdat je zover bent. Als je klaar bent met het testen van je wijzigingen
moet je ze committen aan de repository om ze beschikbaar te stellen
aan de rest van de groep.
We zullen het commando cvs commit hieronder beschrijven.
Echter, wat als een andere ontwikkelaar dezelfde bestanden of dezelfde regels als jij heeft gewijzigd? Wiens wijzigingen zullen de overhand krijgen? Het is in het algemeen onmogelijk om deze vraag automatisch te beantwoorden; CVS is zeker niet bevoegd om dat oordeel te vellen.
Dus voordat je de wijzigingen aan kunt leveren, vereist CVS dat je sources
synchroon zijn met eventuele aangeleverde wijzigingen van de andere
teamleden. Hier zorgt het cvs update commando voor:
$ cvs update cvs update: Updating . U Makefile RCS file: /u/src/master/httpc/httpc.c,v retrieving revision 1.6 retrieving revision 1.7 Merging differences between 1.6 and 1.7 into httpc.c M httpc.c $
Laten we dit eens regel-voor-regel bekijken:
U Makefile
RCS file: ...
retrieving revision 1.6
retrieving revision 1.7
Merging differences between 1.6 and 1.7 into httpc.c
1.7 zijn revisienummers, die
worden gebruikt om een specifiek punt in de historie
van een bestand te identificeren.
CVS voegt alleen de wijzigingen in, in je werkkopie; de repository
en de werkdirectories van de andere ontwikkelaars blijven onaangetast.
Het is aan jou om de samengevoegde tekst te testen, en ervoor te zorgen dat
het klopt.
M httpc.c
Aangezien CVS de wijzigingen van iemand anders met je source heeft samengevoegd, kun je het beste controleren of alles nog steeds werkt:
$ make gcc -g -Wall -Wmissing-prototypes -lnsl -lsocket httpc.c -o httpc $ httpc GET http://www.cyclic.com ... HTML text for Cyclic Software's home page follows ... $
Het schijnt nog steeds te werken.
Nu dat je de sources met de rest van de groep hebt bijgewerkt en ze hebt
getest, ben je er klaar voor om je wijzigingen aan de repository aan te
leveren en ze zichtbaar te maken voor de rest van de groep. Het enige
bestand dat je hebt gewijzigd is `httpc.c', maar het is altijd veilig
om cvs update op te starten om een lijst met de gewijzigde bestanden
van CVS te verkrijgen:
$ cvs update cvs update: Updating . M httpc.c $
Zoals verwacht, noemt CVS alleen het bestand `httpc.c'; het geeft aan dat er wijzigingen in voorkomen die je nog niet hebt aangeleverd. Je kunt ze dan als volgt aanleveren:
$ cvs commit httpc.c
Op dit punt zal CVS je favoriete editor opstarten en je vragen om een logbericht waarin je de wijziging beschrijft. Als je de editor afsluit, zal CVS je wijziging aanleveren:
Checking in httpc.c; /u/src/master/httpc/httpc.c,v <-- httpc.c new revision: 1.8; previous revision: 1.7 $
Nu dat je de wijzigingen hebt aangeleverd, zijn ze zichtbaar voor de rest
van de groep. Als een andere ontwikkelaar cvs update opstart, zal
CVS je wijzigingen met `httpc.c' in hun werkdirectory samenvoegen.
Op dit punt, ben je misschien wel nieuwsgierig naar de wijzigingen die de
andere ontwikkelaar in `httpc.c' heeft gemaakt. Om de logrecords
van een gegeven bestand te bekijken, kun je het commando cvs log
gebruiken:
$ cvs log httpc.c RCS file: /u/src/master/httpc/httpc.c,v Working file: httpc.c head: 1.8 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 8; selected revisions: 8 description: The one and only source file for the trivial HTTP client ---------------------------- revision 1.8 date: 1996/10/31 20:11:14; author: jimb; state: Exp; lines: +1 -1 (tcp_connection): Cast address structure when calling connect. ---------------------------- revision 1.7 date: 1996/10/31 19:18:45; author: fred; state: Exp; lines: +6 -2 (match_header): Make this test case-insensitive. ---------------------------- revision 1.6 date: 1996/10/31 19:15:23; author: jimb; state: Exp; lines: +2 -6 ... $
De meeste tekst hier kun je negeren; het deel om zorgvuldig te bekijken is de reeks loggegevens na de eerste regel met afbreektekens. De loggegevens verschijnen in omgekeerde tijdsvolgorde, in de veronderstelling dat recentere wijzigingen meestal interessanter zijn. Ieder gegeven beschrijft een wijziging aan het bestand, en kan als volgt worden ontleed:
Het cvs log commando kan logrecords aan de hand van een datumrange, of
revisienummer selecteren; zie voor de details de handleiding.
Als je eigenlijk de wijziging zelf zou willen zien, kun je het commando
cvs diff gebruiken. Als je bijvoorbeeld de wijzigingen, die Fred
voor revisie 1.7 aanleverde, zou willen zien, kun je het volgende
commando gebruiken:
$ cvs diff -c -r 1.6 -r 1.7 httpc.c
Laten we eens kijken wat de diverse onderdelen betekenen, voordat we de uitvoer van dit commando bekijken:
-c
cvs diff verzocht om voor de uitvoer gebruik te maken
van een voor de mens leesbaarder formaat.
(Ik ben er niet zeker van waarom dit niet als standaard is ingesteld).
-r 1.6 -r 1.7
-r 1.6 -r 1.8 zou zowel de wijzigingen van fred
tonen als je recentste wijziging.
(Je kunt zelfs opgeven dat wijzigingen in omgekeerde volgorde moeten
worden getoond -- alsof ze ongedaan werden gemaakt -- door de revisies
andersom op te geven: -r 1.7 -r 1.6. Dit klinkt vreemd, maar soms
is het handig).
httpc.c
Hier is de uitvoer van het commando:
Index: httpc.c
===================================================================
RCS file: /u/src/master/httpc/httpc.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -c -r1.6 -r1.7
*** httpc.c 1996/10/31 19:15:23 1.6
--- httpc.c 1996/10/31 19:18:45 1.7
***************
*** 62,68 ****
}
! /* Return non-zero iff HEADER is a prefix of TEXT. HEADER should be
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
--- 62,69 ----
}
! /* Return non-zero iff HEADER is a prefix of TEXT, ignoring
! differences in case. HEADER should be lower-case, and
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
***************
*** 76,81 ****
--- 77,84 ----
for (i = 0; i < header_len; i++)
{
char t = text[i];
+ if ('A' <= t && t <= 'Z')
+ t += 'a' - 'A';
if (header[i] != t)
return 0;
}
$
Het kost wat moeite om aan deze uitvoer te wennen, maar het is het beslist waard om het te begrijpen.
Het interessantste gedeelte begint bij de eerste twee regels beginnend met
*** en ---; deze beschrijven de vergelijking van de oudere
en nieuwere bestanden.
De rest bestaat uit twee delen, ieder begint met een
regel asterisksen. Dit is het eerste deel:
***************
*** 62,68 ****
}
! /* Return non-zero iff HEADER is a prefix of TEXT. HEADER should be
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
--- 62,69 ----
}
! /* Return non-zero iff HEADER is a prefix of TEXT, ignoring
! differences in case. HEADER should be lower-case, and
null-terminated; LEN is the length of TEXT. */
static int
match_header (char *header, char *text, size_t len)
Tekst van de oudere versie verschijnt na de *** 62,68 *** regel;
tekst van de nieuwe versie verschijnt na de --- 62,69 --- regel.
Het nummerpaar van ieder geeft de range getoonde regels aan.
CVS brengt rondom de wijziging wat structuur aan, en markeert de werkelijke
regels waar het om gaat met `!' tekens. Dus, je kunt zien dat de enkele
regel in de bovenste helft werd vervangen door de twee regels in de onderste
helft.
Hier is het tweede deel:
***************
*** 76,81 ****
--- 77,84 ----
for (i = 0; i < header_len; i++)
{
char t = text[i];
+ if ('A' <= t && t <= 'Z')
+ t += 'a' - 'A';
if (header[i] != t)
return 0;
}
Dit deel beschrijft de invoeging van twee regels, gemarkeerd met `+' tekens. CVS laat de oude tekst in dit geval weg, omdat het overtollig zou zijn. CVS gebruikt een vergelijkbaar deel qua opmaak om verwijderingen te beschrijven.
Net als het Unix diff commando, wordt uitvoer van cvs diff
gewoonlijk een patch genoemd, omdat ontwikkelaars volgens traditie
het formaat hebben gebruikt om bugfixes of kleine nieuwe features te
distribueren.
Terwijl het voor mensen redelijk te lezen is, bevat een patch voldoende
informatie voor een programma om de wijzigingen die het beschrijft op
een ongewijzigd tekstbestand toe te passen.
In feite is dit exact wat het Unix patch commando doet, een patch
als invoer opgeven.
CVS behandelt de aanmaak en het verwijderen van een bestand net als andere veranderingen, door dergelijke acties in de historie van het bestand op te nemen. Een manier om hier naar te kijken is te zeggen dat CVS de historie van directories als ook de bestanden die erin staan opneemt.
CVS gaat er niet vanuit dat nieuw aangemaakte bestanden onder zijn beheer
zouden moeten vallen; dit zou in veel omstandigheden ook niet goed zijn.
Het is bijvoorbeeld niet nodig om wijzigingen aan objectbestanden en
uitvoerbare bestanden op te nemen, aangezien de inhoud ervan altijd weer
opnieuw kan worden gegenereerd vanuit de bronbestanden (hoopt men).
Als je een nieuw bestand aanmaakt, zal cvs update het met een
`?' teken markeren, totdat je CVS aangeeft wat je van plan bent
er mee te doen.
Om een bestand aan een project toe te voegen, moet je het bestand eerst
aanmaken, en dan het commando cvs add gebruiken om het voor
toevoeging te markeren. Vervolgens zal de volgende aanroep van
cvs commit het bestand aan de repository toevoegen. Je kunt
bijvoorbeeld als volgt een README bestand aan het httpc project toevoegen:
$ ls CVS Makefile httpc.c poll-server $ vi README ... enter a description of httpc ... $ ls CVS Makefile README httpc.c poll-server $ cvs update cvs update: Updating . ? README --- CVS is met dit bestand nog niet bekend. $ cvs add README cvs add: scheduling file `README' for addition cvs add: use 'cvs commit' to add this file permanently $ cvs update --- Wat denkt CVS er nu van? cvs update: Updating . A README --- Het bestand is voor aanvulling gemarkeerd. $ cvs commit README ... CVS vraagt je om een logrecord ... RCS file: /u/jimb/cvs-class/rep/httpc/README,v done Checking in README; /u/src/master/httpc/README,v <-- README initial revision: 1.1 done $
CVS behandelt verwijderde bestanden op vergelijkbare wijze. Als je een
bestand verwijdert en dan cvs update opstart,
gaat CVS er niet van uit dat je het bestand wilt verwijderen.
In plaats daarvan doet het iets uit welwillendheid -- het maakt het bestand
opnieuw aan met als inhoud wat het als laatste heeft opgenomen,
en markeert het met een `U' teken, net als bij iedere andere update.
(Dit betekent dat als je wijzigingen aan een bestand in je werkdirectory
ongedaan wilt maken, je de bestanden gewoon kunt verwijderen, en ze
vervolgens door cvs update opnieuw aan laat maken).
Om een bestand uit een project te verwijderen, moet je het bestand eerst
verwijderen en dan het commando cvs rm gebruiken om het voor
verwijdering te markeren. Vervolgens zal de volgende aanroep naar
cvs commit het bestand uit de repository verwijderen.
Het `committen' van een bestand dat met cvs rm is gemarkeerd,
verwijdert niet de historie van een bestand. Het voegt gewoon een nieuwe
revisie toe, die als "non-existent" wordt gemarkeerd. De repository
heeft nog steeds de registraties van de voorgaande inhoud van het bestand,
en kan deze herroepen als dat nodig is -- bijvoorbeeld via
cvs diff of via cvs log.
Er zijn verscheidene strategieën voor het herbenoemen van bestanden;
de eenvoudigste is door gewoon het bestand in je werkdirectory te hernoemen,
en cvs rm op de oude naam uit te voeren, en
cvs add op de nieuwe naam. Het nadeel hiervan is dat de loggegevens
voor de inhoud van het oude bestand niet naar het nieuwe bestand worden
overgedragen. Andere strategieën vermijden dit, maar hebben andere,
vreemdere problemen.
Je kunt directories toevoegen net zoals je dit met gewone bestanden zou doen;
Als men cvs diff kan gebruiken om de feitelijke tekst van een
wijziging op te halen, waarom zou men zich dan druk maken om het schrijven
van loggegevens? Loggegevens kunnen uiteraard korter zijn dan een patch,
en de lezer in de gelegenheid stellen algemeen begrip voor de wijziging te
verkrijgen zonder zich in de details ervan te hoeven verdiepen.
Goede loggegevens beschrijven echter de reden die de ontwikkelaar had
om de wijziging door te voeren. Bijvoorbeeld: een slecht logrecord voor
revisie 1.7 hierboven zou kunnen luiden, "Converteer naar kleine letters."
Dit zou correct, maar volledig nutteloos zijn;
cvs diff geeft dezelfde informatie maar dan duidelijker.
Een beter logrecord zou zijn, "Maak deze test
case-insensitive," omdat dat het doel voor iedereen met een algemene
kennis van de code verduidelijkt:
HTTP clients zouden verschillen in hoofd- en kleine letters bij het
ontleden van reply headers moeten negeren.
Zoals hierboven al is aangegeven, neemt het commando cvs update
wijzigingen die door andere ontwikkelaars zijn gemaakt, op in je werkdirectory.
Als zowel jijzelf als de andere ontwikkelaar hetzelfde bestand hebben
gewijzigd, voegt CVS hun wijzigingen met die van jou samen.
Je kunt je vast wel voorstellen hoe dit werkt als de wijzigingen gelden voor gebieden van het bestand die van elkaar verwijderd zijn, maar wat gebeurt er als jij en die andere ontwikkelaar dezelfde regel hebben veranderd? CVS noemt deze situatie een conflict, en laat het aan jou over om het op te lossen.
Stel bijvoorbeeld dat je net wat foutcontrole hebt toegevoegd aan de
host name opzoekcode. Voordat je je wijziging aanlevert, moet je
cvs update opstarten, om je sources synchroon te laten lopen:
$ cvs update cvs update: Updating . RCS file: /u/src/master/httpc/httpc.c,v retrieving revision 1.8 retrieving revision 1.9 Merging differences between 1.8 and 1.9 into httpc.c rcsmerge: warning: conflicts during merge cvs update: conflicts found in httpc.c C httpc.c $
In dit geval, heeft een andere ontwikkelaar hetzelfde gebied van het bestand gewijzigd dat jij hebt gewijzigd, dus geeft CVS een melding over een conflict. In plaats dat het `M httpc.c' afdrukt, zoals het dat gewoonlijk doet, drukt het `C httpc.c' af, om aan te geven dat er in dat bestand een conflict is opgetreden.
Om het conflict op te lossen, vraag je het bestand op in je editor. CVS markeert het conflict op de volgende wijze:
/* Look up the IP address of the host. */
host_info = gethostbyname (hostname);
<<<<<<< httpc.c
if (! host_info)
{
fprintf (stderr, "%s: host not found: %s\n", progname, hostname);
exit (1);
}
=======
if (! host_info)
{
printf ("httpc: no host");
exit (1);
}
>>>>>>> 1.9
sock = socket (PF_INET, SOCK_STREAM, 0);
De tekst uit je werkbestand verschijnt bovenaan, na de `<<<'
tekens; eronder staat de conflicterende tekst van de andere ontwikkelaar.
Het revisienummer `1.9' geeft aan dat de wijziging die het conflict
veroorzaakte, in versie 1.9 van het bestand werd geïntroduceerd,
wat het makkelijker voor je maakt om de logs te controleren, of de
volledige wijziging met cvs diff te bestuderen.
Zodra je hebt besloten hoe het conflict zou moeten worden opgelost, verwijder je de markeringen van de code, en plaats je het zoals het zijn moet. Aangezien in dit geval de code voor foutafhandeling duidelijk voorrang heeft, zou je de wijziging van de andere ontwikkelaar er gewoon uit kunnen gooien, waarbij de tekst als volgt wordt:
/* Look up the IP address of the host. */
host_info = gethostbyname (hostname);
if (! host_info)
{
fprintf (stderr, "%s: host not found: %s\n", progname, hostname);
exit (1);
}
sock = socket (PF_INET, SOCK_STREAM, 0);
Zodra dit is gebeurd, kun je je wijzigingen testen en het bestand aanleveren:
$ make gcc -g -Wall -Wmissing-prototypes -lnsl -lsocket httpc.c -o httpc $ httpc GET http://www.cyclic.com HTTP/1.0 200 Document follows Date: Thu, 31 Oct 1996 23:04:06 GMT ... $ httpc GET http://www.frobnitz.com httpc: host not found: www.frobnitz.com $ cvs commit httpc.c
Het is belangrijk te begrijpen wat CVS wel en niet doet in geval van een conflict. CVS begrijpt de semantiek van je programma niet; het behandelt de source code net als een structuur met tekstbestanden. Als een ontwikkelaar een nieuw argument aan een functie toevoegt en de aanroepen er naartoe aanpast, terwijl tegelijkertijd een andere ontwikkelaar een nieuwe aanroep naar die functie doet, en het nieuwe argument niet doorgeeft, dan is dat zeker een conflict --- de twee wijzigingen zijn incompatibel -- maar CVS zal het niet rapporteren. CVS's begrip van conflicten is strikt tekstueel.
In de praktijk zijn conflicten gelukkig zeldzaam. Meestal zijn ze het resultaat van twee ontwikkelaars die hetzelfde probleem proberen te adresseren, een gebrek aan communicatie tussen ontwikkelaars, of een meningsverschil over het ontwerp van het programma. Ontwikkelaars op redelijkerwijze taken toekennen, vermindert de kans op conflicten.
Veel versie controle systemen staan een ontwikkelaar toe om een lock op een bestand te plaatsen, om te voorkomen dat anderen er wijzingen in aanbrengen, totdat hij zijn wijzigingen heeft aangebracht. Ondanks dat het soms passend is om een lock op een bestand te plaatsen, is het klaarblijkelijk geen betere oplossing dan de benadering van CVS. Wijzigingen kunnen meestal correct worden samengevoegd, en ontwikkelaars vergeten weleens om de lock vrij te geven; in beide gevallen, veroorzaakt een expliciete lock onnodige onderbrekingen. Bovendien voorkomt een lock slechts tekstuele conflicten; ze voorkomen geen semantische conflicten van de soort zoals hierboven is beschreven, wanneer de twee ontwikkelaars hun wijzigingen aan verschillende bestanden toebrengen.
This document was generated on 12 February 2000 using texi2html 1.56k.