CVS

Motywacja

Nie wyobrażam sobie tworzenia oprogramowania bez wykorzystania systemu zarządzania wersjami. Musi istnieć jedno repozytorium, w którym znajduje się pełny kod źródłowy tworzonych systemów. Musi być możliwe dokładne odtworzenie kodu, z którego zbudowano dystrybucję aktualnie działającą u klientów (nawet gdy klientów jest kilku i każdy używa trochę innej wersji). Musi być dostępna historia zmian - zarówno w formie opisów podawanych przez wprowadzających modyfikacje, jak bezpośredniego porównania poszczególnych plików. Często pojawia się konieczność wprowadzania "na boku" poprawek w starszej wersji programu czy biblioteki - akurat w chwili, gdy właśnie jesteśmy w środku głębokich przeróbek. Potrzeby takie są wyraźne nawet w projektach robionych przez jedną osobę przez jeden-dwa miesiące. Gdy pracuje kilku czy kilkunastoosobowy zespół (już nie mówiąc o większych) a projekt trwa wiele miesięcy, brak zarządzania wersjami daje praktyczną pewność ogromnych problemów.

Rynek narzędzi do zarządzania wersjami (czy też zarządzania konfiguracją - co oprócz zarządzania wersjami obejmuje procedury budowy kodu, rejestracji błędów, powiadamiania o zmianach itp) jest bardzo bogaty. Są to jednak w większości przypadków bądź produkty dosyć prymitywne (RCS, SCCS, SourceSafe, PVCS), bądź drogie (Perforce, StarTeam, Razor) albo bardzo drogie (ClearCase, Continouous). W polskiej praktyce wydanie nawet kilku tysięcy dolarów (by już nie wspominać o kilkudziesięciu) na tego typu narzędzia nie jest rzeczą łatwą. Ale istnieje produkt, który nie kosztuje nic a zapewnia całkiem zaawansowane możliwości - CVS.

Zalety CVS

Oczywiście trzeba wspomnieć o darmowości - aczkolwiek muszę podkreślić, że nawet gdyby PVCS czy SourceSafe byłyby dostępne za darmo, używałbym CVS. Poniżej staram się wymienić kilka istotnych zalet CVS - przy czym jest to lista subiektywna, wynikająca z moich potrzeb i nie pretendująca do kompletności.

CVS działa w sieci

Jedno repozytorium CVS może obsługiwać całą sieć klientów, pobierających z niego odpowiednie moduły i zatwierdzających zmiany. Każdy może pracować na swoim ulubionym PC czy stacji roboczej a poprawki lądują w wspólnym repozytorium.

Co tu się zresztą rozwodzić - właśnie z CVS korzysta mnóstwo projektów OpenSource, gdzie z jednego repozytorium korzystają nieraz setki programistów rozproszonych po całym świecie.

CVS działa na wszystkim

CVS działa na bardzo szerokim zestawie platform sprzętowych i systemowych. W mojej obecnej firmie repozytorium CVS (Linux) obsługuje klientów korzystających z systemów Windows, OpenVMS, DigitalUnix oraz Linux. Niesłychanie użyteczne, gdy próbujemy pisać przenośne oprogramowanie.

Można używać wielu kopii roboczych

Bez żadnych problemów, jeden programista może używać równocześnie kilka niezależnych kopii roboczych (czy to na różnych platformach, czy nawet na jednej - gdy w jednym miejscu prowadzi się prace nad najnowszą wersją, w drugim robi eksperymenty a w trzecim usuwa błąd w wersji sprzed miesiąca działąjącej aktualnie u klienta).

Nie trzeba być stale podłączonym

CVS działa bez stałego podłączenia do repozytorium (wymagane jest ono jedynie w trakcie aktualizowania kopii roboczej i zatwierdzania zmian). Nie ma żadnych problemów z wzięciem kopii na laptopa czy dyskietkę, pracą w domu czy u klienta i późniejszym wprowadzeniem zmian do repozytorium.

Dodanie lub skasowanie pliku jest wersjonowane

Dodanie nowego pliku lub skasowanie już nieużywanego jest normalną zmianą podlegającą wersjonowaniu.

Repozytorium ma strukturę

Repozytorium ma normalną drzewiastą strukturę - odzwierciedlaną w kopii roboczej jako drzewo katalogów. Pozwala to na zarówno sensowną organizację kodu, jak pobieranie wyłącznie części plików - tych związanych z aktualnym projektem. Nie pisałbym o tej cesze jako zalecie (wydaje się oczywista) ale używałem kiedyś CMS...

Repozytorium trudno uszkodzić a łatwo reorganizować

Repozytorium CVS to po prostu zbiór, rozłożonych w odpowiednich katalogach, archiwów RCS-owych (jeden plik RCSowy na jeden wersjowany plik źródłowy). Jeśli któryś z tych plików ulegnie uszkodzeniu, wszystkie pozostałe nadal pozostają w pełni dostępne (porównajcie to z opowieściami o uszkodzeniach baz SourceSafe...). Jeśli chcemy podzielić repozytorium na dwa, zmienić jego strukturę albo przenieść całość lub część na inną maszynę, wystarczy odpowiednio skopiować pliki. Przy okazji: wyjątkowo łatwa jest migracja między CVS i RCS - to tylko kopiowanie plików xxxx.yyy,v

CVS nie wymaga blokowania plików

Ta cecha często początkowo budzi pewne kontrowersje - ale na dłuższą metę jest bardzo wygodna. Pracując z CVS programista nie blokuje plików (acz istnieje taka możliwość i np. przy edycji dokumentów warto z niej korzystać). Każdy wprowadza zmiany gdzie i jak chce (nigdy więcej poszukiwania "Krzysia" który nie wiadomo po co nałożył blokadę na pliku który koniecznie musi zmienić "Grześ"). Chwila prawdy następuje w chwili wprowadzania zmian do repozytorium - jeśli plik od momentu ostatniego pobrania został zmodyfikowany przez kogoś innego, CVS uniemożliwia zatwierdzenie zmian - wymagając w zamian aktualizacji. Jeśli zmiany dotyczyły różnych miejsc pliku, ładnie łączy je sam, jeśli tych samych, generuje raport rozbieżności i wymaga od programisty ich rozwikłania. Po usunięciu konfliktów można poprawki zatwierdzić.

W mojej opinii mechanizm ten - dla plików tekstowych, np. kodu źródłowego - działa bardzo ładnie a algorytm łączenia zmian jest całkiem sensowny. Sytuacje w których jedna osoba poprawiała funkcję A a druga dodała nową funkcję B są obsługiwane całkowicie bezboleśnie.

To po prostu stabilnie działa

Przez kilka lat używania CVS nie miałem nigdy żadnych tajemniczych problemów. Jest to zresztą chyba najlepiej wytestowane (bo najliczniej i najdłużej używane) narzędzie do zarządzania wersjami.

CVS obrasta w narzędzia uzupełniające

Intensywne używanie CVS w wielu projektach OpenSource owocuje pojawianiem się wielu - także OpenSource - narzędzi wspomagających. Niektóre z nich omawiam w dalszej części tego artykułu.

Wady i braki CVS - oraz sposób ich kompensowania

CVS posiada kilka istotnych ograniczeń. Poniżej wspominam o nich, zarazem dając pewne sugestie jak można je kompensować. Znów: lista ta nie jest kompletna, dotyczy kwestii które dla mnie były w ten czy inny sposób dotkliwe.

CVS nie jest systemem zarządzania konfiguracją

CVS jest dobrym systemem zarządzania wersjami ale ... tylko tym i niczym więcej. Nie obsługuje rejestracji błędów i wiązania ich z poprawkami. Nie implementuje procedur kompilacji i tworzenia dystrybucji. Nie daje możliwości określania stanu poszczególnych modułów (czyli przydzielania etykietek typu w trakcie tworzenia, alfa - faza wstępnych testów, beta - faza finalnych testów, gotowe do dystrybucji). Nie definiuje i nie wymusza żadnego standardowego procesu rozwijania kodu.

Jeśli nie stać nas na pełne narzędzia zarządzania konfiguracją (typowe ceny grubo ponad 1000$ od stanowiska), musimy z tym żyć i po prostu:

• zdefiniować obowiązujące w firmie/projekcie procedury (od "co wolno commitować", przez "jak tagować istotne wersje" i "jak przeprowadzać kompilacje testowe a jak budowę dystrybucji" po "jak utrzymywać listę błędów i wspominać o ich usuwaniu w komentarzach o zmianach");
• przygotować standardowe procedury kompilacji, reguły tworzenia plików Makefile itp;
• używać CVS w powiązaniu z innymi narzędziami (choćby gnumake, bugzilla, grupy dyskusyjne a niekiedy proste aplikacje rozwijane samodzielnie, przykłady mam zamiar tu w przyszłości zaprezentować).

Zresztą, z jakiegokolwiek narzędzia byśmy korzystali, sensowne procedury musimy ustalić. Dobre narzędzia komercyjne mogą nam istotnie bardziej niż CVS pomóc w wymuszaniu ich przestrzegania.

CVS nie obsługuje atomowego zatwierdzania zmian

Choć jednym poleceniem cvs commit możemy zatwierdzić poprawki w wielu plikach, CVS wewnętrznie implementuje to po prostu jako kolejne zatwierdzanie poprawke w wszystkich tych plikach. Wiąże się to z dwoma problemami:

• w razie jakichś problemów (np. zerwanie połączenia sieciowego z serwerem) część naszych zmian może zostać zatwierdzona a część nie - problem jest o tyle niezbyt istotny, że raczej to zauważymy, a zwykłe ponowienie tego samego polecenia "dokończy dzieła";
• tracimy informację o powiązaniu zmian - analizując historię zmian nie widzimy bezpośrednio, że czyjaś poprawka obejmowała zmiany w plikach A, B i C (mamy jedynie, w ramach historii plików A, B i C zmiany dokonane w tym samym czasie i z tym samym komentarzem).

W obejściu drugiego problemu znacznie pomaga skrypt cvs2cl.pl Kena Fogela - który integruje historię zmian w drzewie katalogów (lub dowolnym zbiorze plików), prezentując ją jako jeden spójny ChangeLog, w którym tego typu zmiany są zagregowane.

CVS nie wersjonuje dodawania i usuwania katalogów

CVS niestety nie umożliwia kontroli wersji obejmującej dodawanie i kasowanie katalogów. Raz dodany nowy katalog wygląda jak gdyby istniał od zawsze, usunąc go praktycznie nie sposób (oczywiście można skasować katalog z repozytorium ale tracimy wtedy historię dla wszystkich plików które się w nim znajdowały a możemy też sprawić pewne problemy klientom). Równie kłopotliwe jest zmienianie nazwy katalogu (możemy zmienić nazwę katalogu w repozytorium ale tracimy na zawsze informację o jego wcześniejszej nazwie czyli np. możliwość dokładnego odtworzenia stanu źródeł z przeszłości).

Problem nie ma dobrego obejścia. Korzystając na poważnie z CVS trzeba dobrze zaplanować zasady budowy hierarchii katalogów i dobrze się zastanowić nad właściwą nazwą nowego katalogu przed jego dodaniem.

CVS nie pozwala na aliasowanie plików

CVS dostarcza przyjemnego mechanizmu aliasowania modułów (dzięki któremu ten sam katalog może być widoczny w dwóch różnych miejscach, na przykład naraz jako projektX/src/sql i bazyDanych/projektX/), niestety nie ma analogicznego mechanizmu dla pojedynczych plików. Trzeba to kompensować tworząc sztuczne katalogi bądź np. reguły kompilacji obejmujące kopiowanie lub używanie pliku z innego katalogu.

Dystrybucja, dokumentacja

CVS jest dostępny - tak w formie źródeł, jak binariów na różne platformy - w ramach większości archiwów FTP udostępniających oprogramowanie GNU (CVS należy też do wszystkich znanych mi dystrybucji Linuksa, jest też często dodawany do dystrybucji komercyjnych Uniksów). Główną stroną WWW jest cvshome.org.

Dostępnych jest kilka list mailowych na temat CVS (z info-cvs na czele), dyskusje na temat CVS często pojawiają się też na grupie dyskusyjnej comp.software.config-mgmt.

Istnieje wiele graficznych interfejsów ułatwiających pracę z CVS. Dla platformy Windows można polecić WinCVS, na Unixach istnieje kilka produktów (tkCVS, gCVS, ...) - których nie omawiam szerzej, bo sam używam głównie PCL-CVS (interfejsu do CVS wbudowanego w edytor XEmacs). Istnieje nawet przenośny na różne platformy interfejs do CVS zaimplementowany w języku Java - jCVS.

Od wielu lat podstawową dokumentacją CVS jest podręcznik autorstwa Pera Cederqvista - dołączany w różnych formatach (źródła w texinfo, pliki info, pliki postscriptowe do wydruku) do dystrybucji CVS. Niedawno pojawiła się bardziej rozbudowana i dokładniejsza książka Kena Fogela - dostępna za darmo pod adresem cvsbook.red-bean.com

Wartościowe narzędzia uzupełniające

O graficznych interfejsach użytkownika wspomniałem już w poprzednim punkcie. Kolejnym bardzo przydatnym uzupełnieniem jest skrypt cvs2cl.pl generujący zagregowane historie zmian (pliki ChangeLog) - dostępny pod adresem http://www.red-bean.com/~kfogel/cvs2cl.shtml.

Istnieje też kilka przeglądarkowych interejsów do CVS (przez przeglądarkę WWW można oglądać historię zmian, porównywać wersje plików itp) - nie będę ich szerzej omawiał bo jak dotąd żadnego z nich nie używałem (natomiast uznaliśmy za użyteczne utrzymywanie aktualnej kopii roboczej w ramach firmowego serwera WWW - dzięki temu każdy może zerknąć do źródeł czy dokumentacji modułu, nawet jeśli aktualnie go nie używa).

Zamiast podsumowania

CVS nie jest "aplikacją marzeń". Realizuje jednak swoje funkcje i - po podparciu pewnymi narzędziami pomocniczymi - wystarcza przynajmniej w projektach realizowanych przez zespoły od kilku do kilkunastu osób o zakresie czasowym rzędu roku (w takich miałem okazję brać udział). Jeśli firma korzysta z wybranego jednego narzędzia do zarządzania wersjami i jest z niego zadowolona, prawdopodobnie przy nim zostanie. Jeśli jednak - co się często zdarza - wykorzystywane są liczne, porozrzucane archiwa (typu kilka baz SourceSafe na Windows, jakieś pliki RCS czy SCCS na Unixie, CMS na VMSie) albo wręcz nie ma jednolitej polityki zarządzania wersjami a ewentualne korzystanie z takiego narzędzia zależy od dobrej woli programisty - warto rozważyć przejście na CVS. Nawet jeśli ostatecznie uznamy, że "potrzebujemy czegoś więcej", pół roku do roku używania CVS pozwala zazwyczaj dobrze zrozumieć, czego można oczekiwać od takiego narzędzia - i świadomie wybrać ewentualnego komercyjnego następcę.