o CVS po polsku
1. WprowadzenieWiedza na temat narzędzi ułatwiających koordynowanie grupowych przedsięwzięć informatycznych, w Polsce jest niemal szczątkowa. Tyle się mówi o pracy grupowej uzywając tu jako przykładów pseudonarzędzi z Win* zapominając, że jednymi z pierwszych, i do dzisiaj najczęściej używanymi narzędziami, są CSSC czy RCS. CVS stanowi o wiele bardziej dojrzały produkt. O ile np. RCS (Revision Control System) operuje na pojedynczych plikach, to CVS na niższej warstwie wykorzystując technologię RCS umożliwia operowanie na katalogach czy też całych projektach. W tej chwili większość projektów OSS, w których bierze udział czasami nawet niewielka grupa, jest składowanych w CVS. Przykładami mogą być choćby GNOME, mutt czy KDE.
2. Jak wygląda praca w CVS?W jakimś punkcie sieci zorganizowane jest repozytorium dokumentów. Jest to swego rodzaju baza umożliwiająca przechowywanie informacji o wszystkich zmianach czyli o tym kto, kiedy i jakie zamiany wykonał. Aby móc operować na zasobach repozytorium trzeba mieć konto powiązane z hasłem. Zazwyczaj w repozytorium zakłada się też konta typu anonymous, nobody czy cvs, na które hasło jest ogólnie znane i opublikowane, ale jednocześnie poprzez to konto można operować jedynie w trybie 'tylko do odczytu'.
3. Co daje CVS?Podstawowym atutem używania tego typu narzędzi jest minimalizowanie konieczności kontaktowania się między osobą chcącą dokonać zmiany, a resztą zespołu. Nawet jeżeli osoba wykonująca zmianę wprowadzi coś nieprawidłowego czy cokolwiek nieopatrznie skasuje (o tym dalej), fakt ten nie niesie za sobą niemal żadnych konsekwencji, gdyż od czasu do czasu osoba mająca pieczę nad całościa (tzw. release manager) przegląda co było zrobione, i w każdej chwili może zdecydować czy daną zmianę zakceptuje zbierając przy wypuszczaniu kolejnej wersji całych źródeł z czoła zmian, czy też nie. W każdej chwili ktokolwiek inny może nanieść poprawkę usuwającą jakąś niedoróbkę po jej pechowym wprowadzeniu. Cofania zmian raczej się nie praktykuje. Kasowanie zasobu również nie jest niebezpieczne, gdyż nie kasuje go fizycznie, a jedynie przenosi do zbioru rzeczy skasowanych; cofnięcie kasowania można dokonać w każdej chwili przenosząc po prostu plik z opisem zasobu do głównego drzewka. Warunki, jakie tworzy CVS, są unikatowe. Umożliwiają one pracę grupie ludzi, która nie musi się znać, mieć do siebie nieogranicznonego zaufania. Praktyczną konsekwencją powyższego jest to, że dostęp do zasobów w trybie 'odczyt i zapis' jest autoryzowany w symbolicznej formie i pozwala to na przeprowadzenie autoryzacji tylko raz w momencie pierwszego dostępu do zasobów, co znacznie ułatwia pracę bardziej aktywnym współudziałowcom projektu.
4. Jak przebiega typowa sesja pracy z wykorzystaniem CVS?Zanim zacznie się pracę, pierwszym ruchem jest uzyskanie dostępu w trybie 'odczytu i zapisu' do zasobów. Odbywa się to tak, że osoba zgłaszająca się dostarczyć musi zakodowane standardową funkcją crypt() hasło. Może to zrobić każdy za pomocą np. perla: $ perl -e 'print crypt "password", "salt"; print "\n"; ' gdzie <password> to hasło jakim osoba potem będzie się posługiwać przy dostępie do repozytorium, a <salt> to dwie dowolne litery. Osobie zarządzającej repozytorium dostarcza się więc parę: <login>:<crypted_password> Wymagany jest zwykle również adres poczty elektronicznej współtwórcy OSS, dzięki któremu będzie można się z nim łatwo kontaktować (np. w celu informowania o przerwach w działaniu repozytorium, etc.) Niezwłocznie po dodaniu użytkownika, może on rozpocząć pracę. Przykład, jakim się tu posłużę, będzie się opierał na zasobach PLD. Pierwsza sprawa to zalogowanie się: $ cvs -d :cvs -d :pserver:kloczek@cvs.pld.org.pl:/cvsroot login (Logging in to kloczek@cvs.pld.org.pl) CVS password: <tu wklepuję własne hasło> Po poprawnym podaniu hasła w pliku ~/.cvspass pojawi się wpis dotyczący dostępu do tego konkretnie repozytorium wraz z postacią zakodowaną hasła, które potem automatycznie będzie używane przy kolejnych kontaktach. Teraz można przystąpić do odczytania zasobów repozytorium. Tu jedna uwaga. Zamiast za każdym razem podawać dla cvs pełną scieżkę "-d :pserver:.." mogę ustawić sobie zmienną w środowisku powłoki: CVSROOT=":pserver:kloczek@cvs.pld.org.pl:/cvsroot" Teraz bedzie już krócej i pierwsze pobranie zasobu wyglądać będzie tak: $ cvs get SPECS W tym momencie rozpocznie się ściaganie modułu SPECS z repozytorium na lokalny dysk twardy, do obecnej scieżki, w której znajduje się użytkownik. Czasami, gdy kontakt z repozytorium jest ograniczony jakimś wąskim gardłem, można transmisję kompresować za pomocą gzipa: $ cvs -z9 get SPECS Po tym wszystkim w bieżącym katalogu powstanie (w naszym przykładzie) katalog roboczy SPECS ze wszystkimi plikami jakie są w tym module. Co mogę zrobić z tym co ściągnąłem? Mogę przeglądać aktualne zbiory (to oczywiste), moge przeglądać historię zmian i status poszczególnych plików za pomocą poleceń: $ cd SPECS $ cvs log <plik> $ cvs status <plik> jak i historię wszystkich zmian jakie były wykonywane, za pomocą np. skryptu, który przychodzi wraz z CVSem, przez wydanie polecenia: $ rcs2log | less Po przejrzeniu i poprawieniu (modyfikuję przykładowo jeden z plików) można dokonać dołączenia mojej zmiany do zasobów repozytorium przez polecenie: $ cvs commit <plik> lub krócej: $ cvs ci <plik> W tym momencie zostanie wywołany domyślny edytor systemu (określony zwykle w zmiennej powłoki $EDITOR) i będzie można skomentować tę zmianę (komentarz jest potem widoczny np. przy przeglądaniu repozytorium za pomocą rcs2log czy "cvs log"), a po wyjściu z edytora, zmiana zostanie wysłana do repozytorium. Załóżmy, że jest kilka osób które już coś danego dnia zmodyfikowały. Co wykonać przed rozpoczęciem pracy ? Otóż pierwszą czynnością powinno być uaktualnienie moich własnych zasobów względem repozytorium czyli: $ cd SPECS; cvs -z9 update Zostaną dociągnięte wszystkie zmiany, a po przejrzeniu loga za pomocą rcs2log mogę rozpocząć własne prace. Co by się stało, gdybym nie wykonał synchronizacji modyfikując jakiś plik, który dzisiaj już zmodyfikowała inna osoba? Nie ma strachu. Przy próbie zrobienia commit zostałby wyświetlony komunikat, że moje własne zasoby nie zostały zsynchronizowane względem repozytorium i że najpierw powinienem to właśnie zrobić. Żeby jednak już nie stracić zmian jakie zrobiłem, moge sobie wygenerować diffa względem repozytorium, którego potem wykorzystam przez: $ cvs diff <plik> > plik.diff i wykonać już update czyli: $ cvs update <plik> po wyłączeniu własnych zmian: $ patch < plik.diff i sprawdzeniu co z tego w efekcie końcowym wyszło - można już zrzucić do repozytorium moją robotę: $ cvs ci <plik> Powyższy opis to tylko początek możliwości jakie kryją się w CVS. CVS jest skomplikowany. Osoby używające [x]emacsa mogą skorzystać z kilku funkcji podpiętych pod menu do pracy z repozytorium CVS. Jest także dostępnych wiele innych narzędzi dodatkowych służących do operowania na zasobach CVS.
5. Informacje techniczne dotyczące obsługi CVS dla PLDListy z prośbami o założenie indywidualnego konta do odczytu i zapisu należy kierować pod adres: pld-cvs@pld.org.pl. W krótkim czasie zgłoszenie zostanie potwierdzone. PLD dysponuje możliwością przeglądania repozytorium przez WWW: http://cvs.pld.org.pl/
6. odpowiedzi na najczęściej zadawane pytania:Pytanie1: Gdzie mogę znaleźć obszerny podręcznik CVSa? Odpowiedź1: Na http://pl.qmail.org/~ser/doc/cvs.html znajdziesz porządny (i długi!) podręcznik CVSa. Niestety tylko po angielsku!
Pytanie2: Ojej, to mowisz, ze mam sobie instalowac cvs? ;) To jest pojedyncza binarka (klient) .. paręset KB ;) Właśnie sobie skompilowałem. Można to jakoś domowo potestować? Odpowiedź2: Zapewne chodzi Ci o próby z własnym repozytorium. Tak można. $ mkdir <katalog> $ export CVSROOT=":pserver:kloczek@cvs.pld.org.pl:/cvsroot" $ cvs init $ cd pl_PL $ cvs add man*/*.* $ cvs ci -m "initial version" man*/*.* Tak może wyglądać zainicjowanie własnego repozytorium. Bardziej poprawna inicjacja modułu powinna jeszcze zawierać po wykonaniu "cvs init" ściągniecie modułu CVSROOT: $ cvs get CVSROOT i po edycji pliku modules zrzucenie go do modułu CVSROOT. Więcej szczegółów mozna znaleźć w instrukcji o której mowa w pytaniu1. Pytanie3: Jak wyciągnąć list plików w danym module bez ich ściągania? Odpowiedź3: Najprościej przez "cvs status | grep File".
(c) by tomasz kłoczko i sergiusz pawłowicz 1999, wszystkie prawa zastrzeżone. |