Praca z CVS w GentooTekst składa się z dwóch części. Pierwsza pokazuje jak używać CVS nie będąc deweloperem, tj. jak pobierać źródła z serwera CVS i sprawić żeby cały czas były aktualne. Druga część wprowadza w świat CVS widziany oczami dewelopera, wyjaśniając jak modyfikować, dodawać lub usuwać pliki w CVS i wykonywać inne deweloperskie operacje. Jeśli CVS jest dla kogoś zupełnie obcy, zalecane jest by zacząć czytać ten dokument od pierwszej części, a dopiero potem przystąpić do drugiej; jeśli natomiast posiadamy podstawową wiedzę na temat CVS, a chcielibyśmy zacząć używać go jak deweloperzy, to wszystko co powinniśmy wiedzieć znajdziemy w części drugiej. Można także przeczytać część wcześniejszą by odświeżyć swoją wiedzę. CVS jest systemem bazującym na zasadzie klient-serwer pozwalającym deweloperom przechowywać ich dokumenty w wybranym miejscu, nazywanym repozytorium. Za pomocą narzędzi oferowanych przez klienta CVS, deweloperzy mogą wprowadzać zmiany w zasobach repozytorium. Z kolei repozytorium CVS śledzi każdą zmianę dokonaną na jakimkolwiek pliku, tworząc historię niejako danego projektu. Deweloperzy mogą pobierać starsze wersje wybranego pliku źródłowego, przeglądnąć dziennik zmian i wykonywać inne potrzebne operacje. Wiele projektów Open Source posiada własne repozytoria CVS, które są wykorzystywane jako podstawowe środowisko pracy dla ich deweloperów. CVS umożliwia współpracę wielu rozsianych po całym świecie osób. Pozwala na dokonywanie zmian w tym samym kodzie przez wiele osób tak, aby wzajemnie sobie w tym nie przeszkadzały. Przy okazji uniemożliwia utratę jakichkolwiek danych czy naniesionych poprawek. CVS - najbardziej aktualne deweloperskie źródła Kiedy deweloperzy zdecydują, że ich projekt (na przykład po dodaniu nowych funkcji lub wprowadzeniu poprawek) osiągnął odpowiedni poziom, wypuszczają go w formie tar.gz. będącej kompilacją ich pracy zawartej w repozytorium; jest to zarazem kolejna oficjalna wersja programu. Niestety, często zdarza się, że ostatnie oficjalne wersje nie są zbyt aktualne z wielu różnych przyczyn. W pierwszej części tego tekstu wyjaśnione zostanie jak wykorzystać CVS by sprostał temu zadaniu - pobierając najnowsze i najlepsze deweloperskie wersje plików źródłowych na własny użytek. Aby zainstalować CVS, wystarczy wpisać polecenie emerge cvs:
Zanim zaczniemy podróż po cudownym świecie CVS, ważne jest by poznać podstawy. Pierwszą rzeczą, którą każdy początkujący musi wiedzieć jest to, że aby połączyć się z repozytorium musimy znać jego ścieżkę nazywaną "CVSROOT". CVSROOT jest ciągiem znaków, tak jak URL, który mówi poleceniu CVS gdzie znajduje się zdalne repozytorium i jak chcielibyśmy się do niego podłączyć. Sprawa robi się jeszcze bardziej interesująca, gdyż faktem jest, że w CVS wyróżnia się kilka różnych formatów CVSROOT, zależnie od tego czy repozytorium znajduje się na naszym czy obcym komputerze oraz w jaki sposób zamierzamy połączyć się z danym repozytorium. Teraz wymienimy kilka przykładów CVSROOT razem z objaśnieniami.
To jest przykład lokalnej ścieżki CVSROOT. Tę ścieżkę stosuje się gdy zamierzamy podłączyć się do lokalnego repozytorium istniejącego pod adresem /var/cvsroot; albo gdy repozytorium zamontowane zostało za pomocą NFS pod tym samym adresem. Zdalny serwer CVSROOT używający protokołu password
Oto przykład CVSROOT dla zdalnego repozytorium znajdującego się na komputerze o adresie foo.bar.com i egzystującego w katalogu /var/cvsroot na tej stacji roboczej. Pierwsza część (":pserver:") mówi naszemu klientowi, aby podłączył się do zdalnego komputera używającego protokołu haseł serwera CVS, który wbudowany jest w CVS. Zazwyczaj publiczne repozytoria CVS używają protokołu haseł, aby umożliwić dostęp użytkownikom anonimowym. CVSROOT wraz z szyfrowaniem RSH/SSH
Ten przykład pokazuje CVSROOT korzystający z protokołu RSH/SSH. W tym przyładzie serwer CVS będzie próbował nawiązać połączenie z repozytorium foo.bar.com używając konta drobbins. Jeśli zmienna środowiskowa CVS_RSH ma wartość "ssh" to nasz klient będzie się starał użyć ssh do nawiązania połączenia. W innym przypadku użyje RSH. Łączenie się za pomocą SSH jest popularne wśród osób, które dbają o swoje bezpieczeństwo; jednakże żaden z tych protokołów nie umożliwia pobierania źródeł przez klienta anonimowego. Zatem, aby użyć tych protokołów musimy posiadać konto na foo.bar.com. Oprócz CVSROOT będziemy musieli poznać nazwę modułu (kolekcji źródeł), który chcielibyśmy zobaczyć, a także hasło użytkownika anonimowego, jeśli chcemy połączyć się z serwerem używającym protokołu haseł CVS. Inaczej niż w przypadku anonimowego serwera ftp, nie ma standardowego formatu hasła dla użytkownika anonimowego, dlatego też potrzebne będzie pobranie danego hasła ze strony deweloperskiej. Jeśli mamy w posiadaniu te informacje, możemy przystąpić do odkrywania kolejnych sekretów CVS. Pobieranie źródeł to proces dwuetapowy. Na początku logujemy się do serwera haseł. Następnie pobieramy zasoby używając komendy checkout. Oto przykładowy zestaw poleceń, które mogą być wykorzystane do sprawdzenia najnowszych zasobów Samby, popularnego projektu, którego celem jest integracja środowisk Unix i Windows:
Pierwsza komenda ustawia zmienną środowiskową CVSROOT. Jeżeli nie ustawimy tej zmiennej, poniższe dwa polecenia będą wymagały dodatkowo dopisania-d :pserver:cvs@pserver.samba.org:/cvsroot po komendzie cvs. Eksportowanie zmiennej CVSROOT oszczędza nam wiele pisania. Te komendy pozwalają pobrać aktualną kopię źrodeł deweloperskich. Jeśli mamy ochotę, możemy skoczyć do przodu, do nowej sekcji, by przeczytać wyjaśnienie tych poleceń, a następnie wrócić tu ponownie:
Pierwsza komenda (powyżej) loguje nas do pserver, a kolejna mówi naszemu klientowi CVS by wypożyczyć (ang. check out; komenda: "co") moduł samby używając kompresji gzip na poziomie 5 ("-z5"), aby przyspieszyć transfer przy wolnym łączu. Dla każdego nowego pliku, który jest tworzony lokalnie, cvs wypisuje "U [ścieżka]" informując, że ten określony plik został zaktualizowany na naszym dysku. Kiedy komenda wypożyczenia ("co") wykona swoje zadanie, ujrzymy katalog "samba" w katalogu, w którym obecnie się znajdujemy; przechowywane będą tam najnowsze zasoby. Zauważyć można, że wszystkie katalogi mają dodatkowy katalog CVS znajdujący się wewnątrz nich - w ten właśnie sposób CVS przechowuje informacje dotyczące konta użytkownika. Owe katalogi można spokojnie pominąć i zapomnieć o nich. Odtąd nie będziemy musieli się martwić ustawianiem zmiennej CVSROOT, czy też przymusem wpisywania wartości CVSROOT w lini poleceń. Dzieje się to dlatego, że te dane są zapisane właśnie we wcześniej wspomnianych katalogach. Ustawienie zmiennej CVSROOT jest wymagane tylko przy początkowej incicjalizacji oraz wykonywaniu polecenia "co". A oto nasze najnowsze źródła! Gdy już je posiadamy, możemy je skompilować i zainstalować, obejrzeć albo zrobić z nimi co tylko nam się podoba. Co jakiś czas prawdopodobnie będziemy chcieli zsynchronizować nasze źródła z tymi na serwerze CVS. Aby wykonać tą operację nie musimy ponownie logować się do pserver - te informacje (dane uwierzytelniające) są już przechowywane w katalogach o których wcześniej wspominaliśmy. Na początku otwórzmy główny katalog, w którym dokonaliśmy operacji wypożyczenia (w naszym przypadku "samba") i napiszmy:
Jeśli na serwerze znajdują się jakieś nowe pliki, cvs zasygnalizuje to wypisując jeden wiersz "U [ścieżka]" dla każdego wystąpienia nowego pliku. Jeśli kompilowaliśmy źródła, zapewne zauważymy dużo wierszy typu "? [path]"; są to pliki obiektowe, które cvs definiuje jako te, które nie odpowiadają żadnym plikom w repozytorium. Zauważmy również dwie opcje lini poleceń które użyliśmy w "cvs update". "-d" mówi cvs, aby ten stworzył nowe katalogi, jeśli te wystąpiły w repozytorium (nie dzieje się to domyślnie), a "-P" informuje iż cvs powinien usunąć puste katalogi z lokalnie wypożyczonych kopii plików. Używanie "-P" to naprawdę dobry pomysł ponieważ cvs ma skłonność do tworzenia dużej liczby pustych (użytych raz, a następnie porzuconych) gałęzi drzewa. Jeśli chodzi o proste pobieranie najnowszych zasobów, to wszystko co trzeba wiedzieć. Teraz przyjrzyjmy się pracy z CVS jako deweloper. Bycie deweloperem wymaga od nas modyfikacji plików znajdujących się na serwerze CVS. Aby dokonać tych zmian wystarczy wprowadzić je w plikach obecnych w naszej lokalnej kopii repozytorium. Zmiany w zasobach nie zostaną naniesione do plików w zdalnym repozytorium dopóki nie polecimy CVS, aby zatwierdził (ang. commit) zmiany. Kiedy sprawdzimy zmiany przez nas dokonane i będziemy mieli pewność, że możemy wprowadzić zmiany w repozytorium, musimy przejść przez dwufazowy proces. Na początku zaktualizujemy zasoby poprzez wypisanie poniższych komend w głównym katalogu źródłowym:
CVS scala zmiany wprowadzone przez innych Jak zauważyliśmy wcześniej, "cvs update" sprawi, że nasze zasoby będą w pełni aktualne z wersją obecną w repozytorium - ale co się stanie ze zmianami, które sami wprowadziliśmy? Nie należy się obawiać - nie zostaną one odrzucone. Jeśli inny deweloper wprowadzi zmiany do pliku, którego nie edytowaliśmy, nasz plik lokalny będzie dokładnym odzwierciedleniem pliku zawartego w repozytorium. Jeśli zmodyfikowaliśmy wiersze 1-10 pliku lokalnego, a inny deweloper usunął wiersze 40-50 i dodał 12 nowych wierszy na końcu pliku, zmodyfikował wiersze 30-40, a potem zatwierdził zmiany w repozytorium zanim to nam udało się je wprowadzić, cvs inteligentnie scala te zmiany w twoim lokalnym pliku, tak że żadna ze zmian wprowadzonych przez ciebie nie zostanie utracona. To pozwala dwóm lub większej liczbie deweloperów pracować na różnych częściach jednego pliku w tym samym czasie. Jednakże kiedy dwóch lub więcej deweloperów wprowadziło zmiany do tego samego obszaru w jednym pliku, sprawy robią się trochę bardziej skomplikowane. Jeśli to się zdarzy, cvs poinformuje nas, że zaistaniał konflikt. Żadna praca nie zostanie utracona, ale będzie wymagana własnoręczna edycja, ponieważ cvs wymaga od nas by to właśnie użytkownik "pokazał" programowi jak ma scalać te dwie zmiany. Za chwilę przyjrzymy się sposobom rozwiązywania konfliktów, a teraz załóżmy, że konflikty nie występują i wpisaliśmy "cvs update -dP". Warto wspomnieć, że w większości przypadków takie problemy nie występują. Bez konfliktów nasze pliki są zaktualizowane i jesteśmy gotowi do zatwierdzenia zmian, więc wystarczy, że wpiszemy następujące polecenia (musimy być w głównym katalogu źródłowym):
"cvs commit" nie tylko zatwierdza nasze zmiany w repozytorium, ale zanim prześle je do zdalnego repozytorium, cvs uruchomi domyślny edytor i pozwoli na krótkie opisanie modyfikacji, które wprowadzamy. Po wprowadzeniu komentarzy, zapisaniu pliku i wyjściu z edytora, nasze zmiany zostaną wprowadzone w zdalnym repozytorium i będą dostępne dla wszystkich deweloperów w zespole. Stosunkowo łatwe jest przeglądanie całościowej historii określonego pliku wraz z komentarzami wprowadzonymi przez deweloperów (włączając w to nas), które mogli wpisać podczas wprowadzania zmian. W celu przeglądnięcia tych informacji piszemy:
Komenda "cvs log" jest rekursywna, co oznacza, że jeżeli zajdzie potrzeba przeglądnięcia dziennika dla całego drzewa katalogów, wystarczy otworzyć dany katalog i wpisać:
Gdy domyślny edytor wybrany przez cvs nie odpowiada użytkownikowi istnieje możliwość samodzielnego doboru edytora przy wprowadzaniu komentarzy po wykonaniu komend "cvs commit". W takim wypadku należy ustawić zmienną środowiskową EDITOR na nazwę edytora, który akurat nam odpowiada. Wprowadzenie takiego ustawienia w pliku ~/.bashrc będzie dobrym pomysłem:
Alternatywnie można określić wiadomość dziennika jako opcję linii komend tak, aby cvs nie musiał ładować edytora na pierwszym miejscu:
Przed opisaniem kolejnych komend cvs, zalecane jest ustawienie pliku ~/.cvsrc. Poprzez stworzenie pliku .cvsrc w katalogu domowym można przekazać do cvs wybrane opcje linii poleceń i ustawienie ich jako domyślnych, co pozwala uniknąć przymusu pamiętania tych opcji i wpisywaniu ich za każdym razem. Oto proponowany domyślny plik .cvsrc:
Oprócz ustawienia kilku pomocnych opcji dla komend cvs, pierwsza linia .cvsrc wprowadza cvs w stan milczenia, co ma znacząco pozytywny wpływ na wyjście cvs update, które staje się w ten sposób bardziej zwarte i przejrzyste. Po zmodyfikowaniu .cvsrc, możemy napisać cvs update zamiast cvs update -dP. Dodawanie pliku do repozytorium Jest naprawdę łatwo dodać plik źródłowy do CVS. Na początku, tworzymy plik za pomocą ulubionego edytora. Następnie napiszmy to co poniżej:
To nakaże cvs dodanie pliku do repozytorium następnym razem gdy użyjemy komendy cvs commit. Dopiero teraz inni deweloperzy będą mogli zobaczyć ten plik. Dodawanie katalogu do repozytorium Proces dodawania katalogu do repozytorium jest podobny:
Inaczej niż w przypadku dodawania pliku, katalog pojawia się w repozytorium od razu. Nie jest potrzebny cvs commit. Kiedy już dodamy lokalny katalog do cvs, wewnątrz niego zostanie utworzony kolejny katalog, tym razem o nazwie "CVS", służący do przechowywania danych o koncie użytkownika. W ten sposób wystarczy spojrzeć do określonego katalogu, a w nim znaleźć CVS by wiedzieć, że ten katalog został dodany do repozytorium. "cvs add" - informacje dodatkowe Można więc zgadnąć, że zanim dodamy plik z katalogu do repozytorium, musimy być pewni, że katalog nadrzędny został już dodany do CVS. W innym wypadku program zwróci taki oto komunikat:
Zaznajamianie się z "cvs update", część 1 Zanim dowiemy się jak rozwiązywać konflikty, zaznajomimy się z wyjściem komendy "cvs update". Jeśli stworzymy plik ~/.cvsrc, który zawiera linię "cvs -q" zauważymy, że czytanie wyjścia "cvs update" jest o wiele przyjemniejsze. "cvs update" informuje o tym co widzi i co robi poprzez wypisanie pojedyńczego znaku, znaku spacji i nazwy pliku; tak jak w przykładzie:
Zaznajamianie się z "cvs update", część 2 "cvs update" używa znaku "?" (znaku zapytania), aby przekazać, że nic nie wie o określonych plikach znajdujących się w lokalnej kopii repozytorium. Nie są oficjalną częścią repozytorium ani nie zostaną dodane w przyszłości (nie znajdują się na liście plików do dodania). Oto lista wszystkich innych jednoznakowych wiadomości informacyjnych, których używa CVS:
Kiedy nowy plik zostanie utworzony w lokalnym repozytorium lub niezmieniany plik zostanie zaktualizowany.
Ten plik planowany jest do dodania i będzie oficjalnie dodany do repozytorium po wykonaniu komendy cvs commit. Zaznajamianie się z "cvs update", część 3
"R" pokazuje, że ten plik jest planowany do usunięcia. Plik zostanie usunięty z repozytorium jak tylko zastosujemy cvs commit.
Oznacza to, że ten plik został zmodyfikowany. Dodatkowo, jest możliwe, ze nowe zmiany z repozytorium zostały scalone z tym dokumentem poprawnie.
Znak "C" oznacza, że ten plik powoduje konflikt i wymaga ręcznej edycji zanim będziemy mogli zatwierdzić wprowadzone zmiany. Wprowadzenie do rozwiązywania konfliktów Spójrzmy teraz jak rozwiązywać konflikt. Jestem zaangażowany w projekt Gentoo Linux, nasza grupa posiada własny serwer cvs pod adresem cvs.gentoo.org. My deweloperzy spędzamy większość czasu przeglądając źródła wewnątrz modułu "gentoo-x86". W tym oto module mamy plik nazwany "ChangeLog" (tłum.: Dziennik zmian), który przechowuje opisy większych zmian wprowadzany do plików w repozytorium. Ponieważ ten plik jest modyfikowany za każdym razem gdy deweloper wprowadza zmiany w CVS, jest on zarazem podstawowym źródłem konfliktów - to przykładowy konflikt. Przypuśćmy, że dodam następujące linie na początku ChangeLog:
Ale, powiedzmy, że zanim jestem w stanie zatwierdzić zmiany w tych trzech liniach, inny deweloper dodaje następujące linie na początku ChangeLog i zatwierdza zmiany:
Przykładowy konflikt, kontynuacja Teraz kiedy uruchomię cvs update (co powinniśmy robić przed każdym zatwierdzeniem zmian), cvs nie będzie w stanie scalać tych zmian w mojej lokalnej kopii ChangeLog ponieważ dodaliśmy linie do tej samej części pliku. Skąd cvs ma wiedzieć, którą wersję użyć? Tak oto otrzymujemy błąd CVS:
Rozwiązywanie konfliktu, część 1 Aaa - konflikt! Na szczęście, naprawianie konfliktu jest stosunkowo łatwe. Jeśli uruchomię mój ulubiony edytor tekstu, zobaczę następujący tekst na początku ChangeLog:
>Rozwiązywanie konfliktu, część 2 Zamiast wybierania właściwej wersji zamiast drugiej, cvs dodał obydwie do pliku ChangeLog i otoczył je specjalnymi seperatorami by jasno pokazać źródło problemu. Teraz to ode mnie zależy, którą wersję pliku wybiorę, czyli tą, która powinna pojawić się w ChangeLog. W tym wypadku tekst zastępujący jest raczej kombinacją dwóch wpisów:
Teraz kiedy zastąpiłem konfliktowy rejon odpowiednią wersją tekstu (i usunąłem markery typu "======="), mogę teraz zatwierdzić moje zmiany do cvs bez dalszych problemów. Porady przy rozwiązywaniu konfliktów Gdy przychodzi do edytowania pliku w którym występuje konflikt, miejmy pewność, że przeglądniemy cały plik i wyłapiemy wszelkie różnice; jeśli tego nie zrobimy cvs nie pozwoli nam zatwierdzić zmian! Jest oczywiście bardzo istotne by usunąć specjalne znaczniki dodane przez cvs do pliku z konfliktami. Kolejna wskazówka - jeśli przez przypadek zrobimy błąd podczas usuwania konfliktu, a potem ("O nie") zapiszemy zmiany, możemy odnaleźć oryginalną kopię pliku w pliku ".#nazwa_pliku.nr_wersji". Teraz przyszła pora na naukę naszej ostatniej umiejętności w CVS - usuwania plików z repozytorium. Usuwanie pliku jest procesem dwufazowym. Na początku usuwamy plik z lokalnych zasobów, a potem wykonujemy odpowiednią komendę cvs remove:
Ten plik zostanie zaplanowany do usunięcia z repozytorium następnym razem gdy zatwierdzimy zmiany. Kiedy zatwierdzimy plik, zostanie on oficjalnie usunięty z lokalnej wersji repozytorium. Chociaż cvs nie usunie tego pliku i będzie przechowywał całkowity stan jego zawartości i historii, jeśli pojawi się potrzeba jego przejrzenia później. Jest to jeden ze sposobów w których cvs chroni wartościowy kod źródłowy. cvs remove jest komendą rekursywną, co oznacza, że możemy usunąć kilka plików, a potem zastosować cvs remove (komendę) bez żadnych argumentów z macierzystego katalogu. Czyniąc to sprawimy, że wszystkie usunięte pliki będą oznaczone jako usunięte, co zostanie wykonane przy następnym zatwierdzeniu zmian. Jeśli chcemy usunąć cały katalog, zalecam następujący proces. Po pierwsze, fizycznie usuńmy wszystkie pliki z tego katalogu i zatwierdźmy poleceniem cvs remove:
Usuwanie całego katalogu, kontynuacja Potem zatwierdźmy zmiany:
Teraz czas na sztuczkę. Postępujemy wg poniższych kroków by usunąć katalog:
Zauważmy, że usuwając katalog nie musimy zatwierdzać zmian - katalogi są dodawane i usuwane z repozytorium w czasie rzeczywistym. Jak w każdym dobrym systemie kontroli wersji, w CVS można pobrać dowolną starszą wersję pliku z repozytorium. Można określić jaka to ma być wersja za pomocą daty lub numeru rewizji. W przykładzie pobierzemy wersję 1.202 pliku o nazwie filename nadpisując nią obecny plik filename:
Można również pobrać plik podając datę jego dodania do repozytorium, służy do tego parametr -D. Można wykorzystać pełne formaty dat lub podać względne nazwy, takie jak yesterday lub last week. To koniec wprowadzenia do CVS. Mam nadzieję, że ten tekst był pomocny. Jest wiele więcej możliwości w CVS, których nie udało mi sie zawrzeć w tym wprowadzającym samouczku, ale dzięki Bogu istnieje wiele świetnych źródeł informacji o CVS, które pozwalają rozwinąć wiedzę o tym systemie kontroli wersji:
Oryginalna wersja tego atrykułu została opublikowana na IMB developerWorks i jest własnością Westtech Information Services. Ten dokument jest zaktualizowaną wersją oryinału i zawiera różnorakie ulepszenia dodane przez zespół odpowiadający za dokumentację w Gentoo Linux. |
|