\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename intro.info
@settitle Introductie CVS
@setchapternewpage off
@c Choices for setchapternewpage are {on,off,odd}.
@c %**end of header

@ifinfo

Dit zijn notities van de tweedaagse cursus van Cyclic Software's. Ze zijn
geschreven door Jim Blandy.


Copyright @copyright{} 1996 Jim Blandy.  All rights reserved.

Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

@ignore
Permission is granted to process this file through TeX and print the
results, provided the printed document carries a copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).
@end ignore

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the Free Software Foundation.

@end ifinfo


@titlepage
@title{Introductie CVS}
@subtitle{Notities voor Dag 1 van een tweedaagse cursus CVS}
@author Jim Blandy, vertaald door Ellen Bokhorst

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1996 Jim Blandy

Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that this permission notice may be stated in a translation
approved by the Free Software Foundation.

@end titlepage


@node Top, Waar is CVS voor?, (dir), (dir)
@top Introductie CVS

Dit zijn de notities voor de tweedaagse CVS-cursus van Cyclic Software. 
Het CVS Versie Systeem is een programma voor het beheren en raadplegen
van de historie van een software-project, of iedere andere directory-structuur
met tekstbestanden.

@menu
* Waar is CVS voor?::            
* Hoe CVS te gebruiken --- Eerste Schets::  
@end menu

@node Waar is CVS voor?, Hoe CVS te gebruiken --- Eerste Schets, Top, Top
@chapter 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:

@itemize @bullet

@item
Wie maakte een bepaalde wijziging?

@item
Wanneer deden ze dit?

@item
Waarom deden ze dit?

@item
Welke andere wijzigingen maakten ze op dat moment nog meer?
@end itemize

@node Hoe CVS te gebruiken --- Eerste Schets,  , Waar is CVS voor?, Top
@chapter Hoe CVS te gebruiken --- Eerste Schets

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

@menu
* Instellen van je repository::     
* Check out van een werkdirectory::  
* Bestanden wijzigen::     
* Wijzigingen samenvoegen::        
* Commit van je wijzigingen::     
* Bestudeer wijzigingen::           
* Toevoegen en verwijderen van bestanden::
* Schrijven van goede loggegevens::    
* Afhandelen van conflicten::          
@end menu


@node Instellen van je repository, Check out van een werkdirectory, Hoe CVS te gebruiken --- Eerste Schets, Hoe CVS te gebruiken --- Eerste Schets
@section Instellen van je repository

CVS neemt de wijzigingen van iedereen in een gegeven project in een
directory-structuur genaamd @dfn{repository} op.
Voordat je CVS kunt gebruiken, moet je de omgevingsvariabele
@code{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
@code{CVSROOT}.

In ieder geval staat de CVS repository op ons systeem in @file{/u/src/master}.
In dat geval zou je de volgende commando's in moeten voeren
@example
setenv CVSROOT /u/src/master
@end example
@noindent
als je shell @code{csh} of een afgeleide daarvan is, of
@example
CVSROOT=/u/src/master
export CVSROOT
@end example
@noindent
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:
@example
$ cvs checkout httpc
cvs checkout: No CVSROOT specified!  Please use the `-d' option
cvs [checkout aborted]: or set the CVSROOT environment variable.
$ 
@end example


@node Check out van een werkdirectory, Bestanden wijzigen, Instellen van je repository, Hoe CVS te gebruiken --- Eerste Schets
@section 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
@code{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
@code{httpc}, een
alledaagse HTTP client:
@example
$ cd
$ cvs checkout httpc
cvs checkout: Updating httpc
U httpc/.cvsignore
U httpc/Makefile
U httpc/httpc.c
U httpc/poll-server
$ 
@end example

Het commando @code{cvs checkout httpc} betekent, ``Haal de source tree
met de naam @code{httpc} op vanuit de repository aangegeven door de
omgevingsvaribele @code{CVSROOT}.''

CVS plaatst de structuur in een subdirectory met de naam @file{httpc}:
@example
$ 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
@end example

Van deze bestanden zijn de meeste je werkkopien van de @code{httpc} sources.
De subdirectory met de naam @file{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.


@node Bestanden wijzigen, Wijzigingen samenvoegen, Check out van een werkdirectory, Hoe CVS te gebruiken --- Eerste Schets
@section 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:

@example
$ 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
$
@end example

Het lijkt erop dat @file{httpc.c} nog niet naar dit besturingssysteem is 
overgedragen. We zullen n van de argumenten aan @code{connect} moeten
toewijzen. Om dat te herstellen, moet regel 48 worden gewijzigd van:
@example
    if (connect (sock, &name, sizeof (name)) >= 0)
@end example
@noindent in dit:
@example
    if (connect (sock, (struct sockaddr *) &name, sizeof (name)) >= 0)
@end example

Nu zou het gecompileerd moeten kunnen worden:
@example
$ make
gcc -g -Wall  -lnsl -lsocket  httpc.c   -o httpc
$ httpc GET http://www.cyclic.com
@dots{} @var{HTML text for Cyclic Software's home page follows} @dots{}
$
@end example


@node Wijzigingen samenvoegen, Commit van je wijzigingen, Bestanden wijzigen, Hoe CVS te gebruiken --- Eerste Schets
@section 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 @dfn{committen} aan de repository om ze beschikbaar te stellen
aan de rest van de groep.
We zullen het commando @code{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 @code{cvs update} commando voor:
@example
$ 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
$ 
@end example

Laten we dit eens regel-voor-regel bekijken:
@table @code

@item U Makefile
Een regel in de vorm @samp{U @var{file}} betekent gewoon dat er een
@dfn{Update} van @var{file} plaatsvond; iemand anders had een wijziging aan het bestand toegebracht,
en CVS kopieerde het gewijzigde bestand naar je homedirectory.

@item RCS file: @dots{}
@itemx retrieving revision 1.6
@itemx retrieving revision 1.7
@itemx Merging differences between 1.6 and 1.7 into httpc.c
Deze meldingen geven aan dat iemand anders het bestand @file{httpc.c}
heeft gewijzigd;
CVS voegt die wijzigingen met de jouwe samen, en vond geen tekstuele
conflicten.
De nummers @samp{1.6} en @code{1.7} zijn @dfn{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.

@item M httpc.c
Een regel in de vorm @samp{M @var{file}} betekent dat @var{file} door jou
is @dfn{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 @file{httpc.c} zowel jouw wijzigingen als die
van de andere gebruiker.
@end table

Aangezien CVS de wijzigingen van iemand anders met je source heeft
samengevoegd, kun je het beste controleren of alles nog steeds werkt:
@example
$ make
gcc -g -Wall -Wmissing-prototypes  -lnsl -lsocket  httpc.c   -o httpc
$ httpc GET http://www.cyclic.com
@dots{} @var{HTML text for Cyclic Software's home page follows} @dots{}
$ 
@end example

Het schijnt nog steeds te werken.


@node Commit van je wijzigingen, Bestudeer wijzigingen, Wijzigingen samenvoegen, Hoe CVS te gebruiken --- Eerste Schets
@section 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 @file{httpc.c}, maar het is altijd veilig
om @code{cvs update} op te starten om een lijst met de gewijzigde bestanden
van CVS te verkrijgen:
@example
$ cvs update
cvs update: Updating .
M httpc.c
$
@end example
@noindent
Zoals verwacht, noemt CVS alleen het bestand @file{httpc.c}; het geeft aan
dat er wijzigingen in voorkomen die je nog niet hebt aangeleverd.
Je kunt ze dan als volgt aanleveren:
@example
$ cvs commit httpc.c
@end example
@noindent
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:
@example
Checking in httpc.c;
/u/src/master/httpc/httpc.c,v  <--  httpc.c
new revision: 1.8; previous revision: 1.7
$
@end example

Nu dat je de wijzigingen hebt aangeleverd, zijn ze zichtbaar voor de rest
van de groep. Als een andere ontwikkelaar @code{cvs update} opstart, zal
CVS je wijzigingen met @file{httpc.c} in hun werkdirectory samenvoegen.

@node Bestudeer wijzigingen, Toevoegen en verwijderen van bestanden, Commit van je wijzigingen, Hoe CVS te gebruiken --- Eerste Schets
@section Bestudeer wijzigingen

Op dit punt, ben je misschien wel nieuwsgierig naar de wijzigingen die de
andere ontwikkelaar in @file{httpc.c} heeft gemaakt. Om de logrecords
van een gegeven bestand te bekijken, kun je het commando @code{cvs log}
gebruiken:
@example
$ 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
@dots{}
$ 
@end example

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:
@table @samp

@item revision 1.8
Iedere versie van een bestand heeft een uniek @dfn{revisienummer}. 
Revisienummers lijken op
@samp{1.1}, @samp{1.2}, @samp{1.3.2.2} of zelfs
@samp{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.

@item date: 1996/10/31 20:11:14;  author: jimb; @dots{}
Deze regel geeft de wijzigingsdatum, en de gebruikersnaam van de persoon
die het aanleverde; de rest van de regel is niet zo interessant.

@item (tcp_connection): Cast @dots{}
Dit (nogal vanzelfsprekend) is het logrecord dat de wijziging beschrijft.

@end table

Het @code{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
@code{cvs diff} gebruiken. Als je bijvoorbeeld de wijzigingen, die Fred
voor revisie 1.7 aanleverde, zou willen zien, kun je het volgende 
commando gebruiken:
@example
$ cvs diff -c -r 1.6 -r 1.7 httpc.c
@end example

Laten we eens kijken wat de diverse onderdelen betekenen, voordat we 
de uitvoer van dit commando bekijken:
@table @code

@item -c
Hiermee wordt @code{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).

@item -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, @code{-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: @code{-r 1.7 -r 1.6}. Dit klinkt vreemd, maar soms
is het handig).

@item 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.

@end table

Hier is de uitvoer van het commando:

@example
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;
      @}
$ 
@end example

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
@code{***} en @code{---}; deze beschrijven de vergelijking van de oudere 
en nieuwere bestanden.
De rest bestaat uit twee @dfn{delen}, ieder begint met een
regel asterisksen. Dit is het eerste deel:

@example
@group
***************
*** 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)
@end group
@end example


Tekst van de oudere versie verschijnt na de @code{*** 62,68 ***} regel;
tekst van de nieuwe versie verschijnt na de @code{--- 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 @samp{!} 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:

@example
***************
*** 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;
      @}
@end example

Dit deel beschrijft de invoeging van twee regels, gemarkeerd met @samp{+}
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 @code{diff} commando, wordt uitvoer van @code{cvs diff}
gewoonlijk een @dfn{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 @code{patch} commando doet, een patch
als invoer opgeven.

@node Toevoegen en verwijderen van bestanden, Schrijven van goede loggegevens, Bestudeer wijzigingen, Hoe CVS te gebruiken --- Eerste Schets
@section 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 @code{cvs update} het met een
@samp{?} 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 @code{cvs add} gebruiken om het voor
toevoeging te markeren.  Vervolgens zal de volgende aanroep van
@code{cvs commit} het bestand aan de repository toevoegen. Je kunt 
bijvoorbeeld als volgt een README bestand aan het httpc project toevoegen:
@example
$ ls
CVS          Makefile     httpc.c      poll-server
$ vi README
@dots{} @var{enter a description of httpc} @dots{}
$ ls
CVS          Makefile     README       httpc.c      poll-server
$ cvs update
cvs update: Updating .
? README @var{--- 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 @var{--- Wat denkt CVS er nu van?}
cvs update: Updating .
A README @var{--- Het bestand is voor aanvulling gemarkeerd.}
$ cvs commit README
@dots{} @var{CVS vraagt je om een logrecord} @dots{}
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
$
@end example

CVS behandelt verwijderde bestanden op vergelijkbare wijze. Als je een
bestand verwijdert en dan @code{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 @samp{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 @code{cvs update} opnieuw aan laat maken).

Om een bestand uit een project te verwijderen, moet je het bestand eerst
verwijderen en dan het commando @code{cvs rm} gebruiken om het voor 
verwijdering te markeren. Vervolgens zal de volgende aanroep naar
@code{cvs commit} het bestand uit de repository verwijderen.

Het `committen' van een bestand dat met @code{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
@code{cvs diff} of via @code{cvs log}.

Er zijn verscheidene strategien voor het herbenoemen van bestanden; 
de eenvoudigste is door gewoon het bestand in je werkdirectory te hernoemen,
en @code{cvs rm} op de oude naam uit te voeren, en 
@code{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 strategien vermijden dit, maar hebben andere,
vreemdere problemen.

Je kunt directories toevoegen net zoals je dit met gewone bestanden zou doen;

@node Schrijven van goede loggegevens, Afhandelen van conflicten, Toevoegen en verwijderen van bestanden, Hoe CVS te gebruiken --- Eerste Schets
@section Schrijven van goede loggegevens
 
Als men @code{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 @emph{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;
@code{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.


@node Afhandelen van conflicten,  , Schrijven van goede loggegevens, Hoe CVS te gebruiken --- Eerste Schets
@section Afhandelen van conflicten

Zoals hierboven al is aangegeven, neemt het commando @code{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
@dfn{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
@code{cvs update} opstarten, om je sources synchroon te laten lopen:
@example
$ 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
$ 
@end example
@noindent

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 @samp{M httpc.c} afdrukt, zoals het dat gewoonlijk doet, 
drukt het @samp{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:

@example
@group
  /* 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);
@end group
@end example

De tekst uit je werkbestand verschijnt bovenaan, na de @samp{<<<}
tekens; eronder staat de conflicterende tekst van de andere ontwikkelaar.
Het revisienummer @samp{1.9} geeft aan dat de wijziging die het conflict
veroorzaakte, in versie 1.9 van het bestand werd gentroduceerd,
wat het makkelijker voor je maakt om de logs te controleren, of de
volledige wijziging met @code{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:

@example
  /* 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);
@end example

Zodra dit is gebeurd, kun je je wijzigingen testen en het bestand aanleveren:
@example
$ 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
@dots{}
$ httpc GET http://www.frobnitz.com
httpc: host not found: www.frobnitz.com
$ cvs commit httpc.c
@end example

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 @dfn{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.

@bye