Krótki wstęp do pracy z CVS’em

CVS (’Concurrent Versioning System’) to, jak nazwa wskazuje, system kontroli wersji. Oznacza to mniej więcej tyle, że program śledzi zmiany nanoszone na poszczególne pliki (i nadaje każdej zmianie wersję) przez poszczególnych userów. Dzięki temu świetnie nadaje się on do pracy zespołowej – np. kilka osób pracuje nad jednym programem i dochodzi do sytuacji że 2 osoby jednocześnie pracują nad jednym plikiem. Jeśli obie ściągną dany plik powiedzmy przez FTP, poprawią, a potem jedna po drugiej nagrają spowrotem na FTP, to zmiany naniesione przez osobę, która przesłała ten plik wcześniej zostaną utracone.

CVS jest sprytny. Wie, nad którą wersją pracuje każdy użytkownik (informacja o tym znajduje się w podkatalogu CVS każdego katalogu ściągniętego z repozytorium). Np. 2 osoby pobierają wersję 1.4. Najpierw pierwsza osoba wrzuca swoje poprawki, więc CVS 'podbija’ numer wersji do 1.5. Podczas wrzucania poprawek przez drugą osobę, CVS widzi, że poprawiał on wersję 1.4, a w repo jest już 1.5, a więc są 2 wyjścia: albo automatycznie połączy poprawki, albo zgłosi konflikt – w katalogu zostanie zapisany plik zawierający 'konfliktowe’ poprawki – wystarczy chwilka aby zobaczyć jaki jest jego format i szybko, ręcznie połączyć
poprawki.

CVS to system, który w swoim katalogu (tzw. repozytorium) trzyma pliki w bardzo specyficznym formacie. Mianowicie zapisany jest podstawowy plik, informacje o zmianach w kolejnych wersjach, tzw. 'log messages’, czyli komentarze do nanoszonych poprawek i informacje o numerze wersji, ew. 'branchu’ (o tym dalej), tagach symbolicznych (o tym też dalej). Repozytorium podzielone jest na moduły – podkatalogi katalogu głównego repozytorium, z których każdy może być osobnym projektem. Specyficznym modułem jest moduł CVSROOT, który zawiera pliki konfiguracyjne CVS’u.

Tagi

Tagi są to znakowe identyfikatory przypisane konkretnym wersjom pliku. Np. plik z wersją 1.234 może mieć taga stable lub devel lub cokolwiek. Tagi można przesuwać, np. po uznaniu wersji 1.534 za stabilną, można przesunąć tag stable z wersji 1.234 na 1.534. Tagi mogą się powtarzać, czyli tag stable może istnieć dla pliku main.cpp i dla pliku grafika.cpp, przy czym nie musi on dotyczyć tej samej wersji – stabilna może być wersja 1.234 pliku main.cpp i 1.534 pliku grafika.cpp. Jest to świetne rozwiązanie, ponieważ można jako parametr do checkout’a (co to jest – niżej) użyć opcji -r numer_wersji_lub_tag i pobrać cały projekt w wersji stable.

Branche

Istnieje także bardzo specyficzny rodzaj tagu, który nosi nazwę branchu. Nie bez powodu nazywa się on 'gałęzią’. Załóżmy że jest sobie projekt. Wydana została jakaś wersja, po czym uznano, że projekt ma 2 drogi, np. wersja korzystająca ze zdalnego serwera i ta pracująca lokalnie. Niby to 2 osobne projekty, ale pochodzą ze wspólnego źródła i być może w przyszłości będą wymieniane pliki pomiędzy nimi. Wtedy robi się tzw. brancha. Pozwala to na równoległe zapisywanie zmian w dwóch lub więcej odgałęzieniach projektu. Branch jest określany także jako 'sticky tag’, ponieważ jeśli zrobi się checkout z parametrem „-r nazwa_branchu”, to ta nazwa jest trzymana przez cały czas, jeśli doda się plik w tym projekcie, to CVS będzie wiedział, że ten plik ma być dodany _tylko_ na tym branchu. Jeśli chce się zmienić branch, to trzeba skasować starą lokalną kopię i zrobić jeszcze raz checkout. Istnieje też możliwość późniejszego ponownego połączenia branchy. Służy do tego parametr „-j nazwa_branchu” dla poleceń 'update’ i 'checkout’. Powoduje on połączenie najnowszej wersji programu (tej bez żadnego brancha) z branchem podanym jako parametr. Można też połączyć 2 podane branche łącząc parametry -j i -r.

Watch

CVS ma też bardzo ciekawą możliwość blokowania edycji. Oznacza to, że jedna osoba informuje CVS, że ona teraz zajmuje się tym plikiem i nanoszenie poprawek przez inne osoby jest zablokowane. Nie napiszę o tym nic więcej bo się tym nigdy nie bawiłem. Jeśli kogoś będzie to interesować to niech przeczyta część 'info cvs’ – rozdział „Multiple developers”.

Są 3 sposoby korzystania z CVSu:

• local – bezpośrednie czytanie z plików repozytorium
• pserver – korzystanie z serwera uruchamianego przez CVS na porcie 2401 (w tym przypadku niezbędne jest logowanie do serwera CVS)
• ext – korzystanie z serwera zdalnie, ale poprzez zewnętrzny program, taki jak rsh (domyślnie) lub ssh (program można podać korzystając ze zmiennej środowiskowej CVS_RSH)

Każdy klient usługi CVS do korzystania z plików przechowywanych w
repozytorium musi dostać następujące informacje:

• typ połączenia (local, pserver, ext)
• w przypadku pserver i ext: nazwa serwera, użytkownik i hasło
• katalog z repozytorium

Powyższe dane klienci uniksowi pobierają jako jeden ciąg znaków.

Dla typu local

":local:katalog_z_repozytorium", np. ":local:/home/cvsroot"

Dla typu ext:

":ext:user@komp:katalog_z_repozytorium", np. ":ext:leon@valis.faq.pl:/home/cvsroot"

Dla typu pserver:

":pserver:user@komp:katalog_z_repozytorium", np. ":pserver:leon@valis.faq.pl:/home/cvsroot"

A teraz polecenia. Wszystko robi się za pomocą polecenia 'cvs’,
ale z różnymi parametrami. Po kolei:

cvs login

Tego chyba nie trzeba tłumaczyć. Loguje się do CVS’u, jeśli łączysz się z nim zdalnie.

cvs co nazwa_modułu

’co’ to skrót od 'checkout’ (można używać obu nazw jako parametr) – wstępne pobranie danego modułu na lokalny komputer. Na takiej kopii się pracuje, nanosi poprawki itp. 'co’ używane jest tylko za pierwszym razem. Później używa się 'up’. Jak już napisałem wyżej, można użyć dodatkowy parametr (przed nazwą modułu) -r xxx, gdzie xxx może być numerem wersji lub tagiem.

cvs up [pliki]

’up’ = 'update’. Uaktualnienie lokalnej kopii i/lub repozytorium. Takie uaktualnienie w obie strony. Jeśli na plik jest nowszy na serwerze, to go ściąga. Jeśli nowszy na lokalnym dysku to notuje to przesłania przy commit’cie lub informuje o konflikcie. Jeśli nie poda się pliku/plików, to aktualizuje aktualny katalog z podkatalogami. Tu także można użyć parametru -r takiego jak przy 'co’.

cvs commit [pliki]

Ostateczne potwierdzenie wysłania zaktualizowanych/dodanych plików do repozytorium. Przed wysłaniem CVS poprosi o wpisanie komentarza do poprawek (’log info’; tylko jeśli nie został podany parametr -m „treść log info”).

cvs add plik/katalog

Zanotowanie pliku/katalogu do dodania. Ostateczne dodanie następuje po wykonaniu commit’a.

cvs tag nazwa_tagu plik(i)

Nadanie tagu o podanej nazwie podanym plikom. Tag będzie przypisany do wersji aktualnie posiadanej w lokalnej kopii, lub innej jeśli podany będzie parametr -r (opis jak wyżej). Można użyć także parametru -F (tag zostanie nie nadany, tylko przesunięty) lub -d (usunięcie zamiast nadania tagu). Parametr „-b nazwa_branchu” robi nowy branch.

cvs remove plik

Usuwa katalog z repozytorium. Jeśli nie zostanie podany parametr -f, to przed usunięciem z repo plik musi być usunięty z lokalnej kopii. Jeśli użyje się opcję -f, to cvs zrobi to sam.

Istnieje możliwość zapisania najczęściej używanych opcji na stałe
w pliku ~/.cvsrc . Mój plik wygląda tak:

cvs -z3
update -d -P
checkout -P
diff -u

Pierwsza linia oznacza, że przesyłane dane będą najpierw kompresowane gzipem na poziomie 3. Druga oznacza, że budowana będzie struktura katalogów i usuwane puste katalogi przy update. Trzecia, że usuwane będą puste katalogi przy checkout. Czwarta określa format pokazywania diffów