Fossil SCM to system kontroli wersji, wiki i bugtracker – wszystko to w rozproszonym stylu. Jest to prawdopodobnie jeden z najbardziej innowacyjnych projektów zarządzania oprogramowaniem od czasu powstania Darcs i Trac.

Obecny trend w świecie otwartych źródeł to przejście z centralnie zarządzanych systemów kontroli wersji na rozproszone odpowiedniki. Liczne projekty już teraz korzystają z Gita czy Mercuriala. W przypadku NetBSD też się nad tym zastanawiano, ale natrafiono na wiele problemów.

Większość takich systemów ma spore zależności. W przypadku Darcs jest to środowisko GHC (Haskell), Monotone wymaga ogromnej biblioteki Boost, Bazaar i Mercurial potrzebują Pytona, natomiast SVK i Git są zależne od Perla.

W przypadku NetBSD jest to szczególnie problematyczne, ponieważ słowo przenośny oznacza bardzo dużo. Powyżej wymienione zależności, nękają ogromne problemy z kompilacja krzyżową (cross compiling). Z tego powodu raczej nie znajdą się one w bazowej dystrybucji NetBSD.

Gita można zbudować co prawda bez udziału Perla, jednak pojawia się kolejna przeszkoda. Skalowalność systemów kontroli wersji można ocenić pod względem trzech parametrów – ilości zmian, wielkości poprawek i objętości repozytorium. Git skaluje się świetnie w dwóch ostatnich przypadkach na tle innych rozwiązań.

Należy pamiętać, że NetBSD posiada jedno z najstarszych i największych repozytorii. 17 lat historii i ponad 300 tysięcy poprawek robi wrażenie. Świetnie obrazuje to wizualizacja wykonana za pomocą Gource. Mimo niskiej jakości nagrania, nadal robi wrażenie:

NetBSD gource visualization [LQ sample] - Vimeo.

Jak ten problem rozwiązały inne projekty? W przypadku jądra Linuksa, repozytorium podzielono na dwie części. Historyczne jest używane do przeglądania starych zmian, natomiast obecne prace są prowadzone na „wyczyszczonej” wersji. Społeczność NetBSD dosyć jednomyślnie oceniła to rozwiązanie i to w negatywny sposób. Niektórzy optowali nawet za wciągnięciem historii CSRG do repozytorium, mimo potencjalnych przeszkód prawnych.

Inna kwestia to przepływ pracy, która wygląda trochę inaczej w środowisku BSD. Zmiany są dodawane często i gęsto w postaci małych poprawek. Większość systemów DVC natomiast skupia się na branchowaniu i forkowaniu, co w rezultacie daje duże poprawki, dodawane znacznie rzadziej.

Jakie są więc alternatywy? Jedną jest przejście na SVN, ale prawdopodobnie plusy takiego rozwiązania są mniejsze niż pochłonięty wysiłek. Drugim być może jest Fossil SCM, o których wspomniałem we wstępie.

Za tym młodym projektem stoi twórca SQLite i CVSTrac – Richard D. Hipp. Zależności Fossila są niewielkie i wszystkie wymagane biblioteki znajdują w bazowej dystrybucji NetBSD, co można sprawdzić instalując go za pomocą pkgsrc. Standardowy tryb pracy to automatyczna synchronizacja z głównym repozytorium, co przypomina pracę z CVS.

Problem z zależnościami i ze specyficznym przepływem pracy wydaje się rozwiązany, co jednak ze skalowalnością? Na to pytanie ciężko odpowiedzieć, ponieważ Fossil nie został sprawdzony jeszcze w odniesieniu do tak dużego repozytorium, jakie posiada NetBSD. Jednak z każda kolejną wersją szybkość działania wzrasta. Oczekiwany jest spory przyrost wydajności po dodaniu obsługi WAL oferowanej przez SQLite – bazy danych, z której korzysta Fossil.

Celowo pominąłem sprawę licencjonowania, ponieważ większość istniejących rozwiązań jest dostępnych na GPLu. Co ciekawe Richard D. Hipp zapowiedział, że przyszłe wersje Fossila będą dostępne na licencji Apache, BSD lub innym liberalnym rozwiązaniu (SQLite jest rozpowszechniany jako Domena Publiczna, co sporo wyjaśnia). Nie muszę chyba mówić, że jest to mocna karta przetargowa.

Jednak Fossil jest projektem zbyt młodym, żeby spełnić wszystkie wymagane warunki. Nie wszystkie funkcje są dopracowane – w tyle pozostaje m.in. wiki ze względu na brak użycia standardowego języka znaczników czy bugtracker, który oferuje dosyć małe możliwości. Ze względu na dynamiczny rozwój brakuje nawet numeracji wydań Fossila.

Dlatego ciężko ocenić stabilność działania programu Richarda, a jest to chyba podstawowy wymóg, jaki stawia społeczność NetBSD. Potencjał jest jednak spory, ze względu na unikalne cechy Fossila, które z czasem zapewne zostaną udoskonalone. Warto też zapoznać się z dyskusją jaka miała miejsce na kanale IRC.