Rozdział 2. CVS
Jednym z problemów, który powinien być rozwiązany we wczesnej fazie projektu, jest sposób
śledzenia zachodzących w nim zmian. Mogą to być zmiany zarówno w kodzie z
ródłowym, jak i w
dokumentacji. Należy je śledzić z dwóch powodów: po pierwsze  po to, aby można było
uzyskać informacje o zawartości kodu lub dokumentacji w określonym momencie czasu; po
drugie  aby wiedzieć, co i kiedy się działo.
Oczywiście, można tworzyć tylko kopie poszczególnych plików w zapasowych katalogach,
nadając im nazwy odpowiednie do daty. Takie proste rozwiązanie staje się jednak bardzo szybko
rozwiązaniem nieefektywnym, szczególnie wtedy, gdy w projekcie bierze udział kilku
programistów i czas pracy nad projektem wynosi więcej niż kilka tygodni.
Jeżeli programista pracuje samodzielnie, to zwykle wyobraża sobie, że kontrola kodu z
ródłowego
nie daje zbyt wiele, ponieważ do tego kodu nie ma dostępu nikt oprócz niego samego. Niestety,
nawet najlepsi programiści od czasu do czasu popełniają błędy i muszą powracać do poprzedniej
wersji programu. Użytkownicy mogą zgłaszać błędy dostrzeżone w kolejnych wersjach programu
i zamiast śledzenia tych błędów w tradycyjny sposób, łatwiej będzie cofnąć się do wersji
poprzedniej i tam sprawdzić zmiany wprowadzone w kodzie. W takich okolicznościach system
kontroli kodu z
ródłowego może dać nieocenione korzyści, ponieważ rejestruje on dokładnie, kiedy
i co zostało zmienione.
Jeżeli kilku programistów pracuje zespołowo, to wymagania są jeszcze ostrzejsze niż w przypadku
programu tworzonego przez jedną osobę. Trzeba wówczas wiedzieć, kto, co i kiedy zmienił 
ponieważ wtedy można łatwiej zlokalizować miejsce popełnienia błędów. Dzięki zastosowaniu
odpowiednich komentarzy przy okazji dokonywania zmian w kodzie można również dowiedzieć
się, dlaczego zmiany te zostały wprowadzone, co bywa czasami bardzo przydatne.
Mówiąc krótko: istnieje bardzo wiele powodów, dla których warto stosować system kontroli kodu
z
ródłowego, natomiast bardzo mało jest przeciwwskazań, gdy pod uwagę bierzemy jakość
bezpłatnych narzędzi dostępnych w systemie Linux.
W tym rozdziale omówimy:
konfigurację CVS,
opis zastosowania CVS do zarządzania projektem,
sieciową instalację CVS umożliwiającą rzeczywistą pracę zespołową.
Narzędzia dla systemu Linux
Kiedyś istniał tylko jeden sposób kontroli kodu z
ródłowego w Linuksie, a mianowicie tzw. system
kontroli wersji (Revision Control System oznaczany skrótem RCS) wchodzący w skład zestawu
narzędzi programowania GNU. System RCS był i jest nadal bardzo użyteczny, ale wielu
programistów (szczególnie tych, którzy brali udział w pracach zespołowych lub działali w różnych
środowiskach programowania) zaczęło korzystać z nowszego narzędzia, czyli z CVS (Concurrent
Versions System).
CVS powstał w roku 1986. jako zestaw kilku skryptów powłoki. Obecnie kod tego systemu opiera
się głównie na pracy Briana Berlinera z 1989. roku. CVS ma trzy podstawowe właściwości, dzięki
którym bywa coraz częściej stosowany do zarządzania zmianami w kodzie z
ródłowym zamiast
RCS:
CVS można łatwo przystosować do pracy w sieci, a nawet w Internecie,
CVS umożliwia jednoczesną pracę wielu programistów nad tym samym kodem
z
ródłowym i w wielu wypadkach pozwala na automatyczne dołączanie zmian do projektu
wprowadzanych przez różnych programistów,
CVS ma znacznie lepiej działający system zarządzania zbiorami plików niż RCS.
Dodajmy do tego fakt, że CVS jest całkowicie bezpłatny; otrzymujemy więc doskonałe narzędzie,
które prawdopodobnie kiedyś trzeba będzie poznać. W tym rozdziale omówimy następujące
zagadnienia:
konfigurację i zastosowanie CVS przez jednego użytkownika na komputerze lokalnym,
konfigurację i korzystanie z CVS przez wielu użytkowników w sieci,
użyteczne właściwości i rozszerzenia CVS, w tym konfigurację sieciową i klienty
graficzne.
CVS jest dość skomplikowanym systemem i dlatego nie można szczegółowo omówić wszystkich
jego właściwości w jednym rozdziale. Myślimy jednak, że udało się tu przedstawić niemal 95%
tych szczegółów, które będą potrzebne w praktyce. Jeżeli pojawią się wówczas bardziej
zaawansowane potrzeby, to należy samemu przestudiować wszystkie ukryte cechy CVS.
Skoncentrujemy się tutaj na zarządzaniu kodem z
ródłowym za pomocą CVS. Należy przy tym
pamiętać, że odnosi się to tylko do zarządzania zmianami w danych testowych, plikach
konfiguracyjnych lub pomocniczych skryptach używanych w projekcie. Oczywiście, wszystkie
elementy projektu mogą być przechowywane w systemie CVS.
CVS może także przechowywać specyfikację projektu, która jest często bardziej wartościowa niż
sam kod z
ródłowy. Jeżeli jednak jakiś element projektu jest zapisany w postaci binarnej, to
informację o tym należy przekazać do CVS. System nie będzie wówczas mógł automatycznie
sygnalizować różnic między poszczególnymi wersjami takiego elementu. Pod koniec tego
rozdziału powiemy więcej na temat zarządzania plikami binarnymi.
Terminologia
Przed rozpoczęciem pracy z systemem CVS musimy zapoznać się ze stosowaną w nim
terminologią:
Pobranie (Check Out)  pobranie kopii jednego lub wielu plików z głównego z
ródła z
zamiarem wprowadzania zmian w tych plikach.
Zatwierdzenie (Commit)  wprowadzenie zmian dokonanych lokalnie w pliku
z
ródłowym do głównej kopii tego pliku.
Projekt (Project)  zbiór plików wchodzących w skład aplikacji.
Repozytorium (Repository)  miejsce przechowywania głównej kopii kodu z
ródłowego
w systemie CVS.
Korekta (Revision)  każda zmiana w pliku to korekta. Określenie to często bywa
traktowane jako numer wersji ostatecznego wydania programu, ale w tym rozdziale
będziemy traktować je zgodnie ze specyfiką CVS  jako oznakowaną zmianę w
pojedynczym pliku z
ródłowym.
W dalszych częściach rozdziału wprowadzimy jeszcze kilka dodatkowych określeń, ale podane
wyżej definicje już wystarczają do rozpoczęcia pracy z CVS.
Repozytorium
System CVS wchodzi w skład wszystkich ważniejszych dystrybucji Linuksa, dlatego w tym
rozdziale skoncentrujemy się na jego konfiguracji. Jeżeli zdarzy się (co jest bardzo mało
prawdopodobne), że dana dystrybucja nie zawiera CVS, to należy skorzystać z informacji
z
ródłowych podanych na końcu rozdziału i pobrać go samemu z któregoś serwera.
Przed uruchomieniem CVS należy utworzyć repozytorium, które posłuży do przechowywania
głównych kopii plików z
ródłowych i wewnętrznych plików konfiguracyjnych.
Lokalizacja repozytorium jest sprawą osobistego wyboru. Ponieważ będzie ono zawierać główne
kopie plików z
ródłowych, warto ulokować je w zabezpieczonym miejscu i regularnie tworzyć
kopie zapasowe! Całkowicie wykonalne jest utworzenie na tym samym komputerze wielu
repozytoriów, z których każde będzie niezależnie przechowywać struktury wielu projektów.
Każde repozytorium może obejmować wiele podkatalogów, a więc konfiguracja systemu CVS jest
bardzo elastyczna.
W naszym przypadku utworzymy repozytorium CVS w katalogu /usr/local/cvsrep. Jeżeli
projekt jest duży, to na repozytorium można przeznaczyć oddzielną partycję dysku i wydzielony
punkt zamontowania katalogu. Aby zachować kontrolę dostępu do CVS, co jest związane z
odpowiednimi uprawnieniami do zapisu w repozytorium, należy utworzyć grupę użytkowników,
którzy będą korzystali z systemu CVS.
W celu łatwiejszego zapamiętania nazwiemy tę grupę cvs-user. Dowolny użytkownik, który
chce uzyskać dostęp do repozytorium CVS, będzie musiał należeć do tej grupy. Przed dopisaniem
użytkowników musimy skonfigurować nasze repozytorium. Najpierw z konta root utworzymy
grupę:
# groupadd cvs-user
a następnie katalog:
# mkdir /usr/local/cvsrep
Po utworzeniu katalogu przeznaczonego na repozytorium system CVS musi utworzyć pliki służące
do zarządzania repozytorium. W tym celu z konta root należy uruchomić polecenie:
# cvs -d /usr/local/cvsrep init
CVS utworzy w katalogu /usr/local/cvsrep katalog CVSROOT, a w nim różne wymagane pliki
konfiguracyjne.
Można teraz przejść do tego katalogu i zmienić grupowe prawa właścicielskie katalogu z
repozytorium i wszystkich zawartych w nim plików na grupę cvs-user:
# cd /usr/local/cvsrep
# chmod g+w .
# chgrp -R cvs-user .
Od tego momentu wszyscy użytkownicy należący do grupy cvs-user będą mogli bez ograniczeń
korzystać z repozytorium CVS. Starszym użytkownikom systemu UNIX przypominamy, że Linux,
podobnie jak większość współczesnych wersji systemu UNIX, pozwala użytkownikom należeć do
wielu grup, a więc przynależność do grupy cvs-user nie pociąga za sobą żadnych ograniczeń.
Obsługa CVS przez jedynego użytkownika
Pokażemy tutaj sposób korzystania z systemu CVS przez jedynego użytkownika repozytorium, a
przy okazji zobaczymy, jak CVS zarządza naszym własnym kodem z
ródłowym.
Format polecenia CVS
CVS jest narzędziem uruchamianym z wiersza poleceń i taki interfejs będzie omawiany w tym
podrozdziale. Póz
niej omówimy także kilka interfejsów graficznych opracowanych dla CVS.
Wszystkie polecenia CVS mają następującą postać:
cvs [opcje standardowe] polecenie [opcje polecenia] [nazwy plików]
Jak widać, polecenia te zawierają argument opisujący faktyczną wymaganą operację. Taka postać
pozwala na użycie dla CVS całkowicie nowej tablicy nazw i ich uproszczenie. Opcje standardowe
są dostępne dla większości poleceń CVS. Poniżej podajemy podstawowe z nich:
-d
Definicja używanego repozytorium. Jeśli nie korzystamy z wielu
repozytoriów, to na ogół wygodniej jest zdefiniować zmienną
środowiskową. Opcja -d zastępuje wartość zmiennej środowiskowej
CVSROOT (którą wyjaśnimy wkrótce), co zapewnia wygodny dostęp do
rzadko używanych repozytoriów.
-e
Definicja edytora używanego wówczas, gdy CVS żąda podania danych
wejściowych, np. przy wpisach do logu.
--help, -H
Wyświetlenie tekstu pomocy dla danego polecenia.
-n
Brak działania. Umożliwia podgląd operacji CVS bez ich faktycznego
wykonywania.
-q, -Q
Praca ze zmniejszoną liczbą komunikatów wyjściowych CVS (-q) lub
całkowicie bez tych komunikatów (-Q).
-t
Śledzenie działania.
-v, -version
Wyświetlenie numeru wersji CVS.
-z
Stopień kompresji przesyłanych danych. Opcja używana przy dostępie z
sieci. Wartość 1 oznacza najmniejszą kompresję, a 9  kompresję
maksymalną. Wartość 4 stanowi dobry kompromis między wykorzystaniem
procesora i szerokością pasma zajmowanego przy transmisji.
Zmienne środowiskowe
Przed rozpoczęciem pracy w systemie CVS trzeba jeszcze zapoznać się z kilkoma przydatnymi
zmiennymi środowiskowymi używanymi przez ten system (tutaj opisujemy tylko trzy zmienne, w
rzeczywistości jest ich nieco więcej):
CVSROOT
Definiuje repozytorium, do którego będą się odnosić polecenia CVS.
CVSEDITOR
Definiuje edytor wywoływany przez CVS wówczas, gdy trzeba wpisać jakiś
tekst.
CVSIGNORE
Definiuje listę nazw plików i wzorce nazw plików, które mają być
ignorowane podczas wykonywania poleceń CVS.
Wartość zmiennej środowiskowej CVSROOT może być zawsze zastąpiona wartością opcji -d, jak
już wspomnieliśmy w poprzednim podrozdziale. Będziemy ją ustawiać przed następnymi
czynnościami. Podane niżej polecenia dotyczą powłoki typu BASH; przy powłoce csh należy użyć
polecenia setenv.
$ export CVSROOT=/usr/local/cvsrep
$ export CVSEDITOR=emacs
$ export CVSIGNORE="foo bar *.class"
Od tego momentu będą obowiązywać następujące wartości i zachowania domyślne:
/usr/local/cvsrep jako repozytorium, emacs jako edytor używany przez CVS, a polecenia
CVS zawsze będą ignorowały pliki o nazwach foo i bar oraz pliki o nazwach z końcówką
.class.
W praktyce CVS rozpoznaje wiele rodzajów plików pośrednich powstających przy kompilacji,
łącznie z plikami o nazwach kończących się na .o, .a i ~, a także pliki core, ignorując je
automatycznie.
Import nowego projektu
Rozpocznijmy od bardzo wczesnego etapu naszego projektu, gdy mamy tylko trzy pliki
zawierające polecenia SQL:
create_tables.sql
drop_tables.sql
insert_data.sql
Nie jest to zbyt wiele, ale wystarczy do zapoznania się z działaniem systemu CVS. Najpierw
musimy wybrać nazwę naszego projektu. CVS używa tej nazwy jako nazwy katalogu, a więc musi
ona spełniać określone reguły. Nazwiemy zatem nasz projekt plip-app, a ponieważ powstał on
dla wydawnictwa Wrox, umiejscowimy go także w katalogu wrox.
Zaimportujemy nasz niewielki zbiór plików za pomocą plecenia cvs import. Wykorzystamy tu
jedynie opcję -m, która definiuje komunikat wpisywany do logu (jeśli nie podamy tej opcji w
wierszu poleceń, to CVS tego zażąda). Użytkownicy zaznajomieni z systemem RCS korzystają
często w poleceniu import z opcji -b, która umożliwia nadanie początkowego numeru sekwencji.
Ciekawscy czytelnicy mogą znalez
ć opisy rzadziej stosowanych opcji na stronach podręcznika
systemowego man oraz info i w publikacjach wymienionych na końcu tego rozdziału.
Mamy więc następującą składnię polecenia cvs import:
cvs import [opcje] nazwa-projektu znacznik-autora znacznik-wydania
Polecenie cvs import wyszukuje wszystkie pliki w bieżącym katalogu i importuje je kolejno do
projektu. W naszym przypadku użyjemy opcji -m, podając w niej komunikat do logu; jako
znacznika autora użyjemy nazwy stixen, a jako znacznika wydania użyjemy start:
$ cvs import -m"Initial version of demonstration application for PLiP"
wrox/plip-app stixen start
Komunikaty CVS będą zbliżone do poniższych:
N wrox/plip-app/create_tables.sql
N wrox/plip-app/drop_tables.sql
N wrox/plip-app/insert_data.sql
I wrox/plip-app/create_tables.sql~
No conflicts created by this import
W odpowiedzi na polecenie importu mogą pojawiać się różnego rodzaju komunikaty. Pierwsza
litera komunikatu określa jego rodzaj, a za nią następuje nazwa pliku. Jako komunikat końcowy
często pojawia się też dodatkowa informacja. Istnieją następujące rodzaje odpowiedzi systemu
CVS (nie tylko dla polecenia import):
C
Konflikt (conflict)  plik już istnieje w repozytorium, lecz różni się od pliku lokalnego,
co wymaga ręcznego dołączenia.
I
Zignorowany (ignored)  plik został zignorowany.
L
Dowiązanie (link)  plik jest dowiązaniem symbolicznym i dlatego został zignorowany
(CVS nie obsługuje dowiązań symbolicznych).
M
Zmodyfikowany (modified)  plik został zmodyfikowany w repozytorium.
N
Nowy (new)  nowy plik został dodany do repozytorium.
R
Usunięty (removed)  plik został usunięty.
U
Zaktualizowany (updated)  plik został zaktualizowany.
?
Zapytanie (query)  znaleziono nie występujący w repozytorium plik lokalny, który nie
ma oznaczenia, że powinien być ignorowany.
W naszym przykładzie mamy trzy nowe pliki dodane do repozytorium i zignorowany plik kopii
zapasowej create_tables.sql~ utworzony przez edytor emacs (wzorzec *.~ jest
rozpoznawany automatycznie przez CVS jako nazwa pliku, który należy zignorować).
Jeżeli póz
niej zechcemy dodać do repozytorium kolejne nowe pliki (co jest wielce
prawdopodobne, zważywszy na szczupłość naszych początkowych danych), to możemy postąpić
dwojako. Jeżeli projekt jest pobierany i przerabiany, to możemy posłużyć się poleceniem cvs
add, omówionym dalej. Jeżeli projekt nie był przerabiany, to dodatkowe pliki można dodawać
posługując się poleceniem cvs import. Załóżmy, że po imporcie plików z
ródłowych zauważamy
np. brak pliku README. Możemy utworzyć go w katalogu bieżącym i dodać go bezpośrednio do
repozytorium za pomocą polecenia:
$ cvs import -m"Added README" wrox/plip-app stixen start
U wrox/plip-app/create_tables.sql
U wrox/plip-app/drop_tables.sql
U wrox/plip-app/insert_data.sql
N wrox/plip-app/README
I wrox/plip-app/create_tables.sql~
No conflicts created by this import.
CVS zauważa istniejące pliki, ale do repozytorium dodaje tylko nowy plik README.
Początek prac nad projektem w CVS
Mamy już utworzony nasz projekt CVS, możemy więc oczyścić katalog bieżący i pobrać z
repozytorium kopie plików, z którymi będziemy pracować. W zasadzie należałoby usunąć katalog
lokalny i wszystkie pliki zaimportowane do CVS, ale w praktyce autorzy wolą pozostawić to
wszystko, zmieniając tylko nazwę katalogu, przynajmniej do czasu uzyskania całkowitej
pewności, że wszystkie pliki w repozytorium CVS są prawidłowe i o niczym nie zapomniano.
W rzeczywistości autorzy książki nigdy nie utracili plików z repozytorium CVS, ale postępują tak
ponieważ wolą dmuchać na zimne.
Aby pobrać pliki z repozytorium należy użyć polecenia cvs checkout. Polecenie to ma kilka
opcji, z których niżej podaliśmy tylko najważniejsze:
-D
Pobranie projektu z podaną datą. Przeważnie data jest podawana albo w
zalecanym formacie ISO jako  1999-09-24 16:05 , albo można użyć  24 Sep
1999 16:05 lub nawet specjalnych fraz, takich jak  yesterday lub  last
Monday .
-d
Pobranie projektu do wskazanego katalogu. Domyślnie, tak jak to
wspomniano wcześniej, nazwa projektu jest używana jako nazwa katalogu.
-p
Pobranie projektu i przekazanie go na standardowe wyjście zamiast zapisania
go w katalogu, co jest zachowaniem domyślnym.
-r
Pobranie projektu w stanie określonym przez dany znacznik. Do znaczników
powrócimy już za chwilę.
W poleceniu należy także podać nazwę projektu, który ma być pobrany i opcjonalnie  nazwy
pobieranych plików. Domyślnie pobierane są wszystkie pliki.
Po przejściu do pustego katalogu możemy zatem pobrać do niego nasz projekt i rozpocząć pracę:
$ cvs checkout wrox/plip-app
cvs checkout: Updating wrox/plip-app
U wrox/plip-app/README
U wrox/plip-app/create_tables.sql
U wrox/plip-app/drop_tables.sql
U wrox/plip-app/insert_data.sql
Zostanie utworzony podkatalog o nazwie wrox/plip-app, a w nim ostatnie wersje każdego
pliku, którymi można się posługiwać w dalszej pracy. Oprócz tego pojawi się podkatalog o nazwie
CVS (wielkie litery). Jest to katalog roboczy systemu CVS i nie wolno zmieniać w nim
czegokolwiek, pomimo że w niektórych dokumentach mówi się o tym. Zalecamy tu ścisłe
trzymanie się oficjalnych poleceń, nawet wtedy, gdy wymagają one większej liczby uderzeń w
klawisze.
Porównywanie zmian z zawartością repozytorium
Po pobraniu kopii projektu pracujemy nad nią lokalnie. Załóżmy więc, że po kilku godzinach
pracy osiągnęliśmy jakiś kolejny stabilny stan, przetestowaliśmy wprowadzone zmiany i chcemy
przenieść zmienione pliki z
ródłowe ponownie do repozytorium. Przed dokonaniem tej operacji
zalecamy jednak ponowne sprawdzenie wprowadzonych zmian.
Pliki przechowywane można porównać lokalnie z plikami znajdującymi się w repozytorium
używając polecenia cvs diff. Ma ono kilka opcji:
-c
Kontekstowe wyświetlenie różnic zawartości plików za pomocą programu
diff (wiersze zmienione w otoczeniu wierszy sąsiednich) co ułatwia
wzrokową identyfikację zmian.
-b
Ignorowanie różnic w liczbie spacji oddzielających wewnątrz danego wiersza.
-B
Ignorowanie wstawionych lub usuniętych pustych wierszy.
-D
Wyszukiwanie różnic odniesionych do plików w repozytorium o określonej
dacie.
-r
Porównanie z plikami o podanym numerze wersji lub znaczniku tekstowym.
Można podać dwie opcje -r i wtedy polecenie cvs diff służy do porównań
wewnętrznych w repozytorium między dwoma różnymi wersjami. Pliki
lokalne są wówczas ignorowane.
Można opcjonalnie podać w tym poleceniu listę plików. Zostaną wówczas pokazane różnice ich
zawartości. Jeżeli lista plików nie będzie podana, to polecenie cvs diff wskaże różnice
zawartości wszystkich plików projektu i plików w bieżącym katalogu.
Należy pamiętać, że polecenie cvs diff ignoruje pliki utworzone w lokalnym katalogu, które nie
są umieszczone w repozytorium. Na pierwszy rzut oka takie zachowanie domyślne nie wydaje się
dobrym rozwiązaniem, ale w praktyce okaże się to przydatne, ponieważ pozwala uniknąć wielu
komunikatów o braku jakichś tymczasowych plików w repozytorium.
Po modyfikacji naszych dwóch przykładowych plików uruchamiamy cvs diff i możemy
porównać ich bieżące kopie robocze z kopiami znajdującymi się w repozytorium CVS:
$ cvs diff -B
cvs diff: Diffing .
Index: create_tables.sql
===============================================================
RCS file: /usr/local/cvsrep/wrox/plip-app/create_tables.sql,v
retriving revision 1.1.1.1
diff-B -r1.1.1.1 create_tables.sql
47a50,55
> );
>
> create table genre (
> genre_id INT NOT NULL,
> genre_name CHAR(21),
> CONSTRAINT genre_id_uniq UNIQUE(genre_id)
Index: drop_tables.sql
=============================================================
RCS file: /usr/local/cvsrep/wrox/plip-app/drop_tables.sql,v
retriving revision 1.1.1.1
diff -B -r1.1.1.1 drop_tables.sql
10a11
> drop table genre;
Jak widać, wyświetlona została nazwa każdego zmienionego pliku oraz wprowadzone w nim
zmiany. Można zauważyć także odnośniki do RCS. Starsze wersje CVS były zbudowane na bazie
RCS, a nowsze nadal korzystają z pewnych rozwiązań i nazw plików tego systemu.
Inny sposób porównywania plików lokalnych z plikami w repozytorium polega na użyciu
polecenia cvs status, które generuje listę zmienionych plików. Polecenie cvs status -v
umożliwi obejrzenie większej liczby komunikatów.
W tym momencie możemy zdecydować, czy chcemy utrzymać wprowadzone zmiany, czy też je
pominąć. Jeśli chcemy pominąć zmiany, to najprostszym sposobem jest usunięcie lokalnego pliku
i użycie polecenia cvs update  wtedy w katalogu lokalnym pojawi się  czysta kopia pliku z
repozytorium.
Aktualizacja repozytorium
Załóżmy, że zmiany wprowadzone w plikach lokalnych są zgodne z oczekiwaniami i chcemy
przekazać zmienione pliki do repozytorium. Operacja ta nazywa się  zatwierdzaniem i jest
przeprowadzana za pomocą polecenia cvs commit.
Polecenie cvs commit ma tylko dwie często używane opcje:
-m
Dołączenie komunikatu informacyjnego. Jeśli komunikat nie zostanie
wpisany, to CVS wywoła albo edytor określony przez zmienną środowiskową
CVSEDITOR lub, jeśli to się nie uda, przez zmienną EDITOR, albo domyślny
edytor systemowy (zwykle jest to vi), w którym trzeba będzie wpisać
komunikat.
-r
Zatwierdzenie korekty o określonym numerze. Jest to zalecane tylko wtedy,
d j kt ł i i ó i d l j ś i t d i ł
gdy projekt ma rozgałęzienia omówione w dalszej części tego rozdziału.
Po uruchomieniu polecenia cvs commit pojawi się informacja o plikach zmienianych w
repozytorium:
$ cvs commit
Ponieważ nie podano komunikatu, a zmienna środowiskowa CVSEDITOR ma wartość emacs, to
wywołany zostanie emacs i pojawi się żądanie wpisania komunikatu:
CVS: ------------------------------------------------------------
CVS: Enter Log. Lines beginning with 'CVS:' are removed automatically
CVS:
CVS: Committing in .
CVS:
CVS: Modified Files:
CVS: create_tables.sql drop_tables.sql
CVS: ------------------------------------------------------------
Po wpisaniu komunikatu i zamknięciu edytora emacs (i wcześniejszym zachowaniu pliku)
polecenie cvs commit wznawia działanie:
Checking in create_tables.sql;
/usr/local/cvsrep/wrox/plip-app/create_tables.sql,v <-- create_tables.sql
new revision: 1.2; previous revision: 1.1
done
Checking in drop_tables.sql;
/usr/local/cvsrep/wrox/plip-app/drop_tables.sql,v <-- drop_tables.sql
new revision: 1.2; previous revision: 1.1
Na podstawie tych komunikatów widać, że CVS automatycznie określa, które pliki wymagają
przetwarzania.
Wydanie projektu
Po zakończeniu pracy nad projektem należy go  wydać (ang. release), czyli spowodować, by
system CVS usunął wszelkie informacje o tym projekcie. W praktyce nie ma to zbyt wielkiego
znaczenia w przypadku projektu prowadzonego przez jednego programistę lub mało
skomplikowanego projektu prowadzonego przez wielu programistów, ale warto przestrzegać tego
dobrego zwyczaju. W naszym przypadku wydanie (zwolnienie) projektu polega na przejściu do
katalogu położonego o stopień wyżej niż katalog plip-app i użyciu polecenia cvs release.
Polecenie to ma tylko jedną opcję:
-d
Automatyczne usunięcie zwolnionego katalogu.
Jeżeli w katalogu lokalnym istnieją jakieś zmiany nie przekazane do repozytorium, to pojawi się
ostrzeżenie i będzie można anulować polecenie cvs release.
Przegląd zmian wprowadzanych do projektu przez cały okres pracy można uzyskać za pomocą
polecenia cvs history. Polecenie to umożliwia zapoznanie się z całą historią projektu w postaci
niezbyt przystępnie zbudowanej listy:
$ cvs history -e -a
O 04/15 17:23 +0000 rick wrox/plip-app =wrox/plip-app= ~/wrox/plip-app
M 04/15 21;15 +0000 rick 1.2 create_tables.sql wrox/plip-app == ~/wrox/plip-
app
M 04/15 21;15 +0000 rick 1.2 drop_tables.sql wrox/plip-app == ~/wrox/plip-
app
F 04/15 21:20 +0000 rick =plip-app= ~/wrox/*
Na podstawie powyższych komunikatów można poznać historię projektu. Najważniejsze opcje
polecenia cvs history są następujące:
-a
Wyświetlenie historii działań wszystkich użytkowników.
-D
Wyświetlenie zmian wprowadzonych od podanej daty.
-e
Wyświetlenie wszystkiego (domyślnie pokazywane są tylko pobrania).
-r
Wyświetlenie zmian, które wprowadzono od podanej korekty.
-u
Wyświetlenie zmian dokonanych przez danego użytkownika.
Przeglądanie zmian
Po wprowadzeniu zmian do plików w repozytorium możemy zobaczyć, co się zmieniło, używając
polecenia cvs log. W tym celu należy przejść ponownie do katalogu z zapisanym projektem.
CVS może wówczas określić, którego projektu dotyczy polecenie. Rozmiar wyświetlanego tekstu
jest raczej dosyć duży, dlatego tutaj pokażemy tylko jego fragment:
$ cd plip-app
$ cvs log create_tables.sql
----------------------------
revision 1.2
date: 2000/04/15 21:15:08, author: rick; state: Exp; lines: +8 -0
Added the genre table.
----------------------------
revision 1.1
date: 2000/04/15 15;57:22, author: rick; state: Exp;
branches: 1.1.1;
Initial revision
Jeżeli w poleceniu cvs log nie zostanie podana nazwa pliku, to pojawią się zapisy z logu
dotyczące wszystkich plików wchodzących w skład projektu. Polecenie cvs log ma kilka
użytecznych opcji:
-D
Wyświetlenie zmian wprowadzonych od podanej daty.
-h
Wyświetlenie tylko informacji nagłówkowej o każdym pliku.
Dodawanie i usuwanie plików z projektu
W miarę postępu prac nad projektem prawie zawsze pojawia się konieczność dodawania nowych
plików do repozytorium CVS. Służy do tego polecenie cvs add z argumentem, którym jest nazwa
dodawanego pliku. Polecenie to ma trzy główne opcje:
-kb
Oznaczenie pliku binarnego.
-ko
Zakaz rozwijania słów kluczowych (patrz poniżej)
-m
Dopisanie do logu CVS komunikatu o przyczynie dodania pliku.
Przy dodawaniu nowego pliku do projektu nie jest on natychmiast dodawany do repozytorium.
Polega to na tym, że nazwa pliku pojawia się na liście plików aktualizowanych w następnym
poleceniu cvs commit.
Podobnie wygląda usuwanie plików z projektu za pomocą polecenia cvs remove. Jeżeli plik o
danej nazwie istnieje w katalogu lokalnym, to polecenie to nie uda się  chyba że zostanie użyta
opcja -f, która służy do usuwania również plików lokalnych. Podobnie jak przy poleceniu cvs
add, zawartość repozytorium jest zmieniana dopiero po zatwierdzeniu zmian za pomocą polecenia
cvs commit.
Jeżeli plik zostanie usunięty i operacja ta zostanie zatwierdzona, a następnie zechcemy odtworzyć
go ponownie, to nieusunięte pozostałości pliku można znalez
ć w podkatalogu Attic w
repozytorium CVS. Trzeba je wówczas skopiować do nowego katalogu i tam, korzystając z
edytora, otworzyć oryginalny plik.
Rozwinięcia słów kluczowych
Jedną z cennych właściwości CVS jest możliwość używania słów kluczowych (ang. keyword
substitution) w pobieranym pliku. Właściwość ta została zaadoptowana z RCS i jest podobnie
obsługiwana. Podczas pobierania plików z repozytorium lub zatwierdzania zmian używane są
następujące  magiczne napisy:
$Author$
Rozwinięcie na nazwę dostępową.
$Date$
Rozwinięcie na datę ostatniego zatwierdzenia.
$Headers$
Rozwinięcie na niektóre standardowe informacje nagłówkowe.
$Id$
Rozwinięcie na standardowe informacje nagłówkowe, bez nazw ścieżek.
$Log$
Rozwinięcie na zestaw komunikatów logu.
$Name$
Rozwinięcie na dowolną nazwę znacznika użytą przy pobieraniu danego pliku.
$Revision$
Rozwinięcie na numer korekty.
$State$
Ogólnie nie używane.
Najłatwiej wyjaśnić działanie tych słów kluczowych po ich rozwinięciu:
$Author: rick $
$Date: 2000/04/16 17:38:08 $
$Header: /usr/local/cvsrep/wrox/plip-app/README,v 1.4 2000/04/16 17:38:08
rick Exp
$
$Id: README,v 1.4 2000/04/16 17:38:08 rick Exp $
$Log: README,v $
Revision 1.4 2000/04/16 17:38:08 rick
Added keyword strings
$Name: $
$Revision: 1.4 $
$State: Exp $
System CVS automatycznie aktualizuje te słowa kluczowe po każdym pobraniu pliku, więc nie
trzeba martwić się o ich poprawność.
Ogólnie rzecz biorąc, warto uwidocznić przynajmniej jeden z tych napisów w ostatecznej
skompilowanej wersji aplikacji, przyporządkowując go jakiejś zmiennej statycznej. Pozwoli to
uniknąć usunięcia takich nieużywanych zmiennych przez kompilator dokonujący optymalizacji
kodu. Autorzy sądzą, że najbardziej przydaje się wyświetlanie wersji programu łącznie z napisem
$Id$. Nawet wówczas, gdy nie chcemy, aby występował on w wersji skompilowanej, warto
przechowywać go w kodzie z
ródłowym jako komentarz. Polecamy strony podręcznika
systemowego dla polecenia ident (z systemu RCS), które służy do wyszukiwania napisów w tym
formacie w plikach skompilowanych.
Korekty, znaczniki i rozgałęzienia
Dotychczas jedynie wspomnieliśmy o korektach i rozgałęzieniach. Pokazaliśmy kilka poleceń
wykorzystujących znaczniki, nie precyzując dokładnie znaczenia tych pojęć. Uczynimy to teraz.
Korekty
Przy każdym zatwierdzaniu zmian w pliku w repozytorium CVS tworzona jest nowa korekta (ang.
revision) tego pliku. Przeważnie korekty mają kolejną numerację w postaci 1.1, 1.2, 1.3 itd. Można
wprawdzie zmienić numer początkowy, co stanowi znaczny postęp w stosunku do RCS, ale w
zasadzie w systemie CVS nie ma takiej potrzeby. Jak wkrótce się przekonamy, znaczniki
stosowane w CVS dają znacznie więcej swobody niż numeracja wersji używana w RCS.
Jak widzieliśmy, w komunikatach generowanych przez CVS występują czasami odwołania do
numerów gałęzi w postaci liczb oddzielonych kropkami oraz do numerów korekt mających postać
dwóch liczb oddzielonych kropką. Może to być trochę mylące, ale dopóki nie używa się
rozgałęzień, należy brać pod uwagę tylko numery korekt.
Znaczniki
Jeżeli wydajemy projekt składający się z wielu plików, to zazwyczaj każdy plik ma wiele korekt
dokonywanych na różnym poziomie. Bardzo ważna jest zatem możliwość przechwycenia nie tylko
odpowiedniej wersji każdego pliku z
ródłowego wchodzącego w skład wydawanego projektu, ale
także korekty o właściwym numerze. Można to sobie ułatwić, stosując nazwane znaczniki
odnoszące się do całego zestawu plików tworzących cały projekt, niezależnie od faktycznych
numerów wersji tych plików.
Załóżmy, że chcemy w tej chwili wydać nasz projekt plip-app. Nie znajduje się on obecnie w
najlepszym stanie, ale chcemy np. przekazać komuś polecenia SQL tworzące naszą bazę danych w
celu umożliwienia mu dalszej pracy. Oczywiście, ponieważ daleko jest jeszcze do ukończenia
projektu, więc prawdopodobnie będziemy musieli zmieniać budowę tabel w bazie danych.
Musimy odnotować, co udostępniamy innym osobom, aby w przyszłości móc je informować o
dokonanych zmianach.
Mamy obecnie cztery pliki, ale nie wszystkie mają ten sam numer korekty. Pliki
create_tables.sql i drop_tables_sql mają numer 1.2, zaś pozostałe pliki mają numer 1.1.
Oczywiście, przy czterech plikach w projekcie zachowanie kontroli jest bardzo proste, ale gdy
liczba plików wynosi kilkadziesiąt i występują korekty o różnych numerach, może to spowodować
niemały kłopot.
Posłużymy się więc znacznikiem (ang. tag) dodanym do projektu, który możemy póz
niej
wykorzystać jako tekstową etykietę na równi z numerami korekt nadawanymi automatycznie przez
system CVS. Do nadania znacznika służy polecenie cvs tag, które ma kilka opcji:
-b
Utworzenie rozgałęzienia (opiszemy to w następnym podrozdziale).
-c
Sprawdzenie, czy wszystkie zmiany w repozytorium zostały zatwierdzone.
Jeśli tak nie jest, to polecenie utworzenia znacznika nie uda się.
-D Znacznik odnoszący się do korekt nie starszych od podanej daty.
-d
Usunięcie znacznika. Należy tu postępować ostrożnie, ponieważ zapis historii
modyfikacji znaczników nie jest tworzony i po ich usunięciu nie zostaje po
nich żaden ślad.
-F
Wymuszona zmiana nazwy istniejącego znacznika stosowana przy konflikcie
nazw.
-r Nadanie znacznika korektom o danym numerze (może się to odnosić także do
znacznika, choć nie wydaje się to zanadto użyteczne).
Oznaczmy więc aktualny stan naszego projektu gotowego do przekazania dla klienta.
$ cvs tag -c release-schema-to-wrox-01
cvs tag: Tagging .
T README
T create_tables.sql
T drop_tables.sql
T insert_data.sql
Takie polecenie spowoduje po prostu dodanie znacznika do każdego pliku w projekcie. Użyliśmy
tu opcji -c, aby sprawdzić, czy wszystkie zmiany zostały zatwierdzone, co jest bardzo dobrym i
pożytecznym zwyczajem.
Znacznik możemy zobaczyć, przeglądając zapisy historii jednego z plików w logu :
$ cvs log -h create_tables.sql
RCS file: /usr/local/cvsrep/wrox/plip-app/create_tables.sql,v
Working file: create_tables.sql
head: 1.2
branch:
locks: strict
access list:
symbolic names:
release-schema-to-wrox-01: 1.2
 start: 1.1.1.1
stixen: 1.1.1
keyword substitution: kv
total revisions: 3
=============================================================
Możemy teraz przekazać kopie plików naszemu klientowi i kontynuować pracę.
W celach demonstracyjnych zmienimy definicję niektórych pól typu CHAR na pola typu VARCHARS
i zatwierdzimy zmiany w repozytorium. Klient może zapytać się o to, czy były wprowadzone
jakieś modyfikacje od czasu otrzymania przez niego ostatniej wersji plików. Odpowiedz
na to
pytanie możemy uzyskać kilkoma sposobami. Najprościej jest przejrzeć zapis w logu za pomocą
polecenia cvs log, wyszukując nazwę naszego znacznika, a następnie za pomocą polecenia cvs
diff odszukać wprowadzone zmiany. Ponieważ polecenie cvs diff działa globalnie na cały
projekt, nie musimy nawet podawać nazw plików, które nas interesują:
$ cvs diff -r release-schema-to-wrox-01
cvs diff: Diffing .
Index: create_tables.sql
================================================================
RCS file: /usr/local/cvsrep/wrox/plip-app/create_tables.sql,v
retriving revision 1.2
retriving revision 1.3
diff -r1.2 -r1.3
8,10c8,10
< fname CHAR(26),
< lname CHAR(26) NOT NULL,
house_flat_ref CHAR(26) NOT NULL,
---
> fname VARCHAR(26),
> lname VARCHAR(26) NOT NULL,
> house_flat_ref VARCHAR(26) NOT NULL,
60c60
< err_text CHAR(50)
---
> err_text VARCHAR(50)
Jak widać, CVS nie tylko rozpoznaje pliki, które zostały zmienione, ale także pokazuje
wprowadzone zmiany, używając standardowego formatu polecenia diff.
Możemy także przekazać kopię projektu w takim stanie, w jakim się on znajdował podczas
oznaczania go określonym znacznikiem. Jest to bardzo proste, ponieważ pobieramy pliki z
repozytorium za pomocą polecenia cvs checkout z opcją -r . Niestety, system
CVS nie zawsze prawidłowo obsługuje prawa dostępu do plików i trzeba samemu się upewnić, czy
prawo do zapisu w pobranych plikach ma grupa cvs-user.
Jeżeli tak nie jest, wóczas trzeba zmienić ręcznie odpowiednie atrybuty pobranych plików,
używając polecenia chgrp -R cvs-user w katalogu /usr/local/cvs-rep. Czasem można
zauważyć, że uprawnienia do pliku nie są takie, jakie ustawiono podczas jego sprawdzania. Mamy
nadzieję, że te drobne niedogodności zostaną usunięte w następnych wersjach CVS.
Załóżmy teraz, że istnieje inny użytkownik o nazwie neil, który chce pobrać z repozytorium pliki
w takim samym stanie, w jakim były przekazane klientowi Wrox. Należy pamiętać o pobieraniu
plików do pustego katalogu. W przeciwnym razie będą one zastępować pliki już istniejące, co
grozi przypadkową utratą danych:
$ cvs checkout -r release-schema-to-wrox-01 wrox/plip-app
cvs checkout: Updating wrox/plip-app
U wrox/plip-app/README
U wrox/plip-app/create_tables.sql
U wrox/plip-app/drop_tables.sql
U wrox/plip-app/insert_data.sql
Jeżeli sprawdzimy zawartość pliku create_tables.sql, to przekonamy się, ze nie ma w nim
ostatnio wprowadzonej zmiany typu pola na VARCHAR.
Przekazaliśmy użytkownikowi neil zmienną środowiskową CVSROOT, która wskazuje na nasze
repozytorium. Można także użyć opcji -d w poleceniach CVS.
To jest właściwie wszystko, co można powiedzieć na temat podstawowego użycia znaczników w
systemie CVS. Nie należy sądzić, że łatwość ich użycia oznacza, iż nie są one ważne. Musimy
pamiętać, że wskaz
niki wyznaczają kolejne stabilne punkty w naszym projekcie.
Rozgałęzienia projektu
Czasami możemy zażyczyć sobie podziału projektu na dwie lub więcej wersji, które będą
rozwijane niezależnie. Jako przykład może tu posłużyć wydanie projektu, dla którego trzeba
utworzyć poprawki bez wprowadzania zmian, które będą przeznaczone dla następnego wydania.
Rozgałęzienie projektu pozwoli na niezależną pracę ze starymi i nowymi wersjami.
Problem ten można rozwiązać poprzez utworzenie niezależnych projektów: jednego dla starych
wersji, drugiego dla nowych. Oczywiście, musimy być absolutnie pewni, że poprawki błędów
dokonane w starym wydaniu zostaną przeniesione do nowego wydania. CVS ułatwia automatyczne
dołączanie poprawek ze starego do nowego wydania.
Załóżmy, że w wersji przekazanej naszemu klientowi musimy zmienić polecenia SQL niezależnie
od postępu głównych prac w projekcie. Zamiast tworzenia na wszelki wypadek prostej kopii
plików z
ródłowych, powinniśmy myśleć perspektywicznie i utworzyć rozgałęzienie (ang. branch),
używając opcji -b przy nadawaniu znacznika za pomocą polecenia cvs tag. Następnie, jeżeli
programista będzie pobierał kopię roboczą plików oznaczonych tym znacznikiem, będzie on
pracował na danym rozgałęzieniu, a nie na głównej kopii projektu.
Rozważmy zmiany wprowadzane w aplikacji podczas jej rozwoju. Jeśli korzystamy z systemu
CVS, to mamy elegancko ponumerowane kolejne wersje, jak na poniższym rysunku:
Jeżeli jedni programiści kontynuują pracę nad kodem z wydania 1., a drudzy zajmują się
wydaniem 2., to rozgałęzienie jest konieczne:
W rozgałęzieniu mamy wersje 1.2.1, 1.2.2 itd., które są rozwijane niezależnie od głównego nurtu
prac w postaci wersji 1.2, 1.3 itd.
Nadal nie wszystko jest stracone. Możemy zdecydować, przemieszczając się wstecz, że nadany
znacznik powinien być odgałęzieniem, a nie tylko prostym znacznikiem. Załóżmy, że neil chce
rozpocząć prace nad czystą kopią projektu wydaną klientowi. Najprostszym sposobem na to jest
użycie polecenia cvs release usuwającego istniejącą kopię, a następnie ponowne pobranie
plików za pomocą polecenia cvs checkout -r release-schema-to-wrox-01
wrox/plip-app, dzięki czemu uzyskuje się właściwą kopię.
Możemy teraz oznaczyć pobraną wersję jako rozgałęzienie, używając polecenia cvs tag.
$ cvs tag -b release-schema-to-wrox-01-branch
cvs tag: Tagging .
T README
t create_tables.sql
T drop_tables.sql
T insert_data.sql
Teraz musimy zacząć postępować ostrożnie. Oznaczyliśmy przed chwilą w repozytorium
wszystkie pliki pobrane z katalogu (release-schema-to-wrox-01) jako należące do głównego
wątku aplikacji. Nie mamy faktycznie bieżącej kopii roboczej tego rozgałęzienia  a to może być
pułapką dla nieuważnych.
W jaki sposób należy więc zmodyfikować kopię lokalną? Musimy ponownie pobrać bieżącą kopię
tak, aby system CVS odnotował informację, że jest ona częścią rozgałęzienia. W tym celu najpierw
zwolnimy istniejące pliki:
$ cvs release -d wrox/plip-app
Teraz możemy zrobić kopię tej kopii rozgałęzienia, które oznaczyliśmy:
$ cvs checkout -r release-schema-to-wrox-01-branch wrox/plip-app
cvs checkout: Updating wrox/plip-app
U wrox/plip-app/README
U wrox/plip-app/create_tables.sql
U wrox/plip-app/drop_tables.sql
U wrox/plip-app/insert_data.sql
Może się zdarzyć, że w tym momencie zamiast różnych komunikatów pojawi się komunikat o
błędzie spowodowanym niewłaściwymi uprawnieniami do pliku val-tags. Oznacza to, że jeden
z użytkowników, tworząc jakieś znaczniki, spowodował utworzenie w obszarze sterującym
repozytorium pliku val-tags. Jeżeli pierwotną grupą, do której należy ten użytkownik, nie jest
cvs-user, to byłoby lepiej, aby utworzone przez niego pliki nie mogły być modyfikowane przez
innych członków tej grupy. Administrator CVS powinien wówczas odpowiednio zmodyfikować
uprawnienia.
Trzeba zatem przejść do innego katalogu roboczego w repozytorium CVS i skorygować
uprawnienia właścicielskie (dla cvs-user) oraz zmienić uprawnienia do pliku val-tags na
takie, jakie mają inne pliki w katalogu CVSROOT.
Mamy więc kopię lokalną projektu wydanego klientowi, która jest odgałęzieniem głównego wątku
aplikacji. Znacznik tego odgałęzienia można zobaczyć za pomocą polecenia cvs status. Jeżeli
użytkownik rick pracujący z głównym wątkiem wyda takie polecenia, to zobaczy:
$ cvs status create_tables.sql
File create_tables.sql Status: Up-to-date
Working revision: 1.3 Sat Apr 15 22:59:50 2000
Repository revision: 1.3 /usr/local/cvsrep/wrox/plip-
app/create_tables.sql,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Jeśli to samo polecenie wyda użytkownika neil pracujący w odgałęzieniu projektu Wrox,
wówczas otrzymamy:
File: create_tables.sql Status: Up-to-date
Working revision: 1.2 Sat Apr 15 21:15:08 2000
Repository revision: 1.2 /usr/local/cvsrep/wrox/plip-
app/create_tables.sql,v
Sticky Tag: release-schema-to-wrox-01-branch (branch: 1.2.2)
Sticky Date: (none)
Sticky Options: (none)
Widać więc, że obydwaj użytkownicy pracują z różnymi wersjami tego samego pliku. Wiersz
Sticky Tag oznacza, że kopia lokalna jest wyróżniona jako część oznakowanego wydania.
Określenie  Sticky (czyli  przyklejany ) oznacza, że system CVS będzie w kolejnych poleceniach
automatycznie uwzględniał status tego pliku. Możemy się o tym przekonać, wprowadzając w nim
niewielką zmianę i wywołując polecenie cvs diff:
$ cvs diff create_tables.sql
Index: create_tables.sql
=================================================================
RCS file: /usr/local/cvsrep/wrox/plip-app/create_tables.sql,v
retrieving revision 1.2
diff -r1.2 create_tables.sql
29a30
> actor3 CHAR(51),
60c61
< err_text CHAR(50)
---
> err_text CHAR(75)
Wynika stąd, że polecenie cvs diff automatycznie rozróżnia fakt, iż pracujemy w odgałęzieniu,
i wyświetla różnice odniesione do plików w repozytorium wchodzących w skład tego
odgałęzienia, a nie odniesione do głównego wątku projektu. Jeżeli ręcznie porównamy zawartość
pliku, z którym pracuje użytkownik neil, z plikiem, z którym pracuje rick, to stwierdzimy, że
różnice są większe:
$ diff ~rick/wrox/plip-app/create_tables.sql create_tables.sql
8,10c8,10
< fname VARCHAR(26),
< lname VARCHAR(26) NOT NULL,
< house_flat_ref VARCHAR(26) NOT NULL,
---
> fname CHAR(26),
> lname CHAR(26) NOT NULL,
> house_flat_ref CHAR(26) NOT NULL,
29a30
> actor3 CHAR(51),
60c61
< err_text VARCHAR(50)
---
> err_text CHAR(75)
Niech użytkownik neil zmieni dla przykładu zawartość pliku insert_data.sql, który nie jest
zmieniony przez użytkownika rick. Wprowadz
my te zmiany do repozytorium za pomocą
polecenia cvs commit. Zobaczymy, że zmiany dotyczą odgałęzienia (ze względu na
 przyklejony znacznik) i wyglądają inaczej, gdy neil sprawdza je w wersji głównej:
$ cvs commit -m"Fix minor bugs in Wrox version"
cvs commit: Examining .
Checking in create_tables.sql;
/usr/local/cvsrep/wrox/plip-app/create_tables.sql,v <-- create_tables.sql
new revision: 1.2.2.1; previous revision: 1.2
done
Checking in insert_data.sql;
/usr/local/cvsrep/wrox/plip-app/insert_data.sql,v <-- insert_data.sql
new revision: 1.1.1.1.2.1; previous revision: 1.1.1.1
done
Jak widać, system CVS utworzył nową wersję z zagnieżdżonym numerem. W tym momencie
wystarczy stwierdzić, że CVS nie ogranicza się do pojedynczych odgałęzień. Można tworzyć kilka
różnych odgałęzień głównego wątku, a nawet odgałęzienia w tych odgałęzieniach. Nie jest to
jednak zalecane rozwiązanie, mimo że system na nie pozwala. Należy dobrze zastanowić się przed
utworzeniem odgałęzienia i bardzo ostrożnie podchodzić do każdej sugestii posiadania większej
liczby aktywnych wątków projektu.
Możemy teraz przekazać klientowi niewielkie zmiany wprowadzone do projektu i zachować je
jako oddzielone od reszty głównego wątku.
Załóżmy, że wszystko jest gotowe na połączenie odgałęzienia z głównym wątkiem. Odgałęzienie
zawierające poprawki błędów, które powinny znalez
ć się także w wydaniu 2., musimy włączyć
ponownie w główny wątek aplikacji.
Użytkownik rick najpierw musi poznać status projektu za pomocą polecenia cvs status -v.
Opcja -v jest potrzebna ze względu na to, że zwykłe polecenie cvs status nie podaje informacji
o odgałęzieniach. Ponieważ generowane wówczas komunikaty są bardzo obszerne, niżej
pokazujemy tylko niewielki fragment dający pojęcie o całości:
File: create_tables.sql Status: Up-to-date
Working revision: 1.3 Sat Apr 15 22:59:50 2000
Repository revision: 1.3 /usr/local/cvsrep/wrox/plip-
app/create_tables.sql,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
release-schema-to-wrox-01-branch (branch: 1.2.2)
release-schema-to-wrox-01 (revision: 1.2)
start (revision: 1.1.1.1)
stixen (branch: 1.1.1)
Ponowne łączenie rozdzielonych wątków może sprawiać kłopoty, ponieważ zmiany w pliku
create_tables.sql były wprowadzane w obydwu wersjach; co gorsza, niektóre z nich
wykluczają się wzajemnie. Widzieliśmy np. w wyniku wcześniejszego polecenia diff:
60c61
< err_text VARCHAR(50)
---
> err_text CHAR(75)
Która wersja jest więc poprawna? Nie ma automatycznego sposobu rozsądzenia problemów tego
rodzaju. CVS wspomaga jednak automatyczne łączenie innych zmian, które nie są tak dowolne.
Możemy więc, nie martwiąc się zupełnie o bezpieczeństwo projektu, pozwolić na automatyczne
łączenie dwóch wątków aplikacji, ponieważ mamy dwa zabezpieczenia. Po pierwsze  CVS nie
dołączy zmian, jeżeli występuje wyraz
ny konflikt, a po drugie  zawsze przegląda się zmiany w
odniesieniu do głównej wersji przechowywanej w repozytorium. Trzeba jednak podkreślić, że
takie operacje powinny być przeprowadzane ze szczególną ostrożnością oraz że przed ich
wykonaniem zarówno główny wątek, jak i odgałęzienie powinny zostać zatwierdzone w
repozytorium.
Do połączenia odgałęzień użyjemy nowego polecenia cvs update, które jest często używane gdy
w projekcie bierze udział wielu użytkowników. Połączenie dwóch wątków odbywa się po użyciu
opcji -j i po podaniu znacznika wątku wyróżniającego odgałęzienie, które ma być dołączone do
bieżącego katalogu z projektem.
Użytkownik rick (pobierający główny wątek jako ostatni) używa polecenia cvs update do
ponownego połączenia odgałęzienia z bieżącą wersją:
$ cvs update -j release-schema-to-wrox-01-branch
cvs update: Updating .
RCS file: /usr/local/cvsrep/wrox/plip-app/create_tables.sql,v
retriving revision 1.2
retriving revision 1.2.2.1
Merging differences between 1.2 and 1.2.2.1 into create_tables.sql
rcsmerge: warning: conflicts during merge
RCS file: /usr/local/cvsrep/wrox/plip-app/insert_data.sql,v
retriving revision 1.1.1.1
retriving revision 1.1.1.1.2.1
Merging differences between 1.1.1.1 and 1.1.1.1.2.1 into insert_data.sql
Jak widać, CVS ostrzega o konflikcie w pliku create_tables.sql. Powinniśmy się tego
spodziewać, ponieważ obydwaj użytkownicy wprowadzili w tym pliku niezależne zmiany, z
których przynajmniej dwie wykluczają się wzajemnie.
Mając podgląd wyników łączenia, możemy otworzyć plik create_tables.sql w edytorze.
Zobaczymy tam, że tylko jeden fragment pliku się nie zgadza:
create table errtext (
err_code INT,
<<<<<<< create_tables.sql
err_text VARCHAR(50)
=======
err_text CHAR(75)
>>>>>>> 1.2.2.1
);
Pozostałe zmiany zostały dołączone z niezwykłą dokładnością. Musimy tylko zmodyfikować plik
create_tables.sql , usuwając powstały konflikt, aby plik w głównym wątku zawierał
pożądaną treść. Ponieważ mamy wskazane niezgodne ze sobą miejsca w obydwu plikach
z
ródłowych, zadanie jest bardzo łatwe do wykonania. Po ponownym sprawdzeniu zmian (dla
pewności) za pomocą polecenia cvs diff możemy ostatecznie zatwierdzić zawartość
repozytorium:
$ cvs commit -m"Merge changes from release-schema-to-wrox-01-branch to
mainstream"
Checking in create_tables.sql;
/usr/local/cvsrep/wrox/plip-app/create_tables.sql,v <-- create_tables.sql
new revision: 1.4; previous revision: 1.3
done
Checking in insert_data.sql;
/usr/local/cvsrep/wrox/plip-app/insert_data.sql,v <-- insert_data.sql
new revision: 1.2; previous revision: 1.1
done
Zawsze należy przestrzegać zasady, że dołączenie odgałęzienia do repozytorium odbywa się
jednoetapowo. Nie należy próbować wprowadzania dodatkowych zmian  chyłkiem . Warto także
dodać w tym momencie znacznik zarówno do głównego wątku, jak i do odgałęzienia, co bardzo
ułatwi ich przyszłe śledzenie.
W wyniku tych wszystkich operacji włączyliśmy wprowadzone zmiany do głównego wątku
aplikacji i ponownie możemy zająć się jednym zestawem plików z
ródłowych.
CVS dla wielu użytkowników
Omawiając odgałęzienie, wspomnieliśmy o niektórych aspektach użycia CVS w środowisku wielu
użytkowników. W tym podrozdziale omówimy te zagadnienia nieco szerzej.
Większość narzędzi do kontroli kodu z
ródłowego jest przeznaczona dla jednego użytkownika i
blokuje dostęp do z
ródeł dla innych użytkowników. Zaledwie kilka z nich umożliwia opcjonalnie
pracę zespołową. W systemie CVS zastosowano zupełnie odmienne podejście  założono, że nad
projektem pracuje wielu programistów jednocześnie i że będą oni zmieniać praktycznie ten sam
plik z
ródłowy.
Problemy powstające przy zmianach kodu przez wielu użytkowników są podobne do tych, które
napotyka się przy dołączaniu w dowolnym czasie odgałęzionych wątków projektu prowadzonych
przez wiele osób.
Istnieją dwa sposoby pracy wielu użytkowników w systemie CVS, wybierane zależnie od liczby
użytkowników i stopnia porozumienia między nimi. Jeśli liczba osób wspólnie użytkujących pliki
jest niewielka i pracują oni blisko siebie, wówczas nie wymaga się od systemu CVS jakichś
specjalnych działań  wystarczy po prostu praca zespołowa. Jeżeli jednak użytkowników jest
wielu i nie mogą oni ściśle ze sobą współpracować, to system CVS może wykonać większą część
zadań administracyjnych umożliwiając programistom obserwację tego, kto co zmienia. Nie ma tu
odmiennych trybów pracy CVS, lecz jest nieco odmienny sposób wykorzystania tego systemu do
osiągnięcia tych samych celów.
Praca zespołowa
Przy takim sposobie pracy użytkownicy korzystają z systemu CVS podobnie jak pojedynczy
użytkownik, z tym wyjątkiem, że przy aktualizacji swoich kopii roboczych za pomocą polecenia
cvs update wprowadzają oni także zmiany dokonane przez innych.
Najważniejsze opcje polecenia cvs update są następujące:
-A
Usunięcie dowolnej opcji  przyklejanej , umożliwiające pracę tak, jak ze świeżą
kopią głównego projektu.
-D
Aktualizacja wersji plików, począwszy od określonej daty.
-d
Odtworzenie brakujących katalogów.
-j
Połączenie dwóch odgałęzień w jeden wątek.
-p
Zapis plików na standardowe wyjście zamiast do katalogu.
-r
Aktualizacja plików zgodnie z określonym numerem korekty lub znacznikiem.
Załóżmy, że są dwaj programiści rick i neil, którzy pobrali kopie pliku README i obydwaj
redagują ten plik. Dodatkowo rick zmienia plik create_tables.sql, a neil zmienia plik
drop_tables.sql.
Na tym etapie pracy żaden z nich nie widzi zmian wprowadzanych przez drugiego, ponieważ w
repozytorium żadne zmiany nie zostały jeszcze zatwierdzone. Załóżmy, że neil zatwierdza
wprowadzone przez siebie zmiany jako pierwszy. Jego poprawki są zapisywane w repozytorium
bez żadnych kłopotów, ponieważ wszystko działa na zasadzie  kto pierwszy, ten lepszy . Jeżeli
rick będzie gotowy do zatwierdzenia swoich zmian, to sprawdzi, uruchamiając polecenie cvs
status, czy nikt nie modyfikuje jego plików. Zobaczy wówczas następujący wynik:
File: README Status: Needs Merge
Working revision: 1.1.1.1 Sat Apr 15 16:13:02 2000
Repository revision:1.2 /usr/local/cvsrep/wrox/plip-app/README,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
=====================================================================
File: create_tables.sqlStatus: Locally Modified
Working revision: 1.4 Sun Apr 16 12:21:34 2000
Repository revision:1.4 /usr/local/cvsrep/wrox/plip-
app/create_tables.sql,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
=====================================================================
File: drop_tables.sql Status: Needs Patch
Working revision: 1.2 Sat Apr 15 21:15:08 2000
Repository revision:1.3 /usr/local/cvsrep/wrox/plip-
app/drop_tables.sql,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
=====================================================================
File: insert_data.sql Status: Up-to-date
Working revision: 1.2 Sun Apr 16 12:21:34 2000
Repository revision:1.2 /usr/local/cvsrep/wrox/plip-
app/insert_data.sql,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Na podstawie tych informacji rick może się zorientować, że:
Plik README został zmodyfikowany zarówno przez niego samego, jak i przez kogoś
innego.
Plik create_tables.sql został zmodyfikowany przez niego samego i nikogo innego.
Plik drop_tables.sql został zmodyfikowany nie przez niego, lecz przez kogoś innego.
Plik insert_data.sql nie został lokalnie zmodyfikowany ani zmieniony w
repozytorium.
Może się to wydawać nieco zagmatwane, ale jak już wcześniej widzieliśmy, CVS dobrze sobie
radzi z automatycznym sortowaniem i pokazywaniem niezgodności. Pierwszym krokiem jest
zezwolenie na wprowadzenie modyfikacji lokalnych plików przez sam system:
$ cvs update
cvs update: Updating .
RCS file: /usr/local/cvsrep/wrox/plip-app/README,v
retriving revision 1.1.1.1
retriving revision 1.2
Merging differences between 1.1.1.1 and 1.2 into README
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in README
C README
M create_tables.sql
U drop_tables.sql
Widzimy, że CVS informuje o konieczności ręcznej modyfikacji pliku README w celu rozwiązania
konfliktu, że do pliku create_tables.sql zmiany zostały wprowadzone automatycznie oraz że
lokalna kopia pliku drop_tables.sql została zastąpiona aktualną kopią z repozytorium.
Po ręcznej edycji pliku README i zaznaczonych w nim wykluczających się zmian (tak jak to się
działo przy opisanym wcześniej dołączaniu odgałęzienia do wątku głównego) użytkownik rick
może użyć polecenia cvs diff w celu sprawdzenia, czy zadowalają go wprowadzone
modyfikacje, a następnie za pomocą polecenia cvs commit może zatwierdzić zmiany w
repozytorium. W praktyce warto również przeprowadzić kilka testów dla uzyskania pewności, że
wprowadzone zmiany rzeczywiście dają to, o co chodzi. System CVS działa wprawdzie dobrze, ale
nie jest w stanie rozpoznać intencji i logiki programisty, a więc obserwacja zmian jest pożądana.
Praca ze śledzeniem
Istnieje zestaw zaawansowanych poleceń CVS służących do śledzenia (ang. watch commands),
które umożliwiają powiadamianie zarejestrowanych użytkowników (zwykle za pomocą poczty
elektronicznej) o edycji i modyfikacji plików w repozytorium. Taki tryb pracy jest bez wątpienia
bardzo zaawansowany i rzadko spotykany, więc nie będziemy tutaj nim szerzej się zajmować.
Informacje te trzeba zdobyć we własnym zakresie, korzystając z danych bibliograficznych
umieszczonych na końcu rozdziału.
Dodatkowa zabawa z CVS
Istnieje jeszcze wiele innych poleceń i właściwości systemu CVS, o których nie wspomnieliśmy.
Poniżej omówimy te, z którymi należy się wcześniej zapoznać.
Pliki binarne
System CVS jest bardzo dobry  nie ma jednak rzeczy doskonałych; dlatego nie obsługuje on
obecnie plików binarnych tak dobrze, jak mógłby je obsługiwać. CVS można wykorzystać do
przechowywania plików binarnych, ale informację o tym należy do niego wprowadzić ręcznie.
Można to uczynić w dwojaki sposób: używając opcji -kb w poleceniu cvs add (jak już to
widzieliśmy wcześniej) lub użyć polecenia cvs admin -kb nazwa_pliku. Niestety, obydwa
polecenia działają tylko na pliki w repozytorium, a nie na ich kopie lokalne. Najlepiej więc
odnowić zwartość katalogu lokalnego, pobierając świeżą kopię do oczyszczonego katalogu.
Obecnie CVS nie może pokazywać różnic w plikach binarnych za pomocą polecenia diff.
Poprawianie błędnych adnotacji
Ludzką rzeczą są pomyłki i czasem podczas zmian w repozytorium zdarza się wstawić do logu
błędną informację. Taki dość często spotykany błąd można jednak naprawić. Aby zmienić
komunikat w logu dotyczący jakiejś specyficznej korekty pliku, należy użyć polecenia:
$ cvs admin -mrev:"New message"
Komunikat ten zastąpi komunikat wprowadzony poprzednio, po którym zaginie wszelki ślad,
należy zatem ostrożnie korzystać z tej właściwości.
Sieciowy dostęp do CVS
Jedną z najbardziej użytecznych właściwości systemu CVS jest jego zdolność do pracy w sieci.
Można udostępniać repozytorium w sieci na kilka sposobów, ale najpopularniejszą metodą jest
pserver (nazwa pochodzi od słów  password authenticating server ).
Usługi CVS korzystają zazwyczaj z portu o numerze 2401. Ten numer można w razie potrzeby
zmienić, ale w praktyce nie jest to stosowane. Ponieważ uruchomienie usług CVS nie obniża
znacząco wydajności komputera przy wykonywaniu zdalnych poleceń tego systemu, najlepiej
użyć do tego celu demona inetd, który będzie monitorował port i uruchamiał odpowiednią usługę
na żądanie.
Najpierw należy sprawdzić, czy usługi CVS są odpowiednio zdefiniowane i czy korzystają ze
standardowego portu. W pliku /etc/services powinien znajdować się następujący wpis:
Cvspserver 2401/tcp
Jeśli takiego wpisu nie ma, wóczas należy go dodać. Może się okazać, że istnieje wpis dla UDP,
ale normalnie system CVS korzysta z TCP. Istniejącego wpisu dla UDP nie należy usuwać.
Następnie trzeba zmodyfikować plik konfiguracyjny demona inetd, nakazując mu uruchamianie
serwera CVS po odebraniu wywołania żądającego dostępu do usług CVS.
W pliku /etc/inetd.conf musimy dodać następujący wiersz (cały tekst musi być podany w
jednym wierszu):
cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-
root=/usr/local/cvsrep
pserver
Należy sprawdzić, czy podana jest prawidłowa ścieżka do programu CVS oraz ścieżka do
repozytorium, które ma być udostępnione w sieci. Opcja allow-root informuje serwer CVS, że
zdalni użytkownicy są uprawnieni do korzystania z podanego repozytorium. Można użyć wielu
opcji allow-root, jeśli zachodzi taka konieczność.
Po tych operacjach zmuszamy inetd do ponownego odczytu pliku konfiguracyjnego:
# killall -HUP inetd
Możemy teraz sprawdzić, czy usługi CVS są dostępne, łącząc się przez telnet z podanym
portem. Wprawdzie nie uzyskamy w taki sposób dostępu do repozytorium, ale jest to najprostsza
metoda sprawdzenia poprawności działania serwera.
$ telnet localhost 2401
Po kilkakrotnym naciśnięciu klawisza Return powinniśmy zobaczyć coś takiego:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
cvs [pserver aborted]: bad auth protocol start:
Connection closed by foreign host.
Wiemy teraz, że serwer CVS jest dostępny na porcie 2401.
Aby dostać się w sposób zdalny do repozytorium, trzeba użyć polecenia o specjalnej postaci:
:pserver:uzytkownik@oddalony-komputer:sciezka-do-repozytorium polecenie
Spróbujmy teraz zalogować się przez sieć jako rick na komputerze gw1:
$ cvs -d :pserver:rick@gw1:/usr/local/cvsrep login
(Logging in to rick@gw1)
CVS password:
$
Od tego momentu można wydawać poprzez sieć polecenia CVS odnoszące się do oddalonego
repozytorium. CVS przechowuje hasła użytkowników w pliku ~/.cvspass, więc nie ma potrzeby
ponownego wpisywania hasła przed wylogowaniem. Czyż nie jest to proste? Niestety, taki sposób
postępowania ma kilka wad, z których najważniejszą jest obniżenie poziomu bezpieczeństwa
serwera. Użytkownicy logują się z sieci, korzystając ze swoich normalnych haseł, a metoda
przekazywania haseł stosowana przez pserver nie jest zbyt bezpieczna (mimo że nie jest tu
stosowane przesyłanie haseł w postaci niezakodowanej). Możemy poprawić bezpieczeństwo
systemu, oddzielając nazwy użytkowników korzystających z systemu CVS od nazw rzeczywistych
użytkowników oraz podając listę użytkowników uprawnionych do zapisu i odczytu w
repozytorium.
Załóżmy więc, że chcemy zezwolić użytkownikowi rick na dostęp do repozytorium, lecz pod
inną nazwą i z innym hasłem. Musimy w tym celu utworzyć plik o nazwie passwd w katalogu
/usr/local/cvsrep/CVSROOT.
Każdy wpis w tym pliku zawiera nazwę użytkownika stosowaną w systemie CVS, zaszyfrowane
hasło i rzeczywistą nazwę tego użytkownika używaną przy logowaniu na komputerze. Obecnie nie
ma prostego sposobu generacji zaszyfrowanych haseł z wiersza poleceń w systemie Linux, więc
można spróbować czasowo zmienić hasło na takie, które ma być użyte w systemie CVS, a
następnie skopiować je z pliku /etc/shadow (przy założeniu, że właśnie tam są przechowywane
hasła dostępu do komputera) do pliku CVSROOT/passwd.
Żądany wpis w tym pliku dla użytkownika rick, wykorzystywany tylko w systemie CVS, może
mieć następującą postać:
rick-cvs:HhyGFguuGuyiuhgiuGiuiuUhh:rick
Od tego momentu rick może załogować się zdalnie na serwer CVS, używając nazwy rick-cvs i
hasła innego niż przy normalnym logowaniu do komputera. Jeśli trzeba zmienić hasło zdalnego
użytkownika bez zmiany nazwy używanej przy logowaniu, należy po prostu pominąć w tym
wpisie końcową rzeczywistą nazwę użytkownika, a CVS sam zmieni go na jedną z nazw
użytkowników, którzy domyślnie mają pozwolenie na logowanie.
W taki sam sposób można umożliwić anonimowy dostęp do serwera CVS, tworząc rzeczywistą
nazwę użytkownika komputera i odwzorowując ją w pliku CVSROOT/passwd w nazwie
anonymous używanej przy logowaniu do CVS.
Oczywiście, nie można zezwalać na anonimowy zapis w repozytorium. W tym celu należy
utworzyć listę użytkowników mających faktycznie uprawnienia do zdalnego zapisu i odczytu
repozytorium. Jest to bardzo proste, bowiem w katalogu CVSROOT należy utworzyć dwa pliki:
jeden o nazwie readers i drugi o nazwie writers. Plik readers powinien zawierać nazwy
użytkowników uprawnionych tylko do odczytu, zaś plik writers  nazwy użytkowników
uprawnionych do zapisu. Ponieważ sama obecność pliku writers automatycznie oznacza
blokadę zapisu dla użytkowników, którzy nie są do niego wpisani, należy zawsze pamiętać o jego
utworzeniu. Obydwa pliki mają prostą strukturę wierszową, a w każdym wierszu podawana jest
nazwa użytkownika stosowana w systemie CVS. Jeżeli chcemy np. ograniczyć uprawnienia
użytkownikom neil i anonymous, zezwalając im tylko na odczyt, zaś rick ma być uprawniony
także do zapisu, to plik readers powinien mieć następującą zawartość:
neil
anonymous
W pliku writers należy wówczas wpisać:
rick
Klienty CVS z interfejsem graficznym
Do tej pory mówiliśmy jedynie o lokalnym i sieciowym korzystaniu z systemu CVS za pomocą
wiersza poleceń. Obecnie istnieje już kilka klientów wyposażonych w interfejs graficzny. Jako
przykład można podać interfejs Tk do systemu CVS, który można znalez
ć pod adresem
http://tkcvs.sourceforge.net/
Ponieważ system CVS może działać w sieci, użytkownicy mający do niego dostęp nie muszą
korzystać z systemu operacyjnego UNIX lub Linux. Powstał więc program WinCVS dostępny pod
adresem http://www.wincvs.org/
Wyjątkową przenośnością charakteryzuje się klient napisany w języku Java, który znajduje się
pod adresem http://www.jcvs.org/
Całkiem interesujące wydaje się korzystanie z systemu CVS poprzez przeglądarkę WWW. Tego
klienta można znalez
ć pod adresem http://stud.fh-heilbronn.de/~zeller/cgi/cvsweb.cgi/
Materiały z
ródłowe
W Internecie istnieje wiele materiałów z
ródłowych dotyczących CVS, a kilka z nich
prawdopodobnie jest już zainstalowanych w komputerze Czytelnika.
Najpierw należy zapoznać się ze stronami podręcznika systemowego man cvs lub informacjami
podawanymi przez info cvs. Jeśli to się nie uda, należy zajrzeć do /usr/doc/cvs-wersji>, gdzie najprawdopodobniej znajduje się więcej dokumentów na ten temat.
Dobrym punktem wyjścia do poszukiwań na stronach internetowych mogą być strony projektu
GNU pod adresem: http://www.gnu.org/software/cvs/cvs.html.
Adres http://www.cyclic.com jest także dobrym punktem wyjściowym. Należy zapoznać się
zwłaszcza z doskonałym dokumentem znanym jako  Cederqvist (od nazwiska autora Pera
Cederqvista). Lista interfejsów użytkownika, które można wykorzystać w systemie CVS, podana
jest pod adresem http://www.sourcegear.com/CVS/Dev/interface.
Pod adresem: http://goanna.cs.rmit.edu.au/~lukem/papers/3rdparty-and-cvs.html znajduje się
interesujący artykuł dotyczący zarządzania cudzym kodem z
ródłowym za pomocą CVS, napisany
przez Luke'a Mewburna.
CVS. Leksykon kieszonkowy; Gregor N. Prudy; (Helion, ISBN: 83-7197-473-6).
Jedną z książek, do której na pewno warto zajrzeć, jest Open Source Development with CVS Karla
Fogela (Coriolis, ISBN 1-57610-490-7). Pewne fragmenty tej książki są dostępne także w sieci 
należy zajrzeć na stronę WWW wydawnictwa Coriolis pod adres: www.coriolis.com.
Podsumowanie
W tym rozdziale omówiliśmy sposób korzystania z systemu CVS, czyli z wydajnego i bezpłatnego
narzędzia służącego do śledzenia zmian kodu podczas tworzenia oprogramowania. Obsługa wielu
użytkowników i dostępu przez sieć powoduje, że system CVS jest wybierany przez wielu
programistów jako podstawowe narzędzie do zarządzania wersjami kodu z
ródłowego.
Omówiliśmy sposób konfiguracji i korzystania z systemu CVS przez pojedynczego użytkownika i
przez wielu użytkowników łączących się za pośrednictwem sieci.
Wymieniliśmy także kilka klientów z interfejsem graficznym obsługującym CVS.
Ponieważ w systemie CVS dostępnych jest wiele poleceń, podajemy tu krótkie zestawienie poleceń
stosowanych najczęściej:
add
Dodanie nowego pliku lub katalogu do repozytorium.
admin
Interfejs administratora dla rcs.
checkout
Pobranie kodów z
ródłowych do edycji.
commit
Zatwierdzenie plików w repozytorium.
diff
Pokazanie różnic między korektami.
history
Pokazanie historii dostępu do repozytorium.
init
Utworzenie nowego repozytorium CVS (jeśli jeszcze nie istnieje).
log
Wyświetlenie informacji o historii plików.
release
Wydanie (uwolnienie) modułu oznaczające, że nie jest on już używany.
remove
Usuwanie wpisu z repozytorium.
status
Wyświetlenie informacji o statusie pobranych plików.
tag
Dodanie symbolicznego znacznika do pobranych wersji plików.
update
Modyfikacja wątku roboczego synchronizująca jego zawartość z repozytorium.
Dodatkową pomoc na temat dowolnego z powyższych poleceń można uzyskać, używając
polecenia cvs -H .
Polecenia CVS mają zawsze następującą składnię:
cvs opcja-ogólna polecenie opcja-polecenia [nazwy-plików]
Opcje ogólne dostępne dla większości poleceń CVS są następujące:
-d
Określanie używanego repozytorium.
-e
Określanie używanego edytora.
--help, -H Wyświetlenie informacji pomocniczych o danym poleceniu.
-n
Brak działania.
-q, -Q Brak komunikatów.
-t
Śledzenie działań.
-v, --version Wyświetlenie wersji CVS.
-z
Stopień kompresji używany podczas dostępu z sieci.