KONFIGURACJA CVS MAREK GRZEŚ Streszczenie. Dokument stanowi instrukcję instalacji i podstawowej obsługi programu CVS. Zawarto w nim również krótki opis innych programów zarządzania wersjami takich jak RCS czy SCCS. 1. RCS - Revision Control System System RCS składa się z szeregu poleceń do zarządzania plikami źródłowymi. Jego działanie polega na śledzeniu zmian pliku źródłowego i utrzymywaniu pojedynczego pliku z listą zmian zwierającą szczegóły potrzebne do odtworzenia każdej poprzedniej wersji pliku źródłowego. Przykład użycia RCS: (1) utworzenie katalogu repozytorium mkdir RCS (2) dodanie pliku test.c do repozytorium (ang. check-in) ci test.c (3) pobranie pliku z repozytorium (ang. check-out) co test.c (4) pobranie pliku z blokowaniem go w repozytorium przed zmianami przez innych użytkowników co -l test.c (5) sprawdzenie różnic między plikiem roboczym a ostatnim zapisanym rcsdiff test.c (6) kiedy plik był zmodyfikowany bez blokowania, to wówczas uaktualnienie zmian można wykonać poleceniem rcs -l test.c (7) rejestrowanie zmian z utrzymaniem blokady do zapisu ci -l test.c (8) opcja -r pozwala wskazać kolejny numer wersji, bo domyślnie numeracja przebiega: 1, 1.1, 1.2, 1.3 itd. ci -r2 test.c (9) podobnie opcja -r pozwala pobrać określoną wersję pliku co -r2.1 test.c (10) informacje na temat zmian plików w repozytorium rlog RCS/* Date: 21 listopada 2005. Key words and phrases. CVS, RCS, SCCS, revision control. 1
2 KONFIGURACJA CVS 2. SCCS - Source Code Control System SCCS powstał w roku 1972 w Bell Telephone Laboratories. Oferuje on bardzo podobne funkcje do tych z RCS a. Tabela 1 stanowi porównanie podstawowych poleceń systemów RCS i SCCS. RCS SCCS rcs admin ci delta co get rcsdiff sccsdiff ident what Tabela 1. Porównanie poleceń RCS i SCCS [3, str. 309] 3. CVS - Concurrent Versions System Kontrola rewizji pozwala na to by można było odzyskać wcześniejsze wersje plików, śledzić zmiany i koordynować pracę zespołu programistów. Oprócz tego tworzyć odgałęzienia w rozwoju modułu i nanosić na jedną wersję zmiany powstałe niezależnie od siebie albo powstałe w innych wersjach. Kontrola ta polega na gromadzeniu specjalnych informacji na temat zmian projektu. Ponieważ CVS jest interfejsem do systemu RCS, dlatego zachowuje swoje informacje dotyczące kontroli wersji w plikach RCS przechowywanych w repozytorium. Jest ono oddzielone od katalogu roboczego użytkownika co pozwala organizować pracę zespołu programistów. System CVS działa w dwóch trybach: lokalnym i sieciowym. 3.1. Proces programowania z CVS. Proces programowania z użyciem CVS schematycznie przedstawiony został na rysunku 1. Szarym kolorem oznaczone zostały etapy, które z reguły trwają najdłużej. Pliki do edycji programista pobiera z repozytorium (cvs checkout) lub uaktualnia lokalną kopię pobierając zmiany (cvs update). Po dokonaniu zmian w lokalnych kopiach, są one zapisywane w repozytorium (cvs commit). W przypadku wystąpienia konfliktów konieczne jest ich rozwiązanie. 3.2. CVS w trybie lokalnym. W tym trybie CVS pozwala na tworzenie repozytoriów i dostęp do nich w ramach jednego komputera. Czynności konfiguracyjne polegają na utworzeniu katalogu, który będzie stanowił korzeń repozytorium. Podczas pracy z CVS em ścieżka do repozytorium może być podawana w opcji -d przy wywołaniu każdego polecenia CVS lub też może być przypisana do zmiennej środowiskowej CVSROOT. CVSROOT=/home/cvs export CVSROOT Repozytorium przed użyciem powinno zostać zainicjowane. Dla repozytorium, dla którego nie ustawiono zmiennej CVSROOT będzie to realizowane poleceniem: cvs -d /home/cvs init W przypadku kiedy zmienna ta zostanie ustawiana, opcję -d można pominąć i zastosować polecenie:
KONFIGURACJA CVS 3 Pobranie kopii cvs checkout Pobranie zmian cvs update Edycja plików cvs commit Konflikty? Nie Tak cvs update Rozwi¹ konflikt Rysunek 1. Proces programowania z użyciem CVS cvs init Zainicjowane repozytorium staje się użyteczne po dodaniu do niego plików projektów. Do CVS a można bezpośrednio kopiować pliki z RCS a, gdyż tak jak to było wspomniane CVS korzysta bezpośrednio z formatu RCS. Pomijając RCS, import do CVS a nowego projektu można przeprowadzić następująco: cvs import -m "First Project import" repository vendortag label Polecenie to w repozytorium dodaje moduł o nazwie repository i ładuje do niego pliki i katalogi z katalogu bieżącego. Opisane tu czynności pozwalają na stworzenie repozytorium i dodanie do niego plików projektu. Na takim projekcie można przeprowadzać operacje opisane w punkcie czwartym, które wyglądają identycznie zarówno w trybie pracy lokalnej jak i zdalnej. 3.3. CVS w trybie sieciowym. W praktyce edycja plików źródłowych odbywa się najczęściej na komputerach, na których nie jest przechowywane repozytorium. Z tego powodu konieczne jest użycie CVS a w trybie klient-serwer.
4 KONFIGURACJA CVS Generalnie, użycie zdalnego repozytorium jest identyczne jak lokalnego z wyjątkiem formatu nazwy repozytorium podawanego w opcji -d lub przypisywanego zmiennej CVSROOT: [:method:][[user][:password]@]hostname[:[port]]/path/to/repository Znaczenie parametrów występujących w tym wzorcu jest opisane przez ich nazwy. Wyjaśnienia wymaga nazwa method. Służy ona do określenia sposobu komunikacji. W tym punkcie omówiona zostanie metoda pserver, w której za komunikację sieciową i kontrolę dostępu do zasobów odpowiada CVS. 3.3.1. Konfiguracja serwera. W systemie Linux CVS uruchamiany jest przez xinetd (lub inetd). Z tego powodu należy stworzyć plik konfiguracyjny programu xinetd. Plik ten może mieć nazwę /etc/xinetd.d/cvspserver i przeznaczoną dla metody dostępu pserver zawartość: service cvspserver { port = 2401 socket_type = stream protocol = tcp wait = no user = root passenv = PATH server = /usr/bin/cvs server_args = -f --allow-root=/home/cvs pserver } Pod dodaniu tego pliku konieczne jest zresetowanie demona xinetd, np. poleceniem: /etc/init.d/xinetd restart Pozostałe czynności administracyjne związane z tworzeniem i inicjowaniem repozytorium są identyczne jak w konfiguracji lokalnej. 3.3.2. Kontrola dostępu do zasobów. Istotnym wymaganiem wobec systemów zarządzania wersjami jest kontrola dostępu do zasobów. W przypadku metody pserver CVS sam przeprowadza autoryzację użytkowników. Jeden ze sposobów polega na uwzględnieniu kont systemowych. Aby CVS pozwalał na dostęp z tych kont należy w pliku $CVSROOT/CVSROOT/config usunąć wpis: SystemAuth=no. Jeżeli taki wpis będzie, wówczas CVS nie uwzględnia kont systemowych a tylko te, które zostały podane w plikach konfiguracyjnych w katalogu $CVSROOT/CVSROOT. Jednym z tych plików jest $CVSROOT/CVSROOT/passwd. W pliku tym tworzy się użytkowników CVS, określa dla nich hasła oraz to na prawach jakiego użytkownika systemowego będą mieli dostęp do zasobów. Jeśli w systemie jest użytkownik bach i ma on dostęp do CVS a oraz w pliku passwd zrobi się wpis: anonymous::bach, wówczas poleceniem: cvs -d :pserver:anonymous@172.16.2.131:/home/cvs login można połączyć się z CVS em. W ten sposób klient będzie korzystał z konta o nazwie anonymous logując się w systemie na konto bach. Po ustawieniu SystemAuth=no nie można logować się do systemu jako bach. W podanym wyżej przykładzie użytkownik anonymous nie musiał podawać hasła. Chcąc określić hasło dla tego użytkownika należy w pliku passwd umieścić: anonymous:$1$uuszdht6$k/ffijt3m1zksa42nqkgj0:bach
KONFIGURACJA CVS 5 Między znakami dwukropka znajduje się zakodowane algorytmem jednostronnym 1 hasło cvstest. Po dodaniu hasła wykonanie polecenia: cvs -d :pserver:anonymous@172.16.2.131:/home/cvs login spowoduje, że użytkownik zostanie o nie poproszony. 3.3.3. Konfiguracja zdalnego klienta. W tym przypadku analogicznie jak w konfiguracji lokalnej parametry serwera i umieszczonego na nim repozytorium mogą być przypisane do zmiennej CVSROOT lub podawane przy każdym wywołaniu CVS a w opcji -d. Dla konfiguracji hasła ustawionego zgodnie z opisem konfiguracji serwera określonej w punkcie poprzednim odwołanie do repozytorium przyjmuje postać: :pserver:anonymous:cvstest@172.16.2.131:/home/cvs Przedstawione tu odwołanie do repozytorium można zastosować do pobrania modułu z repozytorium w następujący sposób: cvs -d :pserver:anonymous:cvstest@localhost:/home/cvs checkout test Istnieje również sposób pracy klienta pozwalający zalogować się do serwera CVS z jednokrotnym podaniem hasła. Można to zrealizować poleceniem: cvs -d :pserver:anonymous@localhost:/home/cvs login Podczas logowania klient proszony jest o podanie hasła. Kolejna odwołania do CVS a nie wymagają już podawania hasła oraz określania opisu repozytorium do momentu wylogownia z serwera. Wylogowanie odbywa się z użyciem polecenia: cvs -d :pserver:anonymous@localhost:/home/cvs logout 3.4. Dostęp zdalny z użyciem ssh. Oprócz metody dostępu pserwer opisanej wyżej CVS posiada między innymi metodę ext, która używa zewnętrznego programu (np. ssh lub rsh) do zestawiania połączeń między klientem i serwerem CVS. Metoda ta jest prawdopodobnie najczęściej używana. 3.4.1. Strona klienta. Aby po stronie klienta móc skorzystać z metody ext, trzeba mieć możliwość zalogowania się na serwer w oparciu o protokół ssh. Dostęp do zasobów CVS odbywa się w tym przypadku na podstawie kont ssh. Przy założeniu, że na komputerze o adresie 172.16.2.131 może zalogować się użytkownik bach, ustawienia zmiennych środowiskowych przedstawione niżej pozwalają na realizację komunikacji w oparciu o protokół ssh. CVSROOT=:ext:bach@172.16.2.131:/home/cvs export CVSROOT CVS_RSH="ssh" export CVS_RSH Ustawienia te pozwalają użytkownikowi korzystać z CVS w sposób opisany w punkcie czwartym z taką różnicą, że dla każdego wykonywanego polecenia będzie on proszony o podanie hasła. Aby uniknąć podawania hasła dla każdego polecenia, można programem ssh-keygen wygenerować klucze publiczny i prywatny i umieścić je odpowiednio na maszynie klienta i serwera (szczegóły konfiguracji w dokumentacji OpenSSH). 3.4.2. Strona serwera. W przypadku wykorzystania ssh nie jest potrzebny żaden proces serwera dla CVS. Za komunikację i zestawianie połączeń odpowiada w tym przypadku ssh. 1 można je skopiować z pliku /etc/shadow
6 KONFIGURACJA CVS 4. Podstawowe polecenia CVS W niniejszym punkcie przedstawione zostaną podstawowe polecenia CVS. Dotyczą one zarówno pracy w trybie lokalnym jak i zdalnym po stronie klienta. (1) pobranie plików z CVS a cvs checkout test (2) wysłanie uaktualnienia pliku test.c do CVS a cvs commit test.c (3) po zakończeniu lokalnych działań nad projektem nie jest wskazane kasowanie jego katalogu, należy zwolnić go poleceniem cvs release cvs release -d <dirtodel> (4) dodanie pliku do repozytorium (wymagane zatwierdzenie poleceniem cvs commit) cvs add filename (5) dodanie katalogu do repozytorium cvs add dirname (6) pobranie uaktualnień z CVS a cvs update (7) wysłanie uaktualnienia ze wskazaniem nowej numeracji wersji cvs commit -r 3.0 (8) wyświetlenie statusu pliku: ostatnia wersja, wersja w katalogu roboczym, itp. cvs status -v test.c (9) utworzenie etykiety symbolicznej cvs tag -c version-3. (10) pobranie plików z przypisaną etykietą cvs checkout -r version-3 test (11) wyświetlenie dziennika cvs log (12) wyświetla ostatnią modyfikację każdej linii pliku cvs annotate (13) przykładowy wynik powyższego polecenia: [marek@hurricane tmp]$ cvs annotate example1 Annotations for example1/header.h *************** 1.1 (marek 01-Oct-03): #define NAME "JOHN" Annotations for example1/test.c *************** 1.1 (marek 01-Oct-03): #include <stdio.h> 1.4 (marek 01-Oct-03): #include "header.h" 1.1 (marek 01-Oct-03): 1.1 (marek 01-Oct-03): int main(){ 1.5 (anonymou 02-Oct-03): printf("hello world\n"); 1.4 (marek 01-Oct-03): printf("%s\n",name); 1.1 (marek 01-Oct-03): return 0; 1.1 (marek 01-Oct-03): } [marek@hurricane tmp]$
KONFIGURACJA CVS 7 (14) usunięcie etykiety symbolicznej cvs rtag -d version-3 4.1. Rozgałęzienia (ang. branches - separate line of development). CVS nie jest ograniczony do zarządzania plikami w sposób liniowy. W bardziej rozbudowanych przedsięwzięciach (duża liczba plików, duża liczba programistów) zdarza się, że pojawia się konieczność przeprowadzenia pewnych prób alternatywnych, które nie zakłócą głównego nurtu programowania. W innej sytuacji potrzeba naprawić błędy w ostatnim wydaniu programu, w czasie gdy trwają już prace nad następnym wydaniem systemu. Drzewo rewizji może być zatem podzielone na gałęzie (ang. branches), gdzie każda gałąź jest oddzielnie utrzymywaną linią rozwoju. Zmiany dokonane w jednej gałęzi mogą być łatwo cofnięte do głównego pnia. (1) tworzenie rozgałęzienia; polecenie to rozdziela gałąź bazując na bieżących zmianach roboczej kopii i nowej gałęzi nadaje nazwę rel-1-0-p cvs tag -b rel-1-0-p (2) takie polecenie tworzy rozgałęzienie zakorzenione w rel-1-0 cvs rtag -b -r rel-1-0 rel-1-0-p tc (3) dostęp do rozgałęzień cvs checkout -r rel-1-0-p tc cvs update -r rel-1-0-p tc 4.2. Moduły. W katalogu $CVSROOT/CVSROOT umieszcza się pliki administracyjne między innymi plik modules, który specyfikuje moduły znajdujące się w repozytorium i przyporządkowuje im katalogi. Przykładowa zawartość tego pliku: CVSROOT CVSROOT modules CVSROOT modules doc gnu/doc W przykładzie tym plik modules wskazuje, że moduł doc odnosi się do katalogu gnu/doc. Literatura [1] Bronson Tan, Bolinger Don, Applying RCS and SCCS, O Reilly, 1995. [2] Fogel Karl, Open Source Development With CVS, http://cvsbook.red-bean.com/cvsbook.html [3] Neil Matthew, Stones Richard, Linux Programowanie, Wydawnictwo RM, Warszawa, 1999. [4] Version Management with CVS, http://ftp.cvshome.org/release/stable/cvs-1.11.7/cederqvist-1.11.7.pdf Politechnika Białostocka, Katedra Oprogramowania, ul. Wiejska 45A, 15-351 Białystok E-mail address: marekg@ii.pb.bialystok.pl URL: http://aragorn.pb.bialystok.pl/~marekg/