W mgnieniu oka

Witaj na prywatnej stronie blinkkina. Zapoznaj się z informacjami na temat bloga i autora. Subskrybuj witrynę przez kanał atom lub zobacz ostatnie komentarze. W wolnej chwili odwiedź mojego mikrobloga na identi.ca.


Fossil SCM

UWAGA! Jest to tylko szkic planowanej publikacji, której tematem jest Fossil SCM.

1. Czym jest Fossil?

Fossil to rozproszony system kontroli wersji, który jest wydajny i niezawodny. Nie jest to nic niezwykłego patrząc na gita czy Mercuriala. W porównaniu z tym systemami Fossil wyróżnia się użytym protokołem – cały ruch odbywa się po HTTP. Dodatkowo jest on przystosowany do działania w trybie CGI.

Jednak co innego jest unikatowe w przypadku Fossila. Jest to zintegrowane rozwiązanie na dostarczenie wiki, systemu śledzenia błędów i dokumentacji. Dodatkowo cały program ogranicza się do jednego pliku, który nie ma zależności. Stabdardowo dostępny jest także interfejs w postaci strony internetowej.

Interesujący jest także tryb “autosync”, który automatycznie sprawdza połączenie. Zależnie od tego praca na repozytorium odbywa się w trybie off-line lub on-line.

2. Artefakty

Fossil SCM - artefakty Repozytorium to worek artefaktów, które są identyfikowane za pomocą sum SHA1. Artefakty są nieposortowane.

Synchronizacja następuje poprzez wymianę artefaktów. Mechanizmy synchronizacji nie mają pojęcia o wersjach, wiki czy biletach błędów. HTTP jest używane do transortu artefakatów podczas synchronizacji.

Fossil SCM - synchronizacja

Po synchronizacji, repozytoria posiadają te same zestawy artefaktów. Kompresja zlib i użycie Delt znacząco zmiejsza użycie łącza. Prywatne i ominięte pliki są wykluczone z procesu synchronizacji.

Fossil SCM - komendy

Zagadnienia, które mogą przydać się podczas rozbudowy publikacji:

  • Repozytorium to jeden plik bazy SQLite z nieuporządkowanymi artefaktami, które są binarnymi BLOBami
  • Foldery nie są “obywatelami pierwszej kategorii”, w porównaniu z Monotone i Darcs
  • Wersje, zmiany tzw. “check-ins” są indentyfikowane za pomocą sum SHA1, które są generowane na podsawie zawarości plików
  • Standardowy tryb pracy bardziej przypomina CVS lub SVN niż systemy rozproszonej kontrolii wersji (tryb “auto-sync”)
  • Wbudowany interfejs strony internetowej czyni Fossila bardzo przystępnym – łatwy dostęp do numeru wersji (check-in) etc
  • W przeciągu istnienia Fossila, ani razu nie zgłoszono problemu ze znikającymi plikami
  • Oficjalna strona Fossila jest self-hosted od dawna – co stanowi atut w przypadku małych projektów
  • Serwer Fossila działa w trybie CGI, co jest dosyć tanie i łatwe w porównaniu z innymi projektami
  • SQLite jest tylko cachem dla binarnych BLOBów (artefaktów) – całe repozytorium może zostać odtworzone przy użyciu artefaktów (opcja rebuild). Indeksowanie manifestów etc zmianiało się kilkukrotnie, artefakty nie.
  • Językiem wysokiego poziomu jest SQL, który został sklejony za pomocą czystego C. Pierwsze wersje były napisane w TCL – z tego pomysłu zrezygnowano, bo kod był nadmiernie rozdmuchany.
  • Branche i tagi są mocno rozbudowane. Tagi mogą być stałe, jednorazowe i wykluczające się (przydatne przy merge)
  • Branche są łatwo rozpoznawalne – wyróżnienie za pomocą kolorów w interfejsie strony internetowej
  • Brak “cherry picking”?
  • Praca offline na wiki i bugtrackerze to unikatowe rozwiązanie
  • Ogromna przenośność – działanie na Windowsie nie odbiega od systemów Unikso-podobnych w porównaniu np. z git