Introductie CVS

Jim Blandy, vertaald door Ellen Bokhorst


Waar is CVS voor?

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:

Hoe CVS te gebruiken -- Eerste Schets

Laten we eerst de essentiŽle CVS commando's eens bekijken, voordat we te veel vage termen en concepten gaan bespreken.

Instellen van je repository

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.
$ 

Check out van een werkdirectory

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.

Bestanden wijzigen

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 ...
$

Wijzigingen samenvoegen

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
Een regel in de vorm `U file' betekent gewoon dat er een Update van file plaatsvond; iemand anders had een wijziging aan het bestand toegebracht, en CVS kopieerde het gewijzigde bestand naar je homedirectory.
RCS file: ...
retrieving revision 1.6
retrieving revision 1.7
Merging differences between 1.6 and 1.7 into httpc.c
Deze meldingen geven aan dat iemand anders het bestand `httpc.c' heeft gewijzigd; CVS voegt die wijzigingen met de jouwe samen, en vond geen tekstuele conflicten. De nummers `1.6' en 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
Een regel in de vorm `M file' betekent dat file door jou is Modified (gewijzigd), en bevat wijzigingen die nog niet zichtbaar zijn voor de andere ontwikkelaars. Dit zijn de wijzigingen die je nog aan moet leveren. In dit geval staan er in `httpc.c' zowel jouw wijzigingen als die van de andere gebruiker.

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.

Commit van je wijzigingen

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.

Bestudeer wijzigingen

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:

`revision 1.8'
Iedere versie van een bestand heeft een uniek revisienummer. Revisienummers lijken op `1.1', `1.2', `1.3.2.2' of zelfs `1.3.2.2.4.5'. Standaard is revisie 1.1 de eerste revisie van een bestand. Iedere succesvolle revisie krijgt een nieuw nummer door het meest rechtse nummer met ťťn te verhogen.
`date: 1996/10/31 20:11:14; author: jimb; ...'
Deze regel geeft de wijzigingsdatum, en de gebruikersnaam van de persoon die het aanleverde; de rest van de regel is niet zo interessant.
`(tcp_connection): Cast ...'
Dit (nogal vanzelfsprekend) is het logrecord dat de wijziging beschrijft.

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
Hiermee wordt 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
Hiermee geef je aan CVS op dat de wijzigingen moeten worden getoond, die nodig waren om revisie 1.6 van httpc.c om te zetten naar revisie 1.7. Je kunt een groter gebied aan revisies opgeven als je dat wilt; bijvoorbeeld, -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
Dit is de naam van het te inspecteren bestand. Als je geen specifieke bestanden opgeeft, zal CVS een rapport voor de gehele directory produceren.

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.

Toevoegen en verwijderen van bestanden

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;

Schrijven van goede loggegevens

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.

Afhandelen van conflicten

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.