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 ź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 ź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 ź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 ź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:
q konfigurację CVS,
q opis zastosowania CVS do zarządzania projektem,
q sieciową instalację CVS umożliwiającą rzeczywistą pracę zespołową.
Kiedyś istniał tylko jeden sposób kontroli kodu ź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 źródłowym zamiast RCS:
q CVS można łatwo przystosować do pracy w sieci, a nawet w Internecie,
q CVS umożliwia jednoczesną pracę wielu programistów nad tym samym kodem źródłowym i w wielu wypadkach pozwala na automatyczne dołączanie zmian do projektu wprowadzanych przez różnych programistów,
q 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:
q konfigurację i zastosowanie CVS przez jednego użytkownika na komputerze lokalnym,
q konfigurację i korzystanie z CVS przez wielu użytkowników w sieci,
q 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 ź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 ź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.
Przed rozpoczęciem pracy z systemem CVS musimy zapoznać się ze stosowaną w nim terminologią:
q Pobranie (Check Out) — pobranie kopii jednego lub wielu plików z głównego źródła z zamiarem wprowadzania zmian w tych plikach.
q Zatwierdzenie (Commit) — wprowadzenie zmian dokonanych lokalnie w pliku źródłowym do głównej kopii tego pliku.
q Projekt (Project) — zbiór plików wchodzących w skład aplikacji.
q Repozytorium (Repository) — miejsce przechowywania głównej kopii kodu źródłowego w systemie CVS.
q 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 ź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.
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 ź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 ź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 ź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ń.
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 źródłowym.
CVS jest narzędziem uruchamianym z wiersza poleceń i taki interfejs będzie omawiany w tym podrozdziale. Póź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 <repository>
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 <editor>
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 <level>
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.
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.
...
mgram