Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00521 008208 10498187 na godz. na dobę w sumie
CVS bez tajemnic - książka
CVS bez tajemnic - książka
Autor: Liczba stron: 360
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-710-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> inne - programowanie
Porównaj ceny (książka, ebook, audiobook).

Projekt, nad którym pracuje zespół programistów, składa się z wielu plików, z których większość występuje w co najmniej kilku wersjach. Każdy z programistów modyfikuje je, dopisując nowe elementy i usuwając inne. Wydanie określonej wersji produktu wymaga zgromadzenia odpowiednich plików. Usuwanie błędów w działaniu aplikacji również wymaga dotarcia do odpowiedniej wersji plików źródłowych. W tych i wielu innych przypadkach pracy zespołowej pomocny okazuje się system zarządzania wersjami. Jednym z najpopularniejszych takich systemów jest, dostępny na zasadach open-source, CVS (Concurrent Versions System).

Książka 'CVS bez tajemnic' to podręcznik opisujący system CVS, zarówno z punktu widzenia użytkownika, jak i administratora. Przedstawia metody zarządzania kodem źródłowym projektów oraz tworzenia repozytoriów i administrowania nimi. Zawiera zestawienie poleceń CVS oraz opisy aplikacji klienckich, umożliwiających połączenie z systemem CVS z poziomu różnych środowisk programistycznych i systemów operacyjnych.

'CVS bez tajemnic' to doskonałe źródło wiedzy dla programistów i administratorów.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI CVS bez tajemnic KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Autor: Jennifer Vesperman T³umaczenie: Marek Pa³czyñski (rozdz. 5 – 11, dod. A – C), Rafa³ Sionek (przedmowa, rozdz. 1 – 4) ISBN: 83-7361-710-8 Tytu³ orygina³u: Essential CVS Format: B5, stron: 360 Ksi¹¿ka „CVS bez tajemnic” to podrêcznik opisuj¹cy system CVS, zarówno z punktu widzenia u¿ytkownika, jak i administratora. Przedstawia metody zarz¹dzania kodem ĥród³owym projektów oraz tworzenia repozytoriów i administrowania nimi. Zawiera zestawienie poleceñ CVS oraz opisy aplikacji klienckich, umo¿liwiaj¹cych po³¹czenie z systemem CVS z poziomu ró¿nych ġrodowisk programistycznych i systemów operacyjnych. • Instalacja systemu CVS • Projekty i repozytoria • Tworzenie znaczników i odga³êzieñ • Wykorzystanie systemu CVS w pracy zespo³u programistycznego • Zarz¹dzanie repozytoriami i projektami • Zdalne repozytoria • Polecenia systemu CVS • Aplikacje klienckie i integracja ze ġrodowiskami programistycznymi „CVS bez tajemnic” to doskona³e ĥród³o wiedzy dla programistów i administratorów. Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl Spis treści Przedmowa ...................................................................................................................... 9 Część I Wprowadzenie 13 1. Czym jest CVS ..................................................................................................................15 15 17 Czym jest system kontroli wersji Obszary zastosowań CVS 2. CVS — przewodnik dla początkujących........................................................................21 21 27 29 32 33 34 35 37 38 39 Instalowanie CVS Tworzenie pierwszego repozytorium Importowanie projektów Uzyskiwanie dostępu do repozytoriów zdalnych Pobieranie plików Wysyłanie poprawek Aktualizowanie magazynów lokalnych Dodawanie plików Usuwanie plików Porady na zakończenie Część II Użytkowanie systemu CVS 41 3. Podstawowe zastosowania CVS ..................................................................................43 43 45 50 53 55 62 64 68 69 70 74 76 Informacje ogólne Magazyny lokalne i repozytoria Wprowadzanie zmian do repozytorium Sprawdzanie statusu plików Uaktualnianie plików znajdujących się w magazynie lokalnym Dodawanie plików do repozytorium Usuwanie plików z repozytorium Przenoszenie plików i katalogów Zwalnianie magazynu lokalnego Słowa kluczowe Pliki binarne i warstwy otaczające Określanie domyślnych opcji polecenia 5 4. Tworzenie znaczników i odgałęzień ............................................................................77 77 86 88 98 Oznaczanie Lepkość Rozgałęzianie Strategie rozgłęziania 5. Praca wielu użytkowników ........................................................................................ 105 106 106 112 115 118 119 Jednoczesna praca nad projektem Monitorowanie pliku Rezerwowanie plików Porównywanie różnych wersji pliku Wyświetlanie najnowszych zmian Wyświetlanie historii pliku Część III Administracja 123 6. Zarządzanie repozytorium ..........................................................................................125 125 126 127 130 133 144 145 151 160 163 165 Tworzenie repozytorium Usuwanie repozytorium Zabezpieczanie projektów Struktura repozytorium Pliki katalogu CVSROOT Zmienne środowiskowe serwera Sporządzanie kopii zapasowej repozytorium Edycja repozytorium Struktura magazynu lokalnego Zmienne środowiskowe systemu klienckiego Kody statusowe 7. Zarządzanie projektem................................................................................................167 167 174 177 187 190 193 Tworzenie projektu Dystrybucja plików Uruchamianie skryptów Współpraca CVS z innymi programami Narzędzia CVS Strategie i uwagi praktyczne 8. Zdalne repozytoria........................................................................................................197 198 199 200 203 Wyznaczanie ścieżek do repozytorium Metoda dostępu local Metody dostępu ext i server Metoda dostępu fork 6 | Spis treści Metoda dostępu gserver Metoda dostępu kserver Metoda dostępu pserver Wykorzystanie usługi inetd w metodach gserver, kserver i pserver 204 207 208 213 9. Rozwiązywanie problemów .......................................................................................215 215 217 221 222 222 223 Ogólne techniki rozwiązywania problemów Problemy z połączeniami Problemy związane z nazwami plików Problemy ze znakami końca wiersza Problemy z prawami dostępu Pliki blokad Część IV Pomoc techniczna 225 10. Polecenia CVS ............................................................................................................... 227 227 230 Opcje instrukcji wiersza poleceń Polecenia CVS 11. Pozostałe elementy CVS ............................................................................................. 273 274 276 287 289 293 295 298 300 Pliki administracyjne Pliki katalogu CVSROOT Zmienne plików katalogu CVSROOT Daty Zmienne środowiskowe Słowa kluczowe i tryby zastępowania słów kluczowych Wzorce dopasowania Metody dostępu do repozytorium Dodatki 303 A Oprogramowanie klienckie różnych systemów operacyjnych ................................ 305 B Narzędzia administratora........................................................................................... 323 C Najważniejsze polecenia CVS w skrócie .................................................................... 333 Skorowidz..................................................................................................................... 339 Spis treści | 7 Tworzenie znaczników i odgałęzień ROZDZIAŁ 4. Z pewnością jedną z najbardziej pomocnych, jak również niedocenianych funkcji CVS są znaczni- ki (ang. tag). Funkcja nadawania znaczników pozwala nadać rewizji etykietę umożliwiającą jej późniejsze pobranie. Ponadto funkcja ta pozwala na rozwidlenie prac nad projektem w taki sposób, iż możliwa staje się równoczesna praca nad dwoma lub więcej wersjami projektu. Od- gałęziona wersja projektu nosi nazwę gałęzi (ang. branch), a jego część główna — pnia (ang. trunk). W rozdziale tym obszernie wyjaśniono takie pojęcia jak oznaczanie i odgałęzianie projektów. Podano w nim także przyczyny, dla których wykonuje się operacje oznaczania i tworzenia odgałęzień projektu, oraz opisano strategie i wskazówki pomocne w efektywnym zarządza- niu odgałęzieniami w projekcie. Oznaczanie CVS umożliwia pobranie dowolnej, obecnej w repozytorium rewizji pliku. Jeżeli pobieranie różnych rewizji ma sens, dlaczego nie miałoby mieć sensu pobieranie zestawu zgodnych ze sobą rewizji innych, tworzących kompletną, w pełni funkcjonalną wersję projektu? Np. wszyst- kich rewizji plików, które składały się na wersję 1.0 projektu, lub stały się pierwszym wyda- niem książki. Znakowanie jest sposobem nadawania znaczników zestawowi rewizji plików tworzącemu jedną zwartą grupę. W przypadku oznaczania nie można do tego celu używać numerów rewi- zji, gdyż np. rewizja 2.3 jednego pliku, mogła tworzyć wspólną grupę z rewizją 2.17 innego pliku. Rysunek 4.1 przedstawia grupę rewizji plików wraz z linią określającą, które numery rewizji należą do tej samej grupy. System CVS umożliwia utworzenie pojedynczego znacznika, wskazującego na rewizje połą- czone za pomocą wymienionej wcześniej linii. Aby mieć wgląd na wszystkie należące do tego znacznika rewizje, system CVS może „pociągnąć” za linię w celu zlokalizowania oznaczonych rewizji. Rysunek 4.2 przedstawia tę samą grupę plików z prostą linią wskazującą pliki nale- żące do tego znacznika. Znacznika można użyć do wskazania określonej wersji pojedynczego pliku lub określonego zestawu rewizji grupy plików i określenia nazwy dla tego zestawu. Od tej pory znacznik po- zwala na łatwe odzyskanie tej jednej rewizji lub całego zestawu. Ponadto zapamiętanie łańcu- cha tekstowego jest o wiele łatwiejszym zadaniem niż zapamiętanie numeru wersji. Uży- wanie znaczników przez programistów do oznaczania wersji według ich własnych kryteriów jest znacznie częstsze niż korzystanie z numerowania rewizji stosowanego przez system CVS. 77 Rysunek 4.1. Rewizje plików należących do tej samej grupy Rysunek 4.2. Oznaczanie rewizji plików .Nazwy znaczników muszą rozpoczynać się od znaku będącego literą i mogą składać się ze zna- ków alfanumerycznych, łączników i znaków podkreślenia. Nazwa każdego znacznika musi być również niepowtarzalna. Pliki znaczników oraz polecenia cvs tag i cvs rtag zostały opisane w punktach „Oznaczanie przy pomocy magazynu lokalnego” i „Oznaczanie za pomocą daty lub rewizji” niniejszego rozdziału. Najlepiej używać zrozumiałych i prostych nazw znaczników. Powinny one wywoływać określo- ne, związane z daną rewizją skojarzenia, podpowiadające np. czemu dane pliku należą do jed- nej grupy. Przykładowymi, dobrymi nazwami znaczników są: release-1-3-beta, release-2-13-patch-5, testing-1-5-alpha i release-2-5-stable. W trakcie trwania projektu należy ustalić jednolitą konwencję nazewniczą znaczników i zachęcić osoby pracujące nad projektem do jej stosowania. Nazwy nadawane znacznikom powinny od- zwierciedlać z kolei konwencję nazewniczą używaną do określania kolejnych wersji projektu, nieobcą wszakże uczestnikom projektu. Na odpowiednio nazwanych znacznikach uczestnicy projektu mogą polegać w dużo większym stopniu, przy wyborze odpowiedniej rewizji projektu, niż na wewnętrznej numeracji CVS. Wewnętrzna numeracja przeznaczona jest dla celów narzędzi wewnętrznych składających się na system CVS i może być tylko i wyłącznie utrudnieniem dla uczestników projektu, gdyby mieli oni polegać na niej przy określaniu etapów projektu. 78 | Rozdział 4. Tworzenie znaczników i odgałęzień W punkcie „Plik taginfo” w rozdziale 7. zaprezentowano skrypt, który może być użyty do automatycznego wymuszania standardów nazewniczych. W systemie CVS istnieją jednakże dwie zastrzeżone nazwy znaczników. CVS używa nazw BASE i HEAD do nazywania odpowiednio: nazwy ostatnio zsynchronizowanej z repozyto- rium rewizji i nazwy znacznika ostatniej rewizji znajdującej się w repozytorium. Rozważmy hipotetyczną sytuację, w której wszyscy uczestnicy projektu synchronizują rewi- zję do wersji 1.23, z tym, że dowolny uczestnik projektu dokonuje dwóch synchronizacji swoich zmian w repozytorium. Wobec tego numery rewizji pozostałych członków zespołu, którzy nie synchronizowali swoich magazynów lokalnych z repozytorium, wynoszą nadal 1.23, pod- czas gdy obecnym numerem wersji HEAD jest już 1.25, ponieważ taka była nazwa rewizji BASE użytkownika, który synchronizował wcześniej swój magazyn lokalny. Oznaczanie przy pomocy magazynu lokalnego W celu oznakowania wszystkich plików w magazynie lokalnym wraz z należącymi do niego podkatalogami, należy wykorzystać polecenie cvs tag. Domyślnie, oznaczana jest rewizja BASE. Określone pliki mogą zostać oznaczone po podaniu ich nazw jako argumentu polecenia cvs tag. Składnia polecenia cvs tag prezentuje się nastepująco: cvs [opcja_cvs] tag [opcja_polecenia] nazwa_znacznika [nazwy_plików] Polecenie cvs tag określa pliki i rewizje do oznaczenia ich na podstawie zawartości maga- zynu lokalnego, lecz faktycznie oznacza je na podstawie numeru ostatnio synchronizowanej z repozytorium rewizji. Zatem, jeżeli w magazynie lokalnym pojawiłyby się nowe zmiany od czasu ostatniej synchronizacji przechowywanych w nim plików z repozytorium, zmiany te nie zostałyby odzwierciedlone w oznaczonych rewizjach. Opcja -c polecenia cvs tag pozwala sprawdzić, czy magazyn lokalny nie został zmodyfiko- wany, a dokonane w nim zmiany jak dotychczas niezatwierdzone, zanim dokonano oznako- wania plików. W przypadku gdy polecenie cvs tag -c napotka na niewprowadzone do re- pozytorium zmiany, zatrzyma swoje działanie, nie dokonując oznakowania żadnych plików. Aby jednak oznakować rewizję znajdującą się w repozytorium, bez wprowadzenia wszyst- kich zmian z magazynów lokalnych, należy podczas wydawania polecenia cvs tag ominąć opcję -c. Chcąc oznakować rewizję znajdującą się w magazynie lokalnym, należy wprowadzić zmiany do repozytorium i uruchomić ponownie polecenie cvs tag. W celu zidentyfikowania rewizji do oznakowania można posłużyć się datami bądź innymi, istniejącymi już znacznikami lub też numerami rewizji. Aby zidentyfikować wersję za pomo- cą nazwy rewizji lub istniejącego znacznika, należy użyć polecenia cvs tag -r rewizja lub cvs tag -r nazwa_znacznika. Aby zidentyfikować wersję za pomocą daty, trzeba posłużyć się poleceniem cvs tag -D data. Dokonując identyfikacji za pomocą daty, CVS oznaczy pierwszą rewizję, której data jest mniejsza od daty określonej za pomocą parametru -D. Więcej informacji na temat dat można znaleźć w rozdziale 11. Wraz z opcjami -D oraz -r można również stosować opcję -f. Opcja ta nakazuje systemowi CVS, aby używał rewizji HEAD, w przypadku gdy żadna inna rewizja nie spełnia wymagań określonych parametrami -r lub -D. Oznaczanie | 79 Domyślnie, polecenie cvs tag działa rekursywnie w stosunku do wszystkich podkatalogów ma- gazynu lokalnego. Za taki sposób wykonywania polecenia cvs tag odpowiada opcja -R, którą można również używać, choć jak już wspomniano wcześniej, nie ma takiej potrzeby. Przykład 4.1 prezentuje oznakowanie plików znajdujących się w magazynie lokalnym znacz- nikiem o nazwie pre_alpha_0-1 za pomocą polecenia cvs tag. Przykład 4.1. Użycie polecenia cvs tag bash-2.05a$ cvs tag pre_alpha_0-1 cvs server: Tagging . T Changelog T INSTALL T Makefile T README T TODO cvs server: Tagging doc cvs server: Tagging doc/design T doc/design/AcceptanceTest.doc T doc/design/Analysis.rtf T doc/design/Requirements.doc T doc/design/Specification.rtf cvs server: Tagging doc/plan T doc/plan/Schedule.rtf cvs server: Tagging lib cvs server: Tagging man cvs server: Tagging src T src/config.h T src/main.c Oznaczanie za pomocą daty lub rewizji Polecenie cvs rtag pozwala na oznakowanie plików bez odwoływania się do konkretnego magazynu lokalnego. Polecenie rtag w celu zidentyfikowania rewizji plików do oznakowa- nia polega na parametrach podawanych wraz z poleceniem, toteż podanie opcji -r lub -D wraz z nazwą co najmniej jednego pliku, katalogu lub modułu staje się obligatoryjne. Zagadnienie modułów zostało szerzej ujęte w rozdziale 7. Podając jako argument opcji nazwy kilku kata- logów, plików lub modułów, należy rozdzielić je spacjami. Składnia polecenia cvs rtag jest następująca: cvs [opcja_cvs] rtag opcja_polecenia nazwa_znacznika nazwy_plików Przykład 4.2 prezentuje nadanie znacznika pre_alpha_0-2 wszystkim plikom znajdującym się w podkatalogach, jak również w samym katalogu wizzard za pomocą polecenia cvs rtag. Opcja -r HEAD oznacza, że znacznik pre_alpha_0-2 zostanie przyporządkowany rewizjom HEAD wszystkich plików. Przykład 4.2 Użycie polecenia cvs rtag bash-2.05a$ cvs -d cvs:/var/lib/cvs rtag -r HEAD pre_alpha_0-2 ewizzard cvs rtag: Tagging wizzard cvs rtag: Tagging wizzard/doc cvs rtag: Tagging wizzard/doc/design cvs rtag: Tagging wizzard/doc/plan cvs rtag: Tagging wizzard/lib cvs rtag: Tagging wizzard/man cvs rtag: Tagging wizzard/src 80 | Rozdział 4. Tworzenie znaczników i odgałęzień Jeżeli w chwili wydania polecenia cvs rtag znajdujemy się w magazynie lokalnym, system CVS jako repozytorium, w którym należy oznakować pliki, domyślnie przyjmie repozytorium powiązane z tym konkretnym magazynem lokalnym. Znajdując się więc w magazynie lokal- nym powiązanym z innym repozytorium niż to, w którym ma dojść do oznakowania plików, należy opuścić je lub użyć opcji -d ścieżka_do_repozytorium , tak jak zostało to pokazane w przykładzie 4.2. Jeśli bieżącym katalogiem roboczym nie jest katalog magazynu lokalnego, można określić je za pomocą zmiennej środowiskowej CVSROOT (w przypadku komputera będącego jedynie klien- tem CVS) lub opcji -d ścieżka_do_repozytorium (w przypadku komputera będącego równocze- śnie serwerem, jak i klientem CVS). Chcąc oznakować każdą najnowszą rewizję wszystkich plików znajdujących się w repozyto- rium, należy użyć opcji -r HEAD. Warto przy tym mieć świadomość tego, że operacje wyko- nywane przez CVS nie są niepodzielne i w przypadku, gdy podczas oznaczania plików za po- mocą opcji -r HEAD, któryś z użytkowników będzie równocześnie wprowadzał swoje zmiany do repozytorium, może zdarzyć się sytuacja, w której jeden katalog zostanie oznakowany przed wprowadzeniem zmian przez użytkownika, podczas gdy inny zostanie oznakowany już po dokonaniu operacji wprowadzenia zmian do repozytorium. Używając opcji -D, trzeba pamiętać, że jeśli nie została określona konkretna godzina, system CVS oznakuje ostatnią rewizję, datującą się przed północą określonego za pomocą opcji -D dnia. Przykładowo, opcja -D 12 Feb 2002 spowoduje oznakowanie plików tak, jak wyglądały one o północy 12 lutego 2002 roku czasu lokalnego. Formaty daty zostały omówione w rozdziale 11. Większość opcji polecenia cvs tag wykazuje podobne właściwości jak w przypadku polece- nia cvs rtag. Opcje -l i -R odpowiadają za rekursywność działania opcji, a opcje -r, -D i -f służą określaniu rewizji, podobnie jak w poleceniu cvs tag. Opcja -c polecenia cvs tag nie ma zastosowania w przypadku polecenia cvs rtag. Pobieranie oznakowanych plików W celu wyświetlenia znaczników przyporządkowanych danemu plikowi, należy wykonać polecenie cvs status -v w katalogu, w którym znajduje się rzeczony plik. Polecenie to wy- świetli również informacje na temat aktualnej rewizji znajdującej się w magazynie lokalnym, aktualnej rewizji w repozytorium oraz informację na temat „lepkich” znaczników aktualnego magazynu lokalnego. Nazwy znaczników zostaną umieszczone w dolnej części wyświetlonego raportu. Warto zwrócić uwagę na znaczniki, których nazwy są opatrzone nie tylko numerami rewizji, lecz także słowem „branch” — są to znaczniki będące równocześnie znacznikami ba- zowymi danego odgałęzienia. Więcej informacji na ich temat można znaleźć w podrozdziale „Rozgałęzianie” w dalszej części tego rozdziału. Przykład 4.3 demonstruje sposób użycia pole- cenia cvs status w celu wyświetlenia znaczników pliku main.c. Przykład 4.3 Znaczniki pliku bash-2.05a$ cvs status -v src/main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maing.c,v Sticky Tag: (none) Oznaczanie | 81 Sticky Date: (none) Sticky Options: (none) Existing Tags: pre_alpha_0-2 (revision: 1.9) pre_alpha_0-1 (revision: 1.9) Pobranie oznakowanego pliku lub całego ich zestawu jest możliwe dzięki zastosowaniu pa- rametru -r nazwa_znacznika jako opcji polecenia cvs checkout lub cvs update. Polecenia checkout należy użyć w celu utworzenia nowego magazynu lokalnego, a polecenia update przy założeniu, że pliki mają być pobrane do aktualnego magazynu lokalnego. W drugim przypad- ku wszystkie znajdujące się w nim pliki zostaną nadpisane plikami oznakowanej rewizji, jed- nakże zmiany, które zostały dokonane od czasu ostatniej synchronizacji z repozytorium, zo- staną scalone z nowymi plikami. Przykład 4.4 prezentuje efekt działania polecenia cvs checkout w przypadku oznakowanego magazynu lokalnego. Przykład 4.4. Pobieranie plików do oznakowanego magazynu lokalnego za pomocą polecenia cvs checkout bash-2.05a$ cvs -d cvs:/var/lib/cvs checkout -r pre_alpha_0-2 wiezzard cvs server: Updating wizzard U wizzard/Changelog U wizzard/INSTALL U wizzard/Makefile U wizzard/README U wizzard/TODO cvs server: Updating wizzard/doc cvs server: Updating wizzard/doc/design U wizzard/doc/design/AcceptanceTest.doc U wizzard/doc/design/Analysis.rtf U wizzard/doc/design/Requirements.doc U wizzard/doc/design/Specification.rtf cvs server: Updating wizzard/doc/plan U wizzard/doc/plan/Schedule.rtf cvs server: Updating wizzard/lib cvs server: Updating wizzard/man cvs server: Updating wizzard/src U wizzard/src/config.h U wizzard/src/main.c Wykonując operacje pobrania plików lub uaktualnienia magazynu lokalnego za pomocą daty lub znacznika nie będącego znacznikiem odgałęzienia (temat odgałęzień opisany został w dal- szej części tego rozdziału), znacznik lub data określająca pliki w magazynie lokalnym będą „lepkie”. Pliki znajdujące się w magazynie lokalnym, które zostały pobrane poprzez określe- nie ich daty lub nazwy znacznika nie będącego znacznikiem odgałęzienia są tylko statyczną reprezentacją stanu projektu w danym czasie. Wprowadzenie zmian do takiego pliku nie jest możliwe. Termin lepkość odnosi się tylko do plików znajdujących się w magazynie lokalnym, nie dotyczy zaś repozytorium. Dokładniejsze informacje na ten temat można znaleźć w pod- rozdziale „Lepkość”. Usuwanie oraz przenoszenie znaczników Nadawanie znaczników ma zazwyczaj charakter stały, jednak czasami pojawia się potrzeba usunięcia znacznika, zmiany jego nazwy lub przeniesienia go. Operacje takie należy przepro- wadzać ze szczególną ostrożnością, gdyż mogą spowodować usunięcie wcześniejszych infor- macji i równocześnie uniemożliwienie ich odzyskania. 82 | Rozdział 4. Tworzenie znaczników i odgałęzień Przy próbie usunięcia specjalnego znacznika — nazywanego znacznikiem odgałęzienia (patrz podrozdział „Rozgałęzianie”) — system CVS wyświetli informację o błędzie i nie usunie znacz- nika, ani nie przeniesie go. Aby wymusić usunięcie lub przeniesienie takiego znacznika, na- leży posłużyć się opcją -B. Należy unikać przenoszenia, jak również zastępowania nazwy znacznika odgałęzie- nia bez potrzeby, a decydując się na to, należy zadbać, aby kopia zapasowa repozy- torium odzwierciedlała wszystkie ostatnie zmiany, gdyż istnieje duże zagrożenie utraty danych. Usuwanie znacznika Zwykle nie ma potrzeby usuwania poprawnie umieszczonego w pliku znacznika. Sytuacja taka może jednak zaistnieć w przypadku błędnego nadania znacznika i wtedy, być może, trzeba będzie usunąć dany znacznik i spróbować nadać go ponownie. Aby usunąć znacznik, należy posłużyć się opcją -d: cvs tag -d nazwa_znacznika [nazwa_pliku] lub cvs rtag -d nazwa_znacznika nazwa_pliku Podczas wykonywania polecenia rtag poza magazynem lokalnym podanie ścieżki do repo- zytorium staje się obligatoryjne. Po wydaniu polecenia rtag wewnątrz magazynu lokalnego CVS przeszuka podkatalog CVS w celu znalezienia odpowiedniego repozytorium. Polecenie tag musi być wykonywane wewnątrz magazynu lokalnego. Domyślnie odnosi się ono do aktualnego magazynu lokalnego i znajdujących się w nim podkatalogów. System CVS przeszuka podkatalog CVS, by znaleźć odpowiednie repozytorium. Przykład 4.5 pokazuje sposób użycia polecenia cvs tag z zamiarem usunięcia znacznika. Polece- nie zostało wydane z najwyższego poziomu hierarchii katalogów magazynu lokalnego dane- go projektu. Przykład 4.5. Usuwanie znacznika bash-2.05a$ cvs tag -d pre_alpha_0-2 cvs server: Untagging . cvs server: Untagging doc cvs server: Untagging doc/design cvs server: Untagging doc/plan cvs server: Untagging src Przenoszenie znacznika Najczęstszą przyczyną przenoszenia znacznika jest poprawienie błędu w oznakowaniu. W nie- których zespołach projektowych używa się również przenośnego znacznika w celu oznakowania najnowszej wersji projektu, gotowej do wydania, lub najnowszej wersji poprawek. Znacznik taki przenoszony jest za każdym razem, kiedy nowa wersja projektu zostaje ukończona. Aby przenieść znacznik z jednej rewizji na inną rewizję tego samego pliku lub ich zestawu, należy posłużyć się poleceniem cvs tag lub cvs rtag wraz z opcją -F. Za pomocą opcji -r okre- śla się rewizję, do której ma zostać przeniesiony znacznik, podczas gdy opcja -F służy do określe- nia nazwy znacznika do przeniesienia. Przykład 4.6 ilustruje operację przeniesienia znacznika Oznaczanie | 83 wykonaną z poziomu magazynu lokalnego przy użyciu polecenia cvs rtag. Raport dotyczący statusu pliku wyświetlił się przed i po operacji przeniesienia. Używając do przeniesienia znaczni- ka polecenia rtag, zamiast tag, należy określić pełną ścieżkę z katalogu głównego repozytorium do pliku main.c, włączając w to również nazwę projektu. Przy wykonywaniu polecenia cvs status określenie pełnej ścieżki nie jest konieczne ze względu na to, że polecenie to zostaje wy- dane z poziomu magazynu lokalnego. Przykład 4.6. Przenoszenie znacznika bash-2.05a$ cvs status -v src/main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maing.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: pre_alpha_0-1 (revision: 1.9) bash-2.05a$ cvs rtag -r 1.8 -F pre_alpha_0-1 wizzard/src/main.c bash-2.05a$ cvs status -v src/main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maign.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: pre_alpha_0-1 (revision: 1.8) Usuwanie i przenoszenie znaczników w plikach znajdujących się w katalogu Attic Pliki usunięte z głównego pnia projektu poleceniem cvs remove lub też pliki, które nigdy się w nim nie znalazły, przechowywane są w podkatalogu Attic, znajdującym się w katalogu re- pozytorium. Pliki takie mogą być skojarzone ze znacznikami, które wymagają usunięcia, prze- niesienia lub zmiany nazwy. Operacji tej nie da się wykonać na plikach znajdujących się w katalogu Attic za pomocą polecenia cvs tag. Jednak polecenie cvs rtag ma opcję -a, któ- ra potrafi wymusić wykonanie polecenia cvs rtag -d -F w stosunku do usuniętych wcześniej plików (np. takich, które są umieszczone w katalogu Attic) znajdujących się w odpowiednim module lub katalogu . Po wydaniu polecenia cvs tag lub cvs rtag wraz z opcją -r nazwa_rewizji, system CVS sprawdza katalog Attic pod kątem obecności określonej rewizji w plikach tam się znajdujących, co tym samym oznacza, że w takim wypadku opcja -a nie jest wymagana. Zmienianie nazwy znacznika Jeżeli któryś z członków zespołu projektowego dodał do systemu znacznik nie odpowiadają- cy standardom nazewniczym przyjętym w danym projekcie, można przeprowadzić operację zmiany nazwy takiego znacznika. 84 | Rozdział 4. Tworzenie znaczników i odgałęzień Co prawda, CVS nie dysponuje specjalnym poleceniem do zmiany nazwy znacznika, jednak- że za pomocą polecenia cvs tag lub cvs rtag wraz z opcją -r nadanie nowego znacznika błędnie oznaczonej rewizji jest bardzo proste. Po pomyślnie zakończonej operacji można usu- nąć stary znacznik. Takie podejście nie jest jednak odpowiednie w przypadku rozgałęzień. Przykład 4.7. prezentuje operację zmiany nazwy znacznika. Celem operacji jest zmiana nazwy znacznika pre_alpha_0-1 na pre_beta_0-1. W pierwszej kolejności plikom oznaczonym jako pre_alpha_0-1 nadaje się znacznik pre_beta_0-1, a następnie usuwa się stary znacznik poleceniem cvs tag -d. Efektem takiej operacji jest zmiana nazwy znacznika pre_alpha_0-1 na pre_beta_0-1. Przykład 4.7. Zmiana nazwy znacznika bash-2.05a$ cvs tag -r pre_alpha_0-1 pre_beta_0-1 cvs server: Tagging . T Changelog T INSTALL T Makefile . . . cvs server: Tagging src T src/config.h T src/main.c bash-2.05a$ cvs tag -d pre_alpha_0-1 cvs server: Untagging . D Changelog D INSTALL D Makefile . . . cvs server: Untagging src D src/config.h D src/main.c Usunięte pliki Trzeba wiedzieć, że jeśli usunie się plik z oznakowywanego właśnie projektu, to ów plik nie zostanie oznakowany. Nie ma to większego znaczenia w przypadku, gdy plik ten nie będzie ponownie dodany do projektu. Jeżeli jednak plik został usunięty z projektu, a następnie do niego przywrócony, to trzeba mieć świadomość, że nie istnieje prosty sposób na sprawdzenie, czy plik ten został oznakowany, czy nie. Dzieje się tak, gdyż znacznik mógł zostać nadany pomiędzy usunięciem pliku, a jego przywróceniem, lub też z tego powodu, że znacznik może być starszy niż plik. By zdobyć więcej informacji na ten temat, można posiłkować się datami plików lub wykonać polecenie cvs rdiff -s -r nazwa_znacznika nazwa_projektu. Opcja -s polecenia rdiff generuje raport podsumo- wujący, w którym wyświetlą się wszystkie pliki bądź to zmienione, bądź dodane lub też usunięte. Aby oznakować zarówno usunięte, jak i nieusunięte pliki wraz z poleceniam cvs tag lub cvs rtag, należy używać opcji -r, na przykład -r HEAD. Przy oznakowywaniu rewizji HEAD, być może będzie trzeba zapewnić ochronę plikom znaj- dującym się w repozytorium przed zmianami innych użytkowników, pomiędzy momentem, w którym zostaje podjęta decyzja, że pliki są gotowe do oznakowania, a ich faktycznym ozna- kowaniem. Rady dotyczące tego, jakie podjąć w takim wypadku działania, zawarte zostały w punkcie „Blokowanie repozytorium” znajdującym się w rozdziale 6. Oznaczanie | 85 Strategie oznakowywania Nadawanie znaczników ułatwia późniejsze pobieranie plików należących dodanego etapu projektu. Znaczniki należy nadawać zawsze wtedy, gdy projekt osiąga kolejne, znaczące eta- py realizacji. Jako absolutne minimum należy przyjąć oznaczanie każdego rozgałęzienia pro- jektu i każdego kolejnego, ukończonego wydania projektu. Dobrze jest obmyślić własną lokalną strategię oznakowywania. Poniższa lista ważnych punk- tów projektu, które należałoby wziąć pod uwagę podczas opracowywania strategii, jest silnie zorientowana na tworzenie programów: • po zakończeniu prac nad każdą ważniejszą funkcją, • w momencie osiągnięcia każdej znaczącej fazy projektu, • tuż przed odrzuceniem istniejącej już funkcji, • tuż przed rozpoczęciem testowania, • przed wprowadzeniem zmian mogących zepsuć uruchamiający się już kod, • tuż przed rozszczepieniem gałęzi, • tuż po scaleniu odgałęzień. Należy używać zrozumiałych znaczników o wcześniej ustalonym formacie, zawierających w swojej nazwie wszystkie potrzebne informacje. Poniższy przykład jest jednym z możliwych do zastosowania, lecz równocześnie niezwykle uszczegółowionym formatem nazywania znaczników. wersja-[alpha-|beta-][test-|final-|patch-][patch#-][pub|priv]g W przypadku, gdy zaistnieje konieczność pobrania starszej wersji kodu w celu przetestowa- nia lub opracowania poprawki, należałoby mieć pod ręką łatwy sposób identyfikacji tej wer- sji, o którą nam chodzi. Powyższy przykład formatu nazwy znacznika zapewnia informację na temat numeru rewizji oraz mówi o tym, czy oznakowana rewizja jest wersją testową, czy też finalną, określa stadium testów, a także powiadamia o tym, czy dane wydanie jest wersją ogólnodostępną, czy wewnętrzną. Należy mieć na uwadze fakt, że zaprezentowany powyżej przykład jest tylko jednym z moż- liwych do zastosowania formatów. Bazując na potrzebach własnego zespołu projektowego najlepiej jest jednak opracować swój własny format nazywania znaczników. Większość zespo- łów będzie preferowała format krótszy od tego, jaki został tutaj zaprezentowany. Lepkość Pojęcie lepkości (ang. stickiness) jest jedną z ważniejszych cech systemu CVS, szczególnie gdy mowa o nadawaniu znaczników i rozgałęzianiu. Lepkość jest zasadniczo cechą wewnętrzną systemu CVS, ogranicza ona jednak zakres zmian, jakie można wprowadzić do magazynu lokalnego. Kiedy któryś z plików znajdujących się w repozytorium osiąga stan, w którym nie powinien być on już poddawany żadnym modyfikacjom, co nie jest domyślnym typem zachowania dla plików znajdujących się w magazynie lokalnym, stan taki nazywa się stanem lepkim (ang. sticky). 86 | Rozdział 4. Tworzenie znaczników i odgałęzień Lepkość pliku może być spowodowana przynależnością pliku do pewnej określonej rewizji lub odgałęzienia projektu, lub też może on posiadać pewne opcje słów kluczowych. Dany plik można włączyć do określonej rewizji poprzez pobranie go z repozytorium za po- mocą określającej go nazwy znacznika, numeru rewizji lub daty. W przypadku, gdy plik zo- stanie pobrany za pomocą daty, mówi się, że ma on lepką datę. Jeżeli zostanie pobrany za po- mocą znacznika, mówi się o lepkim znaczniku, a przypadku pobrania za pomocą numeru rewizji, analogicznie plik taki określa się jako plik posiadający lepką rewizję. Podobnie jak w powyższym przykładzie, o plikach znajdujących się w magazynie lokalnym, należących równocześnie do odgałęzienia, mówi się, że posiadają one lepkie odgałęzienie, a w przypadku pliku o określonych dla danego magazynu lokalnego słowach kluczowych, mówi się jako o pliku mającym lepkie słowa kluczowe. Znacznik lepkości determinuje zachowanie wszystkich uruchamianych poleceń mających wpły- wa na tenże plik. Plik, z lepką data, rewizją lub ze znacznikiem nie należącym do jakiegokol- wiek odgałęzienia nie zostanie zaktualizowany do nowszej wersji; plik taki nie może zostać również zsynchronizowany z repozytorium. Z kolei plik określony lepkim odgałęzieniem zawsze zostanie zaktualizowany lub zsynchronizowany z określonym odgałęzieniem. Stan lepkości plików może być monitorowany za pomocą polecenia cvs status. Przykładowo, aby zobaczyć raport dla pliku index.htm, należy wydać polecenie cvs status index.htm. Przy- kład 4.8. prezentuje raport na temat statusu pliku mającego lepkie odgałęzienie. Przykład 4.8. Wyświetlenie statusu lepkiego pliku bash-2.05a$ cvs status main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maign.c,v Sticky Tag: beta_0-1_branch (branch: 1.9.2g) Sticky Date: (none) Sticky Options: (none) Katalogi magazynów lokalnych również mogą być lepkie, a stan taki implikuje przekazywa- nie go również każdemu plikowi dodanemu do takiego katalogu. Nazwy katalogów oznaczo- nych jako lepkie znajdują się w pliku Tag umiejscowionym w podkatalogu CVS takiego lep- kiego katalogu. Przykład 4.9. prezentuje plik Tag. Przykład 4.9. Zawartość pliku Tag bash-2.05a$ less CVS/Tag Tbeta_0-1_branch Stan lepkości nadaje się lub zmienia za pomocą polecenia cvs checkout lub cvs update wraz z opcjami -k, -D lub -r. Stan taki można usunąć poprzez uruchomienie polecenia cvs update -A, które to polecenie spowoduje pobranie z pnia repozytorium rewizji HEAD, nadanie ustawień domyślnych odpowiednim plikom oraz usunięcie wszystkich lepkich znaczników z katalogów. Aby usunąć oznaczenie lepkości z danego katalogu, należy posłużyć się poleceniem cvs update -A, określając dany katalog jako cel działania tegoż polecenia. Polecenie cvs update -A nazwa_pliku nie spowoduje usunięcia znacznika lepkości katalogu, jak również nie będzie ono odnosiło się do innych plików znajdujących się w katalogu. Lepkość | 87 Rozgałęzianie We wcześniejszej wersji tego rozdziału określono rozgałęzienie jako rozwidloną linię projek- tową, z wyróżnieniem linii nazywanej rozgałęzieniem lub odgałęzieniem (ang. branch) oraz linią główną projektu nazywaną pniem (ang. trunk). W skład zarówno odgałęzienia, jak i pnia wcho- dzą te same dane do momentu, w którym zostały one rozdzielone — moment ten nazywany jest podstawą (ang. base) odgałęzienia. Od tego momentu dane na temat zmian dokonanych w odgałęzieniu, jak i pniu, przechowywane są oddzielnie. Kolejnym wersjom odgałęzienia nadawane są numery rewizji bazujące na numerze rewizji podstawy odgałęzienia. Odgałęzić można nie tylko pojedynczy plik, ale także ich grupę lub nawet cały projekt, po- dobnie jak przypadku oznakowywania, gdzie można nadawać znaczniki pojedynczym plikom, jak również całej ich grupie. Najlepiej jednak rozgałęziać cały projekt. Doświadczenie wska- zuje na to, że dokonując odgałęzienia jednego pliku, koniec końców trzeba będzie odgałęzić również i inne pliki wchodzące w skład tego samego projektu z tych samych powodów, z ja- kich odgałęziono pierwszy z plików. Dużo łatwiej jest więc śledzić w trakcie projektu poje- dynczą gałąź niż dużą ilość niezwiązanych ze sobą gałęzi, stworzonych dla pojedynczych plików. Znacznik określa rewizję każdego oznakowanego pliku, a oznakowany nim magazyn lokalny nie może być zmodyfikowany. W odróżnieniu od takiego zachowania, za pomocą mechani- zmu rozgałęziania tworzone są zdatne do edytowania rewizje, które mogą być niezależnie synchronizowane z repozytorium, pobierane, aktualizowane i oznakowywane. Pod wieloma względami odgałęzienie można traktować jako zupełnie niezależną linię rozwojową projektu. Plik można oznakować dowolną ilością znaczników, przy czym żadna z nazw znaczników nie może się powtarzać. CVS pozwala również na oznakowywanie odgałęzionych rewizji za pomocą różnych znaczników gałęzi. Bazuje on przy tym na niepowtarzalności nazw znaczni- ków i odgałęzień, przyjmując nazwę odgałęzienia jako nazwę znacznika. Odgałęzienie jest aktywną linią rozwojową projektu, w związku z czym znaczniki są wyko- rzystywane do oznaczania określonych wersji projektu w istotnych dla niego momentach. Po- mimo faktu, iż zarówno odgałęzienia, jak i znaczniki tworzy się za pomocą polecenia cvs tag, ich zadanie jest zgoła różne. Odgałęzienie reprezentuje wiele różnych rewizji, podczas gdy znacznik — tylko jedną. W przypadku niektórych poleceń, takich jak np. cvs diff, system CVS wymaga, aby odgałęzienie wskazywało tylko na jedną rewizję. W takich przypadkach system CVS wskazuje na najnowszą rewizję znajdującą się w danym odgałęzieniu. Odgałęzienia wykorzystywane są często do tego, aby umożliwić testerom przeprowadzenie testów aplikacji na wersji release candidate, gdy przygotowywana jest już ogólnodostępna wersja wydania programu, podczas gdy niezależnie od przeprowadzanych testów może już być opracowywana nowa linia rozwojowa produktu. Odgałęzienia mogą być również wykorzy- stywane do opracowywania w oddzieleniu od głównej linii rozwojowej eksperymentalnych zmian w projekcie, np. do kompletnego przepisania kodu biblioteki. W idealnym przypadku dobrze byłoby mieć świadomość potrzeby stworzenia odgałęzienia jeszcze przed rozpoczęciem modyfikacji plików projektu znajdujących się w magazynie 88 | Rozdział 4. Tworzenie znaczników i odgałęzień lokalnym. Rozgałęzienie projektu z poziomu magazynu lokalnego zaprezentowano w punk- cie „Tworzenie odgałęzienia” znajdującego się w dalszej części tego rozdziału. Zdarzają się sytuacje, gdy świadomość eksperymentalnego charakteru dokonanych zmian lub potrzeba przeprojektowania całej sekcji projektu przychodzi dopiero po zmodyfikowaniu plików. W takich sytuacjach warto utworzyć odgałęzienie projektu umożliwiające śledzenie dokonanych zmian, a które nie będzie wpływało na resztę projektu. Sposób wykonania takiego odgałęzienia został opisany w punkcie „Wsteczne tworzenie odgałęzień” w dalszej części te- go rozdziału. Wsteczne tworzenie odgałęzień może być nieco trudniejsze do wykonania standardowego rozgałęzienia, najlepiej więc planować tego typu działania z wyprzedzeniem. Na rysunku 4.3 zaprezentowano operacje rozgałęzienia projektu. Rewizja 2.6 jest rewizją ba- zową odgałęzienia, a odgałęzienie jako takie jest reprezentowane jako rewizja 2.6.2. Odgałę- zienie posiada własną, niezależną od głównego pnia projektu linię rozwojową, numerowaną począwszy od rewizji 2.6.2.1. Numeracja rewizji głównego pnia jest kontynuowana jako 2.7. Rysunek 4.3. Odgałęzienie Odgałęzienie bazuje na pniu głównym. Jednak zarówno pień, jak i odgałęzienie przechowy- wane są w tym samym pliku znajdującym się w repozytorium, co wiąże się z tym, że polece- nia operujące na tym pliku na poziomie repozytorium mogą wpływać na pień, a także na odgałę- zienie. Przykładowo, ten sam znacznik nie może być użyty w tym samym pliku do oznakowania pnia i odgałęzienia. Oprócz tego, wynik działania polecenia cvs status i cvs log wyświe- tlają całościową informacje na temat pliku, włączając w to informacje zarówno na temat pnia jak i odgałęzienia. Zmiany dokonane w pniu mogą zostać włączone do odgałęzienia, ale także zmiany poczynione w odgałęzieniu mogą zostać włączone do głównego pnia projektu. Dalszy rozwój odgałęzienia może zostać albo porzucony, albo kontynuowany w zależności od przeznaczenia scalenia zmian. Obszary zastosowań odgałęzień Odgałęzienia mają wiele zastosowań. Zwykle są one wykorzystywane do tworzenia oddziel- nych linii rozwojowych projektu, podczas gdy pień służy opracowywaniu głównej linii pro- jektowej produktu. W projektach programistycznych i w zadaniach dotyczących zarządzania treścią, odgałęzie- nia są często wykorzystywane do prac eksperymentalnych, opracowywania wersji kandy- dackich produktu, refaktoryzacji kodu lub treści, a także do wprowadzania poprawek. W przypadku zarządzania konfiguracją za pomocą CVS, pień główny może służyć jako kon- figuracja domyślna, a odgałęzienia jako poszczególne warianty konfiguracyjne, np. jedna ga- łąź odpowiada za konfiguracje usług sieciowych, inna za konfigurację usług związanych z do- starczaniem poczty itd. Rozgałęzianie | 89 Poniższa lista prezentuje niektóre z typowych zastosowań dla różnych typów odgałęzień. Typy odgałęzień opisano w podrozdziale „Strategie rozgałęziania” w dalszej części tego rozdziału. Warianty zastosowań jednego schematu, takie jak przechowywanie konfiguracji serwerów W przypadku zastosowania odgałęzień jako repozytorium wariantów konfiguracyjnych, najlepiej używać długich odgałęzień lub też okazjonalnie — odgałęzień zagnieżdżonych. Dodatkowe zmiany najlepiej wprowadzać w pniu, a następnie scalać je z odgałęzieniem, jeśli jest to wymagane do poprawnego funkcjonowania odgałęzienia. Zarządzanie poprawkami W celu zarządzania poprawkami błędów należy używać długich rozgałęzień, a zmiany scalać z pniem głównym projektu. Prace eksperymentalne, takie jak nowe fragmenty kodu lub np. projekt nowego wyglądu strony W takich wypadkach należy używać krótkich rozgałęzień, a zmiany scalać z pniem głównym. Zasadnicze zmiany projektu, takie jak kompletne przepisanie kodu W zależności od rozpiętości zmian można stosować długie odgałęzienia scalane do pnia, długie odgałęzienia scalane w obu kierunkach, jak i odgałęzienia krótkie. Testowe wersje kandydackie Należy stosować długie odgałęzienia scalane do pnia głównego. Można również pokusić się o konwersję tego typu odgałęzień na odgałęzienia zarządzania poprawkami po wy- puszczeniu pełnej wersji produktu. Tworzenie odgałęzienia Odgałęzienie tworzy się za pomocą polecenia cvs tag lub cvs rtag wraz z opcją -b. Opcja ta może występować w połączeniu z dowolnymi innymi opcjami tych poleceń, odpowiedzialny- mi za tworzenie znaczników. W celu identyfikacji wersji mającej zostać rozgałęzionej można użyć zarówno daty, istniejącego już znacznika lub numeru rewizji. Za pomocą polecenia cvs tag można również utworzyć odgałęzienie na podstawie ostatnio zsynchronizowanej rewizji magazynu lokalnego. Utworzenie odgałęzienia w ten sposób przypo- mina sposób oznaczania plików, jaki opisano w punkcie „Oznaczanie przy pomocy magazy- nu lokalnego”. Przykład 4.10. ilustruje sposób utworzenia odgałęzienia za pomocą polecenia cvs tag z wyko- rzystaniem nazwy znacznika do identyfikacji rewizji do rozgałęzienia. Wydając polecenie cvs update można upewnić się, czy wszystkie pliki z rewizji pre_beta_0.1 znajdują się w magazynie lokalnym. Wyświetlony wynik działania polecenia cvs update pozwala również na upewnienie się, że żaden z plików nie został zmieniony. Przykład 4.10. Tworzenie odgałęzienia bash-2.05a$ cvs update -d -r pre_beta_0-1 . . . bash-2.05a$ cvs tag -r pre_beta_0-1 -b pre_beta_0-1_branch cvs server: Tagging . T Changelog T INSTALL T Makefile 90 | Rozdział 4. Tworzenie znaczników i odgałęzień T README T TODO cvs server: Tagging doc cvs server: Tagging doc/design T doc/design/AcceptanceTest.doc T doc/design/Analysis.rtf T doc/design/Requirements.doc T doc/design/Specification.rtf cvs server: Tagging doc/plan T doc/plan/Schedule.rtf cvs server: Tagging src T src/config.h T src/main.c Odgałęzienie zostaje utworzone w repozytorium, a nie w magazynie lokalnym. Aby rozpo- cząć edycję plików wchodzących w skład odgałęzienia, należy najpierw pobrać pliki do ma- gazynu lokalnego, realizując polecenie cvs checkout, lub zaktualizować magazyn za pomo- cą polecenia cvs update, tak aby odzwierciedlał on odgałęzienie. Dobrą praktyką jest z kolei oznaczanie głównego pnia projektu tuż przed wykonaniem ope- racji rozgałęzienia, z tego względu, że ułatwi to przyszłe scalenie zmian. Aby mieć pewność, że pliki oznaczone jako te, które mają być podstawą odgałęzienia w istocie stają się plikami, na bazie których jest ono wykonywane, należy utworzyć odgałęzienie za pomocą polecenia cvs rtag -r znacznik_podstawy -b znacznik_odgałęzienia nazwa_projektu. Polecenie to wykorzystuje znacznik podstawy do określenia rewizji będącej podstawą do tworzenia na- stępnych odgałęzień. Przykład 4.11 przedstawia sposób, w jaki należy utworzyć znacznik podstawy, a następnie wykonać operację rozgałęzienia. Polecenie cvs status zostało wykorzystane do pokazania stanu znacznika jednego z plików. Przykład 4.11. Oznakowywanie rewizji przed wykonaniem operacji rozgałęzienia bash-2.05a$ cvs tag beta_0-1_branch_root cvs server: Tagging . T Changelog T INSTALL . . . cvs server: Tagging src T src/config.h T src/main.c bash-2.05a$ cvs rtag -r beta_0-1_branch_root -b beta_0-1_branch ewizzard cvs rtag: Tagging wizzard cvs rtag: Tagging wizzard/doc cvs rtag: Tagging wizzard/doc/design cvs rtag: Tagging wizzard/doc/plan cvs rtag: Tagging wizzard/lib cvs rtag: Tagging wizzard/man cvs rtag: Tagging wizzard/src bash-2.05a$ cvs status -v src/main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maing.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Rozgałęzianie | 91 Existing Tags: beta_0-1_branch (branch: 1.9.2) beta_0-1_branch_root (revision: 1.9) pre_beta_0-1 (revision: 1.8) Wsteczne tworzenie odgałęzień W sytuacji, gdy po dokonaniu pewnej ilości zmian, ale jeszcze przed ich zatwierdzeniem w re- pozytorium, powstaje potrzeba wykonania odgałęzienia, należy spróbować utworzyć odga- łęzienie na podstawie wersji przed zmianami. Jeśli zmiany nie zostały jeszcze zatwierdzone, odgałęzienie można wykonać wstecznie, postępując zgodnie z poniższymi wskazówkami: 1. Nie należy wprowadzać zmian do repozytorium, aż do momentu wykonania odgałęzie- nia. Informacja ta jest ważna z tego względu, że wykorzystywana jest funkcja polecenia cvs tag pozwalająca na utworzenie odgałęzienia przed ostatnimi zmianami. Ze względu na brak możliwości wprowadzenia zmian do repozytorium przed rozpoczę- ciem procedury, najlepiej jest utworzyć kopię zapasową zmienionych plików, wydając systemowe polecenie copy. Kopia powinna obejmować cały magazyn lokalny i powinna być przechowywana aż do momentu wprowadzenia zmian do repozytorium. 2. Odgałęzienie należy utworzyć za pomocą polecenia cvs tag -b nazwa_odgałęzienia. Polecenie cvs tag oznakowuje ostatnią rewizję, która została zsynchronizowana z repo- zytorium, właśnie tę, która ma zostać poddana operacji rozgałęziania. Polecenie to nie powoduje modyfikacji magazynu lokalnego. 3. Za pomocą polecenia cvs update -r nazwa_odgałęzienia należy wczytać pliki danego odgałęzienia do magazynu lokalnego. Spowoduje to próbę scalenia plików odgałęzienia z plikami znajdującymi się w magazynie lokalnym, lecz ponieważ pliki z magazynu lo- kalnego bazują na plikach odgałęzienia, operacja scalenia nie wywoła zmiany jakichkol- wiek plików. CVS oznaczy pliki znajdujące się w magazynie lokalnym jako pliki będące częścią odgałęzienia, nadając im lepkie znaczniki. 4. Wydając polecenie cvs commit, należy zapisać zmiany dokonane w plikach do repozyto- rium jako kolejną rewizję odgałęzienia. 5. Sprawdzić poprawność plików, a następnie usunąć pliki tymczasowej kopii zapasowej Powyższy proces bazuje na założeniu, że polecenie cvs tag oznakowuje repozytorium takim, jakie było ono w chwili ostatniego wprowadzenia zmian z magazynu lokalnego. Odgałęzienie jest zatem tworzone dla tego momentu, a ewentualna próba aktualizacji magazynu lokalnego z odgałęzieniem powoduje, że system CVS stara się scalić pliki podstawy, na bazie których został utworzony magazyn lokalny z plikami w nim się znajdującymi, w wyniku czego maga- zyn lokalny pozostaje niezmieniony. Przykład 4.12 przedstawia operację wstecznego utworzenia odgałęzienia. Przykład 4.12. Wsteczne utworzenie odgałęzienia ash-2.05a$ cvs tag -b test_0-1_branch cvs server: Tagging . T config.h T main.c bash-2.05a$ cvs update -r test_0-1_branch cvs server: Updating . M config.h bash-2.05a$ cvs commit 92 | Rozdział 4. Tworzenie znaczników i odgałęzień Po wprowadzeniu zmian do repozytorium można również wykonać operację wstecznego utwo- rzenia rozgałęzienia za pomocą określonej daty, tak jak to pokazano na rysunku 4.2, trzeba jed- nak zastąpić opcję -b nazwa_znacznika, opcją -D data. W przypadku częstego kopiowania i wklejania godzin podawanych przez polecenie cvs log, należy dodatkowo określić strefę czasową UTC za pomocą opcji -D data. Tworzenie magazynu lokalnego odgałęzienia Aby zmodyfikować pliki odgałęzienia, należy pobrać pliki z magazynu lokalnego, będącego protoplastą odgałęzienia, które ma zostać zmodyfikowane. Polecenie cvs commit wydane z po- ziomu magazynu lokalnego odgałęzienia spowoduje wprowadzenie zmian z magazynu lokalne- go odgałęzienia do repozytorium, a polecenie cvs update pobranie plików z repozytorium do magazynu lokalnego. Magazyn lokalny odgałęzienia tworzy się za pomocą polecenia cvs checkout lub cvs update wraz z opcją -r nazwa_znacznika_odgalezienia. Rysunek 4.4 prezentuje operację pobrania plików do magazynu lokalnego odgałęzienia Rysunek 4.4. Magazyn lokalny odgałęzienia CVS oznacza pliki znajdujące się w magazynie lokalnym odgałęzienia lepkim znacznikiem, aby tym samym podkreślić ich przynależność do odgałęzienia. Przykład 4.13 prezentuje spo- sób utworzenia magazynu lokalnego odgałęzienia i raport dotyczący statusu plików, z których jeden oznaczony jest lepkim znacznikiem odgałęzienia. Przykład 4.13. Utworzenie magazynu lokalnego odgałęzienia bash-2.05a$ cvs -d cvs:/var/lib/cvs checkout -r beta_0-1_branch ewizzard cvs server: Updating wizzard U wizzard/Changelog U wizzard/INSTALL . . . cvs server: Updating wizzard/src U wizzard/src/config.h U wizzard/src/main.c bash-2.05a$ cd wizzard/src/ bash-2.05a$ cvs status main.c = = = = = = = = = = = = = = = = = = = = = = = g = = = = = = File: main.c Status: Up-to-date Rozgałęzianie | 93 Working revision: 1.9 Repository revision: 1.9 /var/lib/cvs/wizzard/src/maing.c,v Sticky Tag: beta_0-1_branch (branch: 1.9.2) Sticky Date: (none) Sticky Options: (none) Istnieje możliwość pobrania poszczególnych plików odgałęzienia do głównego magazynu lo- kalnego, jednak taka operacja, skutkująca mieszaniną plików należących do odgałęzienia i pnia, nie jest zalecana. Pobranie pojedynczych plików nie należących do tego samego odgałęzienia lub pnia, co aktualny magazyn lokalny, jest możliwe z poziomu katalogu nie będącego maga- zynem lokalnym. Polecenie cvs update -A umożliwia uaktualnienie plików znajdujących się w maga- zynie lokalnym za pomocą plików z pnia projektu. Polecenie to usuwa znaczniki lepkości i pobiera najnowsze wersje plików należące do pnia. Wszystkie zmiany z ma- gazynu lokalnego wykonane od momentu, gdy zostały pobrane plik,i na których ów magazyn bazuje (rewizji BASE), są scalane z nowo pobieranymi plikami. Magazynu lokalnego odgałęzienia można używać jak normalnego magazynu. Czynności wyko- nywane na poszczególnych rewizjach plików będą jednak bardziej dotyczyły samego odgałę- zienia, a nie pnia projektu. Z kolei czynności dotyczące kopii pliku znajdującego się w repo- zytorium będą dotyczyły wszystkich jego instancji. Przykładowo, polecenie cvs status wydane z poziomu magazynu lokalnego wygeneruje raport przedstawiający status lokalnych kopii plików, numery rewizji pnia dla rewizji roboczych i tych znajdujących się już w repozytorium oraz aktualny znacznik odgałęzienia i rewizji oznaczony jako lepki. Dodawanie i usuwanie plików Po każdym wykonaniu polecenia cvs add lub cvs remove na plikach przechowywanych w ma- gazynie lokalnym odgałęzienia, operacja dodania lub usunięcia plików ogranicza się do pli- ków należących do odgałęzienia i nie obejmuje swoim działaniem pnia. W przykładzie 4.14 pokazano odpowiedź systemu CVS po dodaniu pliku do odgałęzienia. Przykład 4.14. Dodawanie pliku do odgałęzienia bash-2.05a$ cvs add handheld.c cvs server: scheduling file `handheld.c for addition on gbranch `beta_0-1_branch cvs server: use cvs commit to add this file permanently Scalanie odgałęzień Proces scalenia odgałęzienia z pniem powoduje uwzględnienie zmian dokonanych w trakcie istnienia odgałęzienia w najnowszej wersji kodu pnia. To, czy działanie takie jest pożądane, zależy od powodu, dla którego zostało ono utworzone. Jednym z takich powodów może być włączenie poprawek do kodu głównego, innym — chęć włączenia zawartości eksperymen- talnego odgałęzienia do kodu głównego. Można również scalić zmiany z kodu głównego do odgałęzienia lub połączyć razem zawartość dwóch odgałęzień. Oznakowanie odgałęzienia w momencie scalenia go z pewnością należy do dobrej praktyki. Znaczniki takie zachowują się niczym markery wskazujące na to, kiedy miało miejsce każde scalenie. 94 | Rozdział 4. Tworzenie znaczników i odgałęzień Po scaleniu dwóch odgałęzień lub odgałęzienia i pnia, zwykle w efekcie otrzymuje się jeden element zmodyfikowany i jeden, który pozostał bez zmian. Po scaleniu zmian z odgałęzienia do pnia głównego, a następnie po wprowadzeniu do repozytorium zmian z magazynu lokal- nego, następna rewizja kodu głównego będzie uwzględniała wszystkie te zmiany. Aby móc jednak pracować na kopii kodu głównego pozbawionej scalonych zmian, należy rozważyć scalenie kodu głównego z odgałęzieniem lub utworzenie nowego odgałęzienia zawierającego zarówno dane wchodzące w skład kodu głównego, jak i dane z odgałęzienia. Kończąc pracę z odgałęzieniami logicznym poleca się usunięcie jej lub zamknięcie jej w jaki- kolwiek inny sposób. CVS jednak nie oczekuje na to, iż niewykorzystywane odgałęzienia bę- dą usuwane. Zamiast tego przechowuje on je jako część zapisu projektu. Nie istnieje również żadne polecenie oznakowujące dane odgałęzienie jako nieużywane. Jako znacznika końcowego odgałęzienia należy użyć komunikatu dziennika. Za pomocą polecenia cvs commit -f można wymusić na CVS zsynchronizowanie z repozytorium plików, w których nie zostały dokonane żadne zmiany, po to aby móc wprowadzić do dziennika komunikat na temat wykonanego scalenia tych plików. Scalanie zmian z odgałęzienia do kodu głównego W celu scalenia zmian z odgałęzienia do kodu głównego, należy najpierw pobrać pliki do aktu- alnego magazynu lokalnego pnia, a następnie uruchomić polecenie cvs update -j znacznik_ bazowy_odgałęzienia -j nazwa_odgałęzienia. Następnie konieczne jest rozwiązanie wszystkich zgłoszonyh przez operację scalenia konfliktów i wprowadzenie zmian do repo- zytorium. Jeżeli wprowadzane zmiany mają złożony i kompleksowy charakter, rozwiązaniem konfliktów powinien zająć się jeden z deweloperów lub osoba prowadząca projekt, odpo- wiedzialna za zarządzanie odgałęzieniami i kodem głównym. W przypadku, gdy odgałęzienie zostało już wcześniej scalone z kodem głównym i zostało ono również na tym etapie oznakowane, polecenie cvs update -j znacznik_ostataniego_ scalenia -j nazwa_odgałęzienia spowoduje scalenie zmian dokonanych od czasu ostatniej operacji. Przykład 4.15 przedstawia proces scalenia odgałęzienia z kodem głównym. W tym wypadku CVS odmówił usunięcia zmienionego pliku z kodu głównego, lecz usunął taki plik w odga- łęzieniu. Przykład ten demonstruje również operacje dodania pliku handheld.c utworzonego wcześniej w odgałęzieniu. Przykład 4.15. Scalanie zmian z odgałęzienia do kodu głównego bash-2.05a$ cvs update -j beta_0-1_branch_root -j beta_0-1_branche cvs server: Updating . cvs server: file config.h has been modified, but has beegn removed in revision beta_0- 1_ branch U handheld.c Scalanie zmian z kodu głównego do odgałęzienia Przed scaleniem zmian z kodu głównego do odgałęzienia konieczne jest pobranie plików do aktualnego magazynu lokalnego odgałęzienia, a następnie uruchomienie z poziomu tego ma- gazynu polecenia cvs update -j znacznik_bazowy_odgałęzienia -j HEAD. Następnie należy Rozgałęzianie | 95 rozwiązać wszystkie zgłoszone przez operację scalenia konflikty i wprowadzić zmiany do repozytorium. Jeżeli wprowadzane zmiany mają złożony i kompleksowy charakter, rozwią- zaniem konfliktów powinien zająć się jeden z deweloperów lub osoba prowadząca projekt, odpowiedzialna za zarządzanie odgałęzieniami i kodem głównym. W przypadku, gdy kod główny został już wcześniej scalony z odgałęzieniem i został on również na tym etapie oznakowany, polecenie cvs update -j znacznik_ostataniego_scalenia -j HEAD spowoduje scalenie zmian dokonanych od czasu ostatniej operacji. Przykład 4.16 prezentuje wynik próby scalenia kodu głównego z odgałęzieniem. Plik config.h został usunięty z odgałęzienia, lecz nadal jest obecny w kodzie głównym. Konflikt ten musi zostać rozwiązany, najprawdopodobniej poprzez anulowanie operacji usunięcia. Z kolei plik handheld.c nie istniał wcześniej w kodzie głównym, lecz ponieważ został do niego dodany podczas operacji scalenia zaprezentowanej w przykładzie 4.15, w związku z tym wygenero- wany komunikat o błędzie dotyczący tego pliku może zostać zignorowany. Przykład 4.16. Scalanie zmian z kodu głównego do odgałęzienia bash-2.05a$ cvs update -j beta_0-1_branch_root -j HEAD cvs server: Updating . cvs server: file config.h does not exist, but is presentg in revision HEAD cvs server: file handheld.c exists, but has been added ign revision HEAD U server.c Scalanie zmian z odgałęzienia do odgałęzienia Scalenia zmian z jednego odgałęzienia do drugiego można dokonać pobierając pliki do maga- zynu lokalnego odgałęzienia docelowego, a następnie uruchomiając polecenie cvs update -j bazowa_nazwa_znacznika -j nazwa_drugiego_odgałęzienia. Dzięki temu scalona zostanie tym samym zawartość jednego magazynu lokalnego z drugim, odświeżonym przed chwilą, magazynem lokalnym odgałęzienia. W przypadku gdy dane odgałęzienia były już wcześniej scalane, a odgałęzienie źródłowe na tym etapie oznakowane, polecenie cvs update -j znacznik_ostataniego_scalenia -j nazwa_ odgałęzienia uruchomione z poziomu magazynu lokalnego odgałęzienia docelowego spo- woduje scalenie zmian dokonanych od czasu ostatniej operacji. Słowa kluczowe a scalanie odgałęzień Zastąpienia słów kluczowych (patrz: rozdział 3.) mogą powodować konflikty w trakcie sca- lania dwóch różnych rewizji plików. Najczęstszą przyczyną konfliktów jest słowo kluczowe Revision, ponieważ zostaje ono zastąpione aktualną rewizją pliku. Konfliktów tych można uniknąć za pomocą trybu zastępowania słów kluczowych -kk, dzięki któremu słowa kluczowe nie są zastępowane odpowiednimi wartościami. Tryb -kk może spowodować uszkodzenie plików binarnych, jeżeli będą one zawie- rały łańcuch znaków, który CVS rozpozna jako nazwę lub wartość słowa kluczowego. 96 | Rozdział 4. Tworzenie znaczników i odgałęzień Scalanie plików binarnych i plików specjalnych Zmiany poczynione w plikach binarnych, jak również w innych plikach, których nie da się scalić, nie mogą niestety zostać automatycznie scalone. Pliki takie mogą być scalone, pod wa- runkiem że istnieją dla nich odpowiednie narzędzia działające na podobnych zasadach jak narzędzia diff i patch dla plików tekstowych. W innym wypadku scalenie tego rodzaju plików trzeba będzie przeprowadzić ręcznie. Fakt ten powinien zostać wzięty pod rozwagę przy planowaniu rozgałęziania linii rozwojowej tego typu plików. Numery rewizji odgałęzień Numery rewizji zwykłych plików składają się z prefiksu oraz ze zwiększającego się sko- kowo identyfikatora, stąd też po zatwierdzeniu kolejnych zmian po rewizji 1.1 następuje rewizja 1.2, 1.3 i 1.4. Numer rewizji plików odgałęzienia tworzony jest na podstawie numeru rewizji, z której zo- stało ono odgałęzione. A zatem numerami rewizji dla odgałęzienia 1.4.2 będą numery 1.4.2.x, gdzie za x należy przyjąć zmieniający się identyfikator rewizji. Warto przy tym pamiętać, że odgałęzienie nie składa się z pojedynczej rewizji, w jego skład wchodzi cała linia rewizji. Na rysunku 4.5 pokazano rozgałęziony plik wraz z kolejnymi numerami jego rewizji. Rysunek 4.5. Numery rewizji System CVS nie nadaje nigdy odgałęzieniu stworzonemu przez użytkownika numeru 1.1.1, ten konkretny numer rewizji zarezerwowany jest dla specjalnej gałęzi nazywanej gałęzią dostawcy. Numery specjalne odgałęzień System CVS wstawia czasami na pozycji drugiej z prawej strony numeru odgałęzienia cyfrę 0. Czyni to, aby zapewnić lepszą wydajność samego systemu CVS. Skutek takiego działania może czasem
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

CVS bez tajemnic
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: