CVS (‘Concurrent Versioning System’) to, jak nazwa wskazuje, system kontroli wersji. Oznacza to mniej wiÄ™cej tyle, że program Å›ledzi zmiany nanoszone na poszczególne pliki (i nadaje każdej zmianie wersjÄ™) przez poszczególnych userów. DziÄ™ki temu Å›wietnie nadaje siÄ™ on do pracy zespoÅ‚owej – np. kilka osób pracuje nad jednym programem i dochodzi do sytuacji że 2 osoby jednoczeÅ›nie pracujÄ… nad jednym plikiem. JeÅ›li obie Å›ciÄ…gnÄ… dany plik powiedzmy przez FTP, poprawiÄ…, a potem jedna po drugiej nagrajÄ… spowrotem na FTP, to zmiany naniesione przez osobÄ™, która przesÅ‚aÅ‚a ten plik wczeÅ›niej zostanÄ… utracone.
CVS jest sprytny. Wie, nad którÄ… wersjÄ… pracuje każdy użytkownik (informacja o tym znajduje siÄ™ w podkatalogu CVS każdego katalogu Å›ciÄ…gniÄ™tego z repozytorium). Np. 2 osoby pobierajÄ… wersjÄ™ 1.4. Najpierw pierwsza osoba wrzuca swoje poprawki, wiÄ™c CVS ‘podbija’ numer wersji do 1.5. Podczas wrzucania poprawek przez drugÄ… osobÄ™, CVS widzi, że poprawiaÅ‚ on wersjÄ™ 1.4, a w repo jest już 1.5, a wiÄ™c sÄ… 2 wyjÅ›cia: albo automatycznie poÅ‚Ä…czy poprawki, albo zgÅ‚osi konflikt – w katalogu zostanie zapisany plik zawierajÄ…cy ‘konfliktowe’ poprawki – wystarczy chwilka aby zobaczyć jaki jest jego format i szybko, rÄ™cznie poÅ‚Ä…czyć
poprawki.
CVS to system, który w swoim katalogu (tzw. repozytorium) trzyma pliki w bardzo specyficznym formacie. Mianowicie zapisany jest podstawowy plik, informacje o zmianach w kolejnych wersjach, tzw. ‘log messages’, czyli komentarze do nanoszonych poprawek i informacje o numerze wersji, ew. ‘branchu’ (o tym dalej), tagach symbolicznych (o tym też dalej). Repozytorium podzielone jest na moduÅ‚y – podkatalogi katalogu głównego repozytorium, z których każdy może być osobnym projektem. Specyficznym moduÅ‚em jest moduÅ‚ CVSROOT, który zawiera pliki konfiguracyjne CVS’u.
Tagi
Tagi sÄ… to znakowe identyfikatory przypisane konkretnym wersjom pliku. Np. plik z wersjÄ… 1.234 może mieć taga stable lub devel lub cokolwiek. Tagi można przesuwać, np. po uznaniu wersji 1.534 za stabilnÄ…, można przesunąć tag stable z wersji 1.234 na 1.534. Tagi mogÄ… siÄ™ powtarzać, czyli tag stable może istnieć dla pliku main.cpp i dla pliku grafika.cpp, przy czym nie musi on dotyczyć tej samej wersji – stabilna może być wersja 1.234 pliku main.cpp i 1.534 pliku grafika.cpp. Jest to Å›wietne rozwiÄ…zanie, ponieważ można jako parametr do checkout’a (co to jest – niżej) użyć opcji -r numer_wersji_lub_tag i pobrać caÅ‚y projekt w wersji stable.
Branche
Istnieje także bardzo specyficzny rodzaj tagu, który nosi nazwÄ™ branchu. Nie bez powodu nazywa siÄ™ on ‘gaÅ‚Ä™ziÄ…’. Załóżmy że jest sobie projekt. Wydana zostaÅ‚a jakaÅ› wersja, po czym uznano, że projekt ma 2 drogi, np. wersja korzystajÄ…ca ze zdalnego serwera i ta pracujÄ…ca lokalnie. Niby to 2 osobne projekty, ale pochodzÄ… ze wspólnego źródÅ‚a i być może w przyszÅ‚oÅ›ci bÄ™dÄ… wymieniane pliki pomiÄ™dzy nimi. Wtedy robi siÄ™ tzw. brancha. Pozwala to na równolegÅ‚e zapisywanie zmian w dwóch lub wiÄ™cej odgaÅ‚Ä™zieniach projektu. Branch jest okreÅ›lany także jako ’sticky tag’, ponieważ jeÅ›li zrobi siÄ™ checkout z parametrem “-r nazwa_branchu”, to ta nazwa jest trzymana przez caÅ‚y czas, jeÅ›li doda siÄ™ plik w tym projekcie, to CVS bÄ™dzie wiedziaÅ‚, że ten plik ma być dodany _tylko_ na tym branchu. JeÅ›li chce siÄ™ zmienić branch, to trzeba skasować starÄ… lokalnÄ… kopiÄ™ i zrobić jeszcze raz checkout. Istnieje też możliwość późniejszego ponownego poÅ‚Ä…czenia branchy. SÅ‚uży do tego parametr “-j nazwa_branchu” dla poleceÅ„ ‘update’ i ‘checkout’. Powoduje on poÅ‚Ä…czenie najnowszej wersji programu (tej bez żadnego brancha) z branchem podanym jako parametr. Można też poÅ‚Ä…czyć 2 podane branche Å‚Ä…czÄ…c parametry -j i -r.
Watch
CVS ma też bardzo ciekawÄ… możliwość blokowania edycji. Oznacza to, że jedna osoba informuje CVS, że ona teraz zajmuje siÄ™ tym plikiem i nanoszenie poprawek przez inne osoby jest zablokowane. Nie napiszÄ™ o tym nic wiÄ™cej bo siÄ™ tym nigdy nie bawiÅ‚em. JeÅ›li kogoÅ› bÄ™dzie to interesować to niech przeczyta część ‘info cvs’ – rozdziaÅ‚ “Multiple developers”.
SÄ… 3 typy korzystania z CVS’u:
- local – bezpoÅ›rednie czytanie z plików repozytorium
- pserver – korzystanie z serwera uruchamianego przez CVS na porcie 2401 (w tym przypadku niezbÄ™dne jest logowanie do serwera CVS)
- ext – korzystanie z serwera zdalnie, ale poprzez zewnÄ™trzny program, taki jak rsh (domyÅ›lnie) lub ssh (program można podać korzystajÄ…c ze zmiennej Å›rodowiskowej CVS_RSH)
Każdy klient usługi CVS do korzystania z plików przechowywanych w
repozytorium musi dostać następujące informacje:
- typ połączenia (local, pserver, ext)
- w przypadku pserver i ext: nazwa serwera, użytkownik i hasło
- katalog z repozytorium
Powyższe dane klienci uniksowi pobierają jako jeden ciąg znaków.
- Dla typu local
- ":local:katalog_z_repozytorium", np. ":local:/home/cvsroot"
- Dla typu ext:
- ":ext:user@komp:katalog_z_repozytorium", np. ":ext:leon@valis.faq.pl:/home/cvsroot"
- Dla typu pserver:
- ":pserver:user@komp:katalog_z_repozytorium", np. ":pserver:leon@valis.faq.pl:/home/cvsroot"
A teraz polecenia. Wszystko robi siÄ™ za pomocÄ… polecenia ‘cvs’,
ale z różnymi parametrami. Po kolei:
- cvs login
- Tego chyba nie trzeba tÅ‚umaczyć. Loguje siÄ™ do CVS’u, jeÅ›li Å‚Ä…czysz siÄ™ z nim zdalnie.
- cvs co nazwa_modułu
- ‘co’ to skrót od ‘checkout’ (można używać obu nazw jako parametr) – wstÄ™pne pobranie danego moduÅ‚u na lokalny komputer. Na takiej kopii siÄ™ pracuje, nanosi poprawki itp. ‘co’ używane jest tylko za pierwszym razem. Później używa siÄ™ ‘up’. Jak już napisaÅ‚em wyżej, można użyć dodatkowy parametr (przed nazwÄ… moduÅ‚u) -r xxx, gdzie xxx może być numerem wersji lub tagiem.
- cvs up [pliki]
- ‘up’ = ‘update’. Uaktualnienie lokalnej kopii i/lub repozytorium. Takie uaktualnienie w obie strony. JeÅ›li na plik jest nowszy na serwerze, to go Å›ciÄ…ga. JeÅ›li nowszy na lokalnym dysku to notuje to przesÅ‚ania przy commit’cie lub informuje o konflikcie. JeÅ›li nie poda siÄ™ pliku/plików, to aktualizuje aktualny katalog z podkatalogami. Tu także można użyć parametru -r takiego jak przy ‘co’.
- cvs commit [pliki]
- Ostateczne potwierdzenie wysÅ‚ania zaktualizowanych/dodanych plików do repozytorium. Przed wysÅ‚aniem CVS poprosi o wpisanie komentarza do poprawek (‘log info’; tylko jeÅ›li nie zostaÅ‚ podany parametr -m “treść log info”).
- cvs add plik/katalog
- Zanotowanie pliku/katalogu do dodania. Ostateczne dodanie nastÄ™puje po wykonaniu commit’a.
- cvs tag nazwa_tagu plik(i)
- Nadanie tagu o podanej nazwie podanym plikom. Tag bÄ™dzie przypisany do wersji aktualnie posiadanej w lokalnej kopii, lub innej jeÅ›li podany bÄ™dzie parametr -r (opis jak wyżej). Można użyć także parametru -F (tag zostanie nie nadany, tylko przesuniÄ™ty) lub -d (usuniÄ™cie zamiast nadania tagu). Parametr “-b nazwa_branchu” robi nowy branch.
- cvs remove plik
- Usuwa katalog z repozytorium. Jeśli nie zostanie podany parametr -f, to przed usunięciem z repo plik musi być usunięty z lokalnej kopii. Jeśli użyje się opcję -f, to cvs zrobi to sam.
Istnieje możliwość zapisania najczęściej używanych opcji na stałe
w pliku ~/.cvsrc . Mój plik wygląda tak:
cvs -z3 update -d -P checkout -P diff -u
Pierwsza linia oznacza, że przesyłane dane będą najpierw kompresowane gzipem na poziomie 3. Druga oznacza, że budowana będzie struktura katalogów i usuwane puste katalogi przy update. Trzecia, że usuwane będą puste katalogi przy checkout. Czwarta określa format pokazywania diffów
Tagi:
Zostaw komentarz