CVS Zarządzanie kodem źródłowym

Transkrypt

1 CVS Zarządzanie kodem źródłowym Plan przedmiotu wykład i ćwiczenia Marek Kubiak Dawid Weiss kwiecień 2003 październik 2003 Historia zmian $Log: cvs-zajecia.tex,v $ Revision /11/05 10:00:44 dweiss administracja serwerem Revision /11/04 11:14:15 dweiss Added nicer pdf output rendering Revision /11/04 10:58:57 dweiss added branching and tagging. Revision /11/04 08:21:09 dweiss Added CVS authorisation methods section and table of contents. Revision /10/29 17:11:49 dweiss added marek s stuff, added examples. Spis treści 1 Czym jest repozytorium CVS? 2 2 Sposoby dostępu do serwera CVS 2 3 CVS z linii poleceń 3 4 CVS i WinCVS podstawowe operacje Uruchamianie WinCVS Tworzenie nowego repozytorium lokalnego Tworzenie nowego projektu w repozytorium Pobieranie aktualnej wersji plików z repozytorium Uaktualnianie repozytorium Usuwanie lokalnej kopii plików pobranych z CVS Porównywanie plików kopii roboczej i wersji w repozytorium Dodawanie plików do repozytorium Uaktualnianie plików kopii roboczej Logowanie do repozytorium w metodzie pserver Ignorowanie plików tymczasowych.cvsignore

2 5 Programy porównujące CSDiff WinMerge Araxis Merge Meld Eclipse Przebieg laboratorium - część I Podstawy użytkowania CVS (90 minut) Manipulacje plikami i wersjami Rozwiązywanie konfliktów (symulacja współbieżnego dostępu do repozytorium) CVS tagowanie oraz rozgałęzianie projektu Powrót lub checkout danej wersji projektu Gałęzie Przechodzenie między gałęziami Łączenie gałęzi z główną linią rozwojową Przykład tworzenia gałęzi i przechodzenia między gałęziami Administracja serwerem CVS Konfiguracja serwera Dodawanie użytkowników do CVS (pserver) Użytkownicy z prawem tylko do odczytu Pliki administracyjne CVSROOT Dodanie powiadomień owych o commitach Inne materiały Czym jest repozytorium CVS? Repozytorium CVS to pewien katalog w systemie plików (lokalnym lub zdalnym) w którym CVS przechowuje informacje o wszystkich wersjach plików wstawionych przez użytkowników. Pliki tekstowe są przechowywane tak, że uwzględniane są tylko różnice pomiędzy kolejnymi wersjami. Dowolną wersję pliku tekstowego system może odtworzyć jednoznacznie przez przeglądnięcie zmian. Pliki binarne są przechowywane w całości (dlatego też każde wstawienie nowej wersji pliku binarnego powoduje zwiększenie się rozmiaru repozytorium o przynajmniej rozmiar tego pliku). 2 Sposoby dostępu do serwera CVS Kluczową rolę w zrozumieniu jak działa CVS odgrywa zmienna o nazwie CVSROOT. Przez analogię do SSH, lub usługi telnet, CVSROOT jest jakby unikalnym identyfikatorem (URI ), specyfikującym sposób dostępu do repozytorium. Składnia zmiennej CVSROOT jest następująca: 2

3 :met_dostępu:adres_serwera:ścieżka_na_serwerze Gdzie, odpowiednio: met dostępu może przyjmować wartości: local jest to określenie repozytorium znajdującego się na dysku lokalnym. W naszych ćwiczeniach będziemy stosowali właśnie ten trub dostępu, chociaż ogólnie nie stosuje się go ze względu na brak możliwości autoryzacji. Przykład zmiennej CVSROOT (system Windows) :local:e:\repozytorium. pserver najpopularniejszy sposób dostępu. Wymaga podania adresu serwera, poprzedzonego nazwą użytkownika, podobnie jak w adresach owych. Ostatni człon stanowi ścieżkę w systemie plików serwera, gdzie znajduje się repozytorium. W ogólności bowiem, jeden serwer może mieć więcej niż jeden CVSROOT. Przykład zmiennej CVSROOT (dla obu systemów taki sam!) :pserver:dweiss@ophelia.cs.put.poznan.pl:/students/cvs. W przypadku korzystania z metody pserver wymagana jest autoryzacja (zob. p. 4.10). Istnieją również inne metody dostępu do zdalnych serwerów (np. oparte o wymianę kluczy i program SSH). Nie są one przedmiotem zajęć. 3 CVS z linii poleceń Klient programu CVS nazywa się po prostu cvs i jest zazwyczaj dostępny w każdej dystrybucji systemu Linux. Przy instalacji Win- CVS (zob. 4), należy do zmiennej systemowej PATH dodać sobie katalog CVSNT, znajdujący się w podkatalogu instalacyjnym WinCVS. CvsNT to właściwie osobny produkt który zawiera również serwer CVS, dla użytkowników systemu Windows. Pomocny w zapamiętaniu poleceń CVS może okazać się reference card z 4 CVS i WinCVS podstawowe operacje Jest to darmowy front-end CVS dla środowiska Windows. Zawiera również zintegrowane narzędzie dostępne z linii poleceń, jak i tryb dostępu local, który umożliwia tworzenie repozytoriów lokalnych, bez uruchamiania usługi pserver. Program darmowy. Strona internetowa: 3

4 4.1 Uruchamianie WinCVS Po uruchomieniu należy ustawić podstawowe właściwości programu, takie jak katalog domowy (gdzie będą pobierane pliki ze zdalnego repozytorium?) i sposób dostępu do repozotorium (zmienna CVSROOT). Należy wybrać: Admin Preferences. Warto zmienić opcję read-only w Globals Checkout na niezaznaczoną, aby istniała w przyszłości możliwość zmiany plików pobranych z CVS. 4.2 Tworzenie nowego repozytorium lokalnego Przed rozpoczęciem wykorzystywania CVS należy utworzyć katalog, w którym system będzie przechowywał pliki użytkowników i własne pliki systemowe. Może to być np.: /Temp/Repository, lub też, dla systemu Windows: c:\temp\repository. Po utworzeniu katalogu należy w programie WinCVS wybrać: Create Create a new repository. W oknie dialogowym, w zakładce General, należy wpisać lokalizację katalogu przeznaczonego na repozytorium. CVS utworzy w tym katalogu pliki potrzebne do zarządzania plikami użytkowników repozytorium jest przygotowane do działania. 4.3 Tworzenie nowego projektu w repozytorium Stworzenie nowego projktu w repozytorium na podstawie katalogu z plikami: Create Import module. Po wskazaniu katalogu należy jeszcze potwierdzić określenie typu zawartości plików (tekstowe lub binarne) to wpływa na sposób przechowywania plików w repozytorium. Nie określenie typu pliku jako binarny spowoduje jego bezpowrotne zniszczenie. Przy imporcie CVS określa pliki jedynie na podstawie ich rozszerzenia. Po ustawieniu podaje się jeszcze dodatkowe komentarze (uwaga na pola vendor i release muszą być identyfikatorami bez znaków specjalnych i spacji) i potem następuje wstawienie całego katalogu do CVS. Pliki w lokalnym katalogu, które były dodawane do CVS, nie są jeszcze uważane przez WinCVS za pliki CVS nie zostały one pobrane z repozytorium i nie podlegają nadzorowi systemu. Dopiero pliki pobrane z CVS (lub faktycznie dodane do projektu) są nadzorowane przez niego. Pliki lokalne można po prostu usunąć. 4.4 Pobieranie aktualnej wersji plików z repozytorium Pliki pobiera się przez opcję: Create Checkout module. W otwartym oknie należy wpisać nazwę modułu (projektu) pobieranego i 4

5 lokalizację, do której ma być on pobrany (kopia lokalna) i po akceptacji pliki zostają pobrane. 4.5 Uaktualnianie repozytorium Uaktualnienie repozytorium zmienionymi plikami: Modify Commit selection. Należy przy tym zaznaczyć, które pliki mają być uaktualniane można zaznaczyć cały katalog, wtedy wszystkie zmiany będą wzięte pod uwagę. Przy uaktualnianiu repozytorium można podać dodatkowy komentarz. 4.6 Usuwanie lokalnej kopii plików pobranych z CVS Po uaktualnieniu repozytorium można usunąć lokalną kopię plików ręcznie, albo też użyć do tego opcji: Trace Release selection. Różnica jest taka, że przed usunięciem plików CVS jeszcze raz sprawdzi, czy wszystkie zmiany zostały wprowadzone do repozytorium (żebyśmy nie usunęli zmian, które jeszcze w repozytorium nie są). Po dodatkowym potwierdzeniu pliki mogą być także fizycznie usunięte. 4.7 Porównywanie plików kopii roboczej i wersji w repozytorium Jeśli posiadamy pobraną do lokalnego katalogu kopię roboczą plików, to możemy zobaczyć, czy od ostatniego pobrania dokonaliśmy jakiś zmian w plikach. Służy do tego Query Diff selection. Można do porównywania plików użyć zewnętrznego programu porównującego (należy ustawić dostęp do niego w Admin Preferences w zakładce WinCVS i wybrać opcję External diff program w dialogu). Sprawdzone jest poprawne działanie programów: CSDiff 1, WinMerge 2, Araxis Merge 3 (commercial). Zobacz również rozdział Dodawanie plików do repozytorium Dodanie pliku stworzonego w kopii roboczej wymaga zaznaczenia go i wykonania Modify Add selection. Jeśli plik jest binarny, to należy użyć polecenia Modify Add selection binary. To polecenie informuje CVS, że należy traktować dodany plik jak element kopii roboczej, ale nie dodaje go jeszcze do repozytorium. Dopiero następne uaktualnienie repozytorium tego dokona (zobacz 4.9). 1 Zob. p Zob. p Zob. p

6 4.9 Uaktualnianie plików kopii roboczej W sytuacji, gdy programista A pracuje na plikach kopii roboczej (lokalnej), inny programista (B) może zmienić niektóre pliki w swojej kopii roboczej i uaktualnić repozytorium. Wtedy programista A może chcieć uaktualnić swoją kopię roboczą aktualnymi wersjami plików z repozytorium (zawierającymi zmiany programisty B). Do pobrania aktualnych wersji plików służy polecenie Modify Update selection. Opcja Query Query update powoduje tylko zapytanie CVS o zmiany, które zaszły w repozytorium od ostatniego pobrania plików zmiany w stosunku do aktualnej kopii roboczej. Żadne zmiany nie są wprowadzane w kopii lokalnej plików, tylko jest wyświetlana informacja o różnicach w stosunku do repozytorium Logowanie do repozytorium w metodzie pserver Aby zalogować się do zdalnego repozytorium należy wydać polecenie (po ustawieniu zmiennej środowiskowej CVSROOT): cvs login CVS spyta wtedy o hasło dostępu. Hasło jest składowane w katalogu domowym użytkownika w formie przemielonej programem crypt (co nie jest zbyt bezpieczne) Ignorowanie plików tymczasowych.cvsignore Czasami zachodzi potrzeba ignorowania pewnych plików, by nie pojawiały się jako znaki zapytania (pliki lokalne, których nie ma w repozytorium) w momencie wydania polecenia update. Funkcjonalność taką można zapewnić dodając do katalogu, gdzie znajdują się te pliki, plik tekstowy o nazwie.cvsignore. W nim wpisujemy nazwy wszystkich plików (katalogów), które chcemy ignorować. Nazwy mogą zawierać znaki specjalne * i?. Przykładowa zawartość pliku.cvsignore może być np. taka: build dist *.tmp *.bak 6

7 5 Programy porównujące 5.1 CSDiff Program darmowy, strona domowa: com/products/csdiff/. Posiada dość niestandardowy sposób prezentacji różnic pomiędzy plikami nie pokazuje naraz dwu plików, ale w jednym oknie pokazuje treść połączoną, zaznaczając usunięcia, zmiany i dodania w tym jednym oknie. 5.2 WinMerge Program darmowy, strona domowa: net/. W dosyć jasny i intuicyjny sposób pokazuje w dwu oknach różnice pomiędzy plikami. 5.3 Araxis Merge Program komercyjny ( ale dostępny w wersji trial (30-dniowej). Pozwala na porównywanie w jednym momencie dwóch lub trzech plików. Przy porównywaniu 2 plików (podobnie do WinMerge) zakłada, że w lewym panelu jest starsza wersja pliku (punkt odniesienia dla statystyk). Pokazuje statystyki zmian (liczbę usunięć, zmian i wstawień w pasku stanu). Pozwala na natychmiastowe edytowanie plików i zapisanie ich. Również na przenoszenie zmian pomiędzy plikami przez kliknięcie przycisku przy zaznaczonej zmianie. Ciekawe są opcje szczegółowości badania zmian np. na poziomie pojedynczych liter, słów, linii tekstu. W opcjach można również wybrać pomijanie spacji w porównaniach, lub też w ogóle pomijanie pewnych fragmentów w porównywaniu, jeśli pasują do pewnego wyrażenia regularnego (np. komentarz C++, Visual Basic) można zdefiniować własne wyrażenia regularne. Możliwe jest też porównywanie katalogów, pomijanie w porównaniach pewnych typów plików (np. typu obj plików generowanych, a nie źródłowych). Program pozwala na drukowanie raportów z porównania (w formie jak na ekranie). 5.4 Meld Program Meld ( jest darmową alternatywą dla użytkowników systemów Linux-owych. Na screenshotach wygląda bardzo dobrze. 7

8 5.5 Eclipse Dobry wizualny diff jest wbudowany w środowisko Eclipse (http: // Działa również z widokiem CVS, który to środowisko posiada (choć czasem są z nim problemy, więc uwaga!). 6 Przebieg laboratorium - część I 6.1 Podstawy użytkowania CVS (90 minut) Manipulacje plikami i wersjami Studenci otrzymują plik.zip z kilkoma różnymi wersjami tych samych plików (kolejne wersje są ponumerowane lub oznaczone datą). Podane poniżej przykłady komend CVS są wzięte z systemu Linux, lub też z wersji WinCVS, która zawiera polecenie cvs uruchamiane z linii poleceń. Odpowiednie funkcje można również uzyskać z GUI programu WinCVS. 1. dotyczy jedynie wersji command-line: Ustalenie adresu repozytorium zmiennej CVSROOT. Adres można ustawić również przekazując za każdym razem do komendy cvs parametr -d, np. cvs -d:pserver:dweiss@myserver.com:/cvsrep. Adres repozytorium składa się z paru części: :metoda dostepu :sciezka na serwerze Najczęściej stosowaną metodą dostępu jest pserver, która wymaga podania użytkownika i serwera. W WinCVS popularna jest również metoda local, która umożliwia dostęp do lokalnego repozytorium. Ustawienie zmiennej CVSROOT (przykład): Windows: SET CVSROOT=c:\temp\repository Unix (bash): CVSROOT=/usr/local/cvsroot; export CVSROOT 2. dotyczy jedynie trybu dostępu pserver : Należy się najpierw zalogować. cvs login 3. Utworzenie nowego repozytorium CVS (utworzenie plików administracyjnych). cvs -d init 8

9 4. Stworzenie lokalnego katalogu z pierwszą wersją źródłowych plików demonstracyjnych. mkdir local unzip examples.zip cp examples/plik_wersja1.txt local/plik.txt cp examples/plik-bin.zip local/plik.zip 5. Utworzenie nowego projektu w repozytorium na podstawie katalogu z plikami źródłowymi. cd local cvs import -m "initial release" -W "*.zip -k b " newproject avendor arelease 6. Usunięcie lokalnego katalogu (przez mechanizmy systemu operacyjnego). cd.. rm -rf local (Windows: del /Q/S local) 7. Pobranie najnowszej wersji plików z repozytorium do wskazanego katalogu lokalnego. cvs co -d local newproject 8. Modyfikacja plików w katalogu lokalnym (symulacja modyfikacji przez zamianę wersji 1. plików demonstracyjnych wersją 2.) cp examples/plik_wersja2.txt local/plik.txt 9. Utworzenie nowego pliku w katalogu lokalnym (np. tekstowego). echo "Nowy plik" >local/nowy-plik.txt 10. Sprawdzenie stanu lokalnego w stosunku do repozytorium: (opcja -n powoduje, że nic nie zostaje tak na prawdę zmienione). cd local cvs -n -q update -d -P Wynikiem powinno być: M plik.txt? nowy-plik.txt 9

10 Czyli jeden plik poddano modyfikacjom, drugi zaś jest jedynie lokalny. 11. Dodanie nowego pliku do projektu (nie wprowadza jeszcze do repozytorium). cvs add nowy-plik.txt Tym razem update daje flagę A, oznaczającą, że plik dodano lokalnie. A nowy-plik.txt M plik.txt 12. Uaktualnienie repozytorium nowymi wersjami plików. cvs commit -m "wprowadzono fajne zmiany" 13. Usunięcie lokalnego katalogu (przez mechanizmy CVS sprawdzające, czy wszystkie zmiany zostały przeniesione już repozytorium). cd.. cvs release -d local Powinno się pojawić coś na kształt: You have [0] altered files in this repository. Are you sure you want to release (and delete) directory local : 14. Ponowne pobranie najnowszej wersji plików z repozytorium do katalogu lokalnego. 15. Ponowna modyfikacja plików w katalogu lokalnym (symulacja modyfikacji przez zamianę wersji 2. plików demonstracyjnych wersją 3.). Usunięcie pliku plik.zip. cp examples/plik_wersja3.txt local/plik.txt rm local/plik.zip 16. Obserwacja zmian w plikach pomiędzy wersją lokalną i aktualną wersją w repozytorium. M plik.txt cvs update: warning: plik.zip was lost U plik.zip 10

11 Jak widać, CVS podpowiada, że polecenie update uaktualni (przywróci) lokalną wersję pliku plik.zip jest to często stosowana metoda przywracania stanu pliku z repozytorium (usuń i wykonaj update). Aby faktycznie usunąć plik z repozytorium (tzn. oznaczyć go jako usunięty), należy wykonać polecenie: cvs remove plik.zip 17. Obserwacja zmian w plikach pomiędzy wersją lokalną i starszą wersją w repozytorium (to samo polecenie, ale w oknie dialogowym należy np. wpisać nr wersji 1.1 ). W wersji z linii poleceń: cvs diff plik.txt Pojawia się: diff -r1.2 plik.txt 4,5d3 < W sumie nieczego w nim nie ma. < 6a5,7 > > A teraz usunieto jedna linie. > Porównanie z poprzednią wersją: cvs diff -r1.1 plik.txt 18. Uaktualnienie repozytorium nowymi wersjami plików. 19. Sprawdzenie logu dla pliku cvs log plik.txt Rozwiązywanie konfliktów (symulacja współbieżnego dostępu do repozytorium) Ten akapit wymaga poprawek i uaktualnienia. 1. Utworzenie nowego projektu (np.: Concurrency) z prostymi plikami źródłowymi, np. tekstowymi lub malutkimi.java). 2. Wprowadzenie tego projektu do repozytorium. 11

12 3. Utworzenie dwu kopii lokalnych tego samego projektu z repozytorium (locala i localb) dla dwu programistów (początek współbieżnego działania). 4. Modyfikacja kopii locala przez programistę A (np. wprowadzenie metody oznaczenie w komentarzu, że autorem zmiany jest programista A). 5. Zaktualizowanie repozytorium przez programistę A (bez problemu). 6. Modyfikacja kopii localb przez programistę B (z zaznaczeniem autorstwa zmiany). 7. Próba zaktualizowania repozytorium przez programistę B (niemożliwe CVS na to nie pozwoli, bo są niespójności. Programista A dokonał już zmian współbieżnie z programistą B i zmiany tego pierwszego zostałyby utracone). 8. Sprawdzenie przez programistę B różnic z aktualną wersją przez mechanizmy CVS (Query Query update). CVS podaje listę plików z konfliktami. 9. Sprawdzenie przez programistę B różnic z aktualną wersją repozytorium prze porównanie plików (Query Diff selection). Użycie zewnętrznego narzędzia do sprawdzania różnic. 10. Pobranie przez programistę B do swojego katalogu localb (lub obu programistów podczas spotkania) aktualnej wersji plików z repozytorium w celu rozstrzygnięcia konfliktów: (Modify Update selection). CVS sciąga najnowszą wersję konfliktowego pliku ze zmienioną nazwą (rozpoczynającą się od znaku #), a plik o właściwej nazwie uaktualnia o zmiany zebrane z dwu źródeł (z repozytorium i z pliku lokalnego). Ten plik jest oznaczony jako konfliktowy. 11. Edycja pliku zaznaczonego jako konfliktowego i usunięcie konfliktów (zwykle wspólnie przez programistów A i B zewnętrzny edytor). 12. Wprowadzenie już zsynchronizowanej wersji do repozytorium (bez problemu). 7 CVS tagowanie oraz rozgałęzianie projektu Projekty programistyczne podlegają zazwyczaj linearnej ewolucji kolejne wersje projektu zastępują poprzednie. Numery wersji 12

13 poszczególnych plików rzadko kiedy jednak odzwierciedlają aktualną wersję oprogramowania. Właśnie w tym celu aby oznaczyć wszystkie pliki obecne w projekcie w danej chwili przy pomocy jednego znacznika wprowadzono do CVS tagi. Tag pozwala na związanie wszystkich wersji plików w repozytorium przy pomocy symbolicznej nazwy, zob. np: file1 file2 file3 file4 file /--1.1* <-*- TAG 1.2* *- 1.3 \- 1.3*- 1.3 / \ 1.4 / 1.4 \-1.5* (źródło: 4.html#SEC44). Dodanie tagu do aktualnej wersji w lokalnej kopii repozytorium realizuje polecenie: cvs tag nazwa znacznika. Nazwa znacznika nie może zawierać znaków specjalnych (jedynie liczby, znaki alfanumeryczne, znak podkreślenia i myślnika). 7.1 Powrót lub checkout danej wersji projektu Checkout oznakowanej wersji z repozytorium uzyskuje się poprzez wydanie polecenia: cvs checkout -r nazwa_znacznika Należy pamiętać o tym, że tak pobrane pliki bedą pamiętały swoje pozycje w drzewie wersji (jest to tak zwany sticky tag ). Nanoszone zmiany nie zostaną zaakceptowane przez CVS, ponieważ same etykiety tagów nie stanowią o rozgałęzieniu drzewa wersji do tego służą gałęzie (ang. branch). Przykład odrzuconej przez CVS zmiany po pobraniu wersji projektu z zaznaczeniem specyficznej etykiety: cvs commit: Examining. cvs commit: sticky tag ver_1 for file plik1.txt is not a branch cvs commit: Examining subdir cvs [commit aborted]: correct above errors first! 7.2 Gałęzie Aby faktycznie rozdzielić wersje projektu na dwie niezależne linie rozwojowe, należy użyć rozgałęzień (ang. branches). Rozgałęzienia 13

14 przydają się, gdy istnieje potrzeba np. poprawiania błędow w danej wersji (oznaczonej jakimś tagiem), a cała linia rozwojowa produktu uległa już znacznym zmianom i nie da się poprawek tych wprowadzić na wersji bieżącej (oznaczonej zawsze tagiem HEAD). Podobnie jak tagi, gałęzie posiadają swoje nazwy. Dodatkowo, CVS nadaje plikom rozszerzony numer wersji, który składa się z podstawowej wersji w momencie rozgałęzienia, oraz nowego numeru, liczonego już w gałęzi. Aby rozgałęzić projekt na danym tagu, należy wydać polecenie: cvs rtag -b -r nazwa_tagu nazwa_gałęzi moduł Przykładowo, może to być: cvs rtag -b -r ver_1 ver_1_branch_bugfix test Przechodzenie między gałęziami Przechodzenie między gałęziami można realizować na jednej lokalnej kopii repozytorium przy pomocy polecenia update, jednak jest to dość dziwaczne, szczególnie dla nowicjuszy. Łatwiej, i bardziej intuicyjnie, jest zrobić sobie dwie kopie repozytorium projektu jedna rozwojowa (HEAD), druga zaś z zawartością danej gałęzi. W każdym razie, dla chcących poeksperymentować (zakładając, że mamy już gałąź ver 1 branch bugfix, można do niej przejść wydając polecenie: cvs update -r ver_1_branch_bugfix -d -P Polecenia -d oraz -P powodują również pobranie katalogów (modułów) z danej gałęzi, które nie istnieją w aktualnej kopii repozytorium, oraz skasowanie tych, które w danej gałęzi nie istnieją. Powrót do głównego korzenia uzyskujemy przy pomocy: cvs update -d -P Proszę spróbować wykasować jakieś pliki, lub je zmodyfikować na gałęzi, zrobic commit, a następnie przechodzić między wersją rozwojową i gałęzią Łączenie gałęzi z główną linią rozwojową Połączenie gałęzi z główną linią rozwojową uzyskuje się na parę sposobów. Ogólnie, to nigdy nie jest to proces automatyczny i należy dbać o to, co się robi. Obszerny tutorial na ten temat znajduje się pod adresem: http: // zob. rozdział Branching and merging. 14

15 7.3 Przykład tworzenia gałęzi i przechodzenia między gałęziami W niniejszym przykładzie zostało utworzone lokalne repozytorium (w środowisku Windows), w którym utworzono parę plików, oraz podmoduły. Pokazano jak utworzyć gałąź i jak przejść między gałęziami na otwartej kopii lokalnej repozytorium. # TWORZENIE REPOZYTORIUM F:\tmp>SET CVSROOT=:local:F:\tmp\repos 5 F:\tmp>cvs init # TWORZENIE MODUŁU DO IMPORTU ORAZ IMPORT F:\tmp>mkdir test 10 F:\tmp>cd test F:\tmp\test>echo >plik1.txt "Oto plik1." F:\tmp\test>mkdir subdir F:\tmp\test>echo >subdir\plik2.txt "Oto plik2." F:\tmp\test>cvs import -m "Initial import." test avendor arelease 15 N test/plik1.txt cvs import: Importing F:\tmp\repos/test/subdir N test/subdir/plik2.txt No conflicts created by this import 20 # PIERWSZY CHECKOUT I SKASOWANIE MODUŁU LOKALNEGO F:\tmp\test>cd.. F:\tmp\test>rmdir /S/Q test 25 F:\tmp>cvs co test cvs checkout: Updating test U test/plik1.txt cvs checkout: Updating test/subdir U test/subdir/plik2.txt 30 F:\tmp>cd test # UTWORZENIE TAGU DLA WERSJI PIERWSZEJ (KTÓRA PÓŹNIEJ JEST ROZGAŁĘZIONA) 35 F:\tmp\test>cvs tag version_1 cvs tag: Tagging. T plik1.txt cvs tag: Tagging subdir T subdir/plik2.txt 40 # DALSZA PRACA NA GŁÓWNEJ WERSJI F:\tmp\test>mkdir subdir2 F:\tmp\test>echo >subdir2\plik3.txt "Oto plik 3 w HEAD" 45 F:\tmp\test>cvs remove -f subdir\plik2.txt 15

16 cvs remove: scheduling subdir/plik2.txt for removal cvs remove: use cvs commit to remove this file permanently F:\tmp\test>cvs remove -f plik1.txt 50 cvs remove: scheduling plik1.txt for removal cvs remove: use cvs commit to remove this file permanently F:\tmp\test>cvs commit -m "zmiany w wersji biezacej" cvs commit: Examining. 55 cvs commit: Examining subdir Removing plik1.txt; F:\tmp\repos/test/plik1.txt,v <-- plik1.txt new revision: delete; previous revision: done 60 Removing subdir/plik2.txt; F:\tmp\repos/test/subdir/plik2.txt,v <-- plik2.txt new revision: delete; previous revision: done 65 # BADAMY CZY WSZYSTKO ZOSTAŁO COMMITNIĘTE? F:\tmp\test>cvs -n update -d -P cvs update: Updating.? subdir2 70 cvs update: Updating subdir F:\tmp\test>cvs add subdir2 Directory F:\tmp\repos/test/subdir2 added to the repository 75 F:\tmp\test>cvs add subdir2\plik3.txt cvs add: scheduling file subdir2\plik3.txt for addition cvs add: use cvs commit to add this file permanently F:\tmp\test>cvs commit -m "dodano katalog subdir2 w w. head" 80 cvs commit: Examining. cvs commit: Examining subdir cvs commit: Examining subdir2 RCS file: F:\tmp\repos/test/subdir2/plik3.txt,v done 85 Checking in subdir2/plik3.txt; F:\tmp\repos/test/subdir2/plik3.txt,v <-- plik3.txt initial revision: 1.1 done 90 F:\tmp\test>cvs -n update -d -P cvs update: Updating. cvs update: Updating subdir cvs update: Updating subdir2 95 # TERAZ TWORZYMY ODGAŁĘZIENIE OD WERSJI 1 (W REPOZYTORIUM!) F:\tmp\test>cvs rtag -b -r version_1 version_1_branch test cvs rtag: Tagging test cvs rtag: Tagging test/subdir 16

17 100 cvs rtag: Tagging test/subdir2 # BADAMY JAK RÓŻNI SIĘ GAŁĄŹ OD AKTUALNEGO STANU PROJEKTU F:\tmp\test>cvs -n update -r version_1_branch -P -d 105 cvs update: Updating. U plik1.txt cvs update: Updating subdir U subdir/plik2.txt cvs update: Updating subdir2 110 cvs update: subdir2/plik3.txt is no longer in the repository #... I DECYDUJEMY SIĘ PRZEJŚĆ DO GAŁĘZI (BRAK OPCJI -n) F:\tmp\test>cvs update -r version_1_branch -P -d 115 cvs update: Updating. U plik1.txt cvs update: Updating subdir U subdir/plik2.txt cvs update: Updating subdir2 120 cvs update: subdir2/plik3.txt is no longer in the repository F:\tmp\test>dir Volume in drive F is PORTABLE Volume Serial Number is C Directory of F:\tmp\test :16 <DIR> :16 <DIR> :16 <DIR> CVS :02 15 plik1.txt :16 <DIR> subdir 1 File(s) 15 bytes 4 Dir(s) bytes free 135 # TERAZ DODAMY JAKIEŚ NOWE PLIKI/ KATALOGI DO GAŁĘZI F:\tmp\test>echo >nowy-plik.txt "oto nowy plik w galezi!" 140 F:\tmp\test>cvs add nowy-plik.txt cvs add: scheduling file nowy-plik.txt for addition on branch version_1_branch cvs add: use cvs commit to add this file permanently F:\tmp\test>cvs remove -f subdir\plik2.txt 145 cvs remove: scheduling subdir/plik2.txt for removal cvs remove: use cvs commit to remove this file permanently # COMMIT ZMIAN DO GAŁĘZI 150 F:\tmp\test>cvs commit -m "zmiany w galezi" cvs commit: Examining. cvs commit: Examining subdir RCS file: F:\tmp\repos/test/Attic/nowy-plik.txt,v 17

18 done 155 Checking in nowy-plik.txt; F:\tmp\repos/test/Attic/nowy-plik.txt,v <-- nowy-plik.txt new revision: ; previous revision: 1.1 done Removing subdir/plik2.txt; 160 F:\tmp\repos/test/subdir/Attic/plik2.txt,v <-- plik2.txt new revision: delete; previous revision: done F:\tmp\test>dir /B 165 CVS nowy-plik.txt plik1.txt 170 # PO CZYM WRACAMY DO WERSJI GŁÓWNEJ (HEAD). OPCJA -A KASUJE STICKY TAGS F:\tmp\test>cvs update -A -d -P cvs update: Updating. cvs update: nowy-plik.txt is no longer in the repository cvs update: plik1.txt is no longer in the repository 175 cvs update: Updating subdir cvs update: Updating subdir2 U subdir2/plik3.txt # JAK WIDAĆ, JESTEŚMY W WER. GŁÓWNEJ 180 F:\tmp\test>dir /B CVS subdir2 185 # WRÓĆMY WIĘC NA CHWILĘ DO GAŁĘZI... F:\tmp\test>cvs update -r version_1_branch -d -P cvs update: Updating. U nowy-plik.txt 190 U plik1.txt cvs update: Updating subdir cvs update: Updating subdir2 cvs update: subdir2/plik3.txt is no longer in the repository 195 # FAKTYCZNIE, ZNÓW TRAFILIŚMY NA GAŁĄŹ (ALE NIE NA DRZEWO :) F:\tmp\test>dir /B CVS nowy-plik.txt 200 plik1.txt 8 Administracja serwerem CVS W tym rozdziale omówimy pokrótce podstawowe elementy administracji serwerem CVS w systemach Linuxowych. 18

19 Uwaga: autor nie zajmuje się tym zawodowo poniższe uwagi powinny być traktowane jako wskazówki praktyka, a nie gotowe recepty. 8.1 Konfiguracja serwera Najprościej jest zapewne wydać polecenie zainstalowania serwera CVS już na etapie instalacji odpowiedniej dystrybucji Linuxa... jeśli zaś to nie działa, to oto, co trzeba zrobić, by uruchomić CVS pod RedHatem (v. 7.2): 1. Utworzyć konto dla użytkownika cvs. Można też ustawić mu shella na /bin/true w pliku /etc/passwd, by nie było możliwe logowanie się na to konto. 2. Następnie należy zainstalować serwer CVS, np. z rpm-a. 3. Należy utworzyć katalog, gdzie będzie repozytorium, np. /usr/cvsroot, oraz przypisać go do użytkownika cvs (polecenie chown) i nadać prawa do rwx (polecenie chmod). 4. Dodajemy CVS do Xineta. W tym celu w katalogu /etc/xinet.d tworzymy plik cvspserver, zawierający: 1 service cvspserver 2 { 3 socket_type = stream 4 wait = no 5 user = cvs 6 server = /usr/bin/cvs 7 server_args = --allow-root=/usr/cvsroot pserver 8 log_on_success += DURATION USERID 9 log_on_failure += USERID 10 nice = disable = no 12 } Parametr server args należy oczywiście ustawić na odpowiednią ścieżke do repozytorium, którą utworzyliśmy poprzednio. 5. Pozostaje jeszcze wyspecyfikowanie portu, do którego zwiążemy CVS. Robimy to przez dodanie linii do pliku /etc/services (o ile już tam jej nie ma): 1 cvspserver 2401/tcp # CVS client/server operations 6. Restartujemy Xineta za pomocą polecenia: /etc/init.d/xinetd restart. Serwer powinien być dostępny na porcie Teraz należy jeszcze dodać użytkowników, by mogli się oni logować. 19

20 8.2 Dodawanie użytkowników do CVS (pserver) W metodzie pserver, autoryzacja jest dokonywana przez samego CVSa. Jest to bardzo słaba autoryzacja, w której hasło tak naprawdę idzie po sieci w formie odkrytej. By wzmocnić zabezpieczenia można użyć metody ext i połączeń przez SSH, którymi nie będziemy się zajmowali. Aby dodać użytkownika do CVS w metodzie pserver należy: 1. fizycznie przejść do katalogu, gdzie znajduje się repozytorium, do podkatalogu CVSROOT, 2. utworzyć w tym katalogu plik o nazwie passwd, którego właścicielem jest użytkownik cvs. Plik passwd powinien mieć prawa dostępu do odczytu jedynie dla użytkownika cvs, czyli chmod 400 passwd. Plik passwd ma następującą strukturę: login_uzytkownika:haslo_crypted:fizyczny_user Aby więc dodać użytkownika dweiss, który będzie reprezentowany przez użytkownika fizycznego cvs, oraz będzie miał hasło bubu, należy dodać linię: dweiss:pkxyvflxbvqbs:cvs Do konstrukcji hasha hasła można użyć np. takiego skryptu w Perlu: 1 #!/usr/bin/perl 2 3 srand (time()); 4 my $randletter = "(int (rand (26)) + (int (rand (1) +.5) % 2? 65 : 97))"; 5 my $salt = sprintf ("%c%c", eval $randletter, eval $randletter); 6 my $plaintext = shift; 7 my $crypttext = crypt ($plaintext, $salt); 8 9 print "${crypttext}\n"; Użytkownicy z prawem tylko do odczytu Niektórzy użytkownicy mogą mieć jedynie prawo do odczytu (ale nadal wymagać autoryzacji!) poprzez umieszczenie ich w specjalnym pliku o nazwie readers, również znajdującym się w katalogu fizycznym repozytorium (CVSROOT). W ten sposób można np. dodać anonimowy dostęp do repozytorium. 20

21 8.3 Pliki administracyjne CVSROOT Wszystkie inne zmiany w konfiguracji administracyjnej CVS należy wykonywać na kopii lokalnej modułu CVSROOT, która checkoutuje się normalnie, tak jak inne pliki. Aby więc pobrać katalog administracyjny należy się zalogować do CVS (przy pomocy cvs login, z uprzednim podaniem zmiennej środowiskowej CVSROOT), a następnie wykonać polecenie cvs co CVSROOT Dodanie powiadomień owych o commitach Aby dodać owe komunikaty o commitach do repozytorium (bardzo użyteczne dla większych grup programistów), należy wycheckoutować plik administracyjny CVSROOT/loginfo. W tym pliku każda linia to pewne polecenie, które wykona CVS. Przykładowo 4 : projects/mruchive /students/cvs-bin/syncmail2 -u --cvsroot=/students/cvs %{svv} mruchive_commits@yahoogroups.com projects/plugtex /students/cvs-bin/syncmail2 -u --cvsroot=/students/cvs %{svv} PlugTex_commits@yahoogroups.com DEFAULT /students/cvs-bin/syncmail --cvsroot=/students/cvs %{svv} dawid.weiss@cs.put.poznan.pl Tak więc wszystkie commity do modułu projects/mruchive spowodują uruchomienie skryptu syncmail2 z podanymi parametrami. Podobnie dzieje się na modułu projects/plugtex. Wszystkie inne commity będą wysyłane przy pomocy polecenia syncmail (ten sam skrypt, lecz nieco zmodyfikowany). Skryptów przetwarzających commity z CVS jest co najmniej parę. Różnią się one oferowaną funkcjonalnością, oraz formatem e- maila, jaki jest wysyłany do użytkowników. Do najbardziej popularnych należą: syncmail, cvsmailer, CVSMailer.html szczególnie przydatny dla użytkowników CVSNT (wersji Windowsowej serwera CVS) log accum, standardowy skrypt dostarczany chyba z serwerem CVS 8.4 Inne materiały Krótka lista innych materiałów, jakie udało się znaleźć: 4 Wcięte linie powinny być kontynuowane w poprzedniej 21

22 htm, manual dla zaawansowanych. 22