Na GitHubu najdete repozitář sqlite/sqlite, takže neobvyklou volbu vývojářů můžete snadno přehlédnout. Je to však jednosměrné zrcadlo: změny přebírá z Fossilu a projekt přes něj nepřijímá pull requesty. Hlavní vývoj probíhá jinde a Hipp sám vysvětluje, proč Git nepoužívá. Od verzovacího systému očekává především přehled o celém projektu a co nejméně starostí s jeho správou. Na těchto požadavcích Fossil vyrostl.

Nejdřív přestaly stačit smajlíky

SQLite původně používalo CVS. Kód se verzoval, jenže v historii se špatně orientovalo a chyběla integrovaná evidence chyb. Hipp proto v roce 2002 začal psát nadstavbu CVSTrac, která zpřístupnila historii přes web. Zlepšily se tím i komentáře ke commitům: v nejstarších záznamech SQLite býval popisem změny i pouhý smajlík, ale jakmile byly komentáře lépe vidět, začalo mít větší smysl něco do nich napsat.

Kolem roku 2005 už Hipp hledal náhradu samotného CVS. Zvažoval Monotone, Git i Mercurial, ale v tehdejší nabídce nenašel požadovanou kombinaci distribuovaného verzování, synchronizace přes běžné HTTP, levného hostování a wiki s evidencí úkolů. V roce 2007 tak začal vznikat Fossil. Nejprve spravoval vlastní vývoj, potom dokumentaci SQLite a v srpnu 2009 do něj přešel i zdrojový kód databáze. Přehled o celém projektu tedy patřil k původnímu zadání, ne k funkcím přidaným později.

Projektový web cestuje s repozitářem

Fossil spojuje verzování kódu s wiki, evidencí chyb a fórem. Součástí stejného programu je i webový server a prohlížeč historie. Repozitář projektu ukládá do jediného databázového souboru SQLite. Jeho prostřednictvím tak SQLite uchovává i vlastní vývojovou historii.

Při klonování repozitáře Fossilu se do počítače stáhne kód, wiki i záznamy o hlášených chybách, a to včetně historie změn. Běžný git clone naproti tomu nestáhne diskuse a issues z GitHubu: ty si ukládá hostingová služba odděleně.

V otevřeném pracovním adresáři Fossilu stačí spustit fossil ui. Program otevře v prohlížeči místní webové rozhraní, v němž můžete procházet staženou historii i bez připojení. Není třeba zvlášť zprovozňovat webovou aplikaci nad repozitářem. Také Git lze provozovat na vlastním serveru v hotovém prostředí s wiki a evidencí úkolů, například ve Forgejo. Tato agenda ale zůstává mimo klon hlavního repozitáře s kódem.

Co se s opravou stalo dál

Webové rozhraní Fossilu staví do popředí časovou osu, která v jednom pohledu ukazuje změny napříč větvemi. Z detailu commitu se dá pokračovat k jeho předchůdcům i následníkům. Při pátrání po chybě se totiž hodí obojí: zjistit, odkud problém přišel, a potom sledovat, kam se dostala jeho oprava.

V historii SQLite si lze otevřít konkrétní cestu k vydání. Začíná opravou sestavení na Windows z 3. února 2025 ve větvi windows-build-issue, pokračuje přes sloučení do hlavní větve trunk a končí verzí 3.49.0 ze 6. února. Vidíte opravu v souvislosti s dalšími změnami a odkaz na tento výřez historie můžete poslat kolegovi.

Git podobné pátrání zvládá také. Pro přehled větví nabízí například git log --graph --all --oneline; průchod mezi dvěma commity lze omezit pomocí --ancestry-path. Fossil takové pohledy nabízí přímo ve svém webovém rozhraní, takže člověk nemusí nejprve sestavovat vhodný příkaz ani hledat další prohlížeč historie. Právě tento průběžný přehled Hipp na svém nástroji oceňuje.

Rozdíl sahá i k názvům větví. Větev v Gitu je pohyblivý ukazatel na commit. Když po sloučení smažete větev oprava-parseru, sloučené commity zůstanou, ale jejich původní příslušnost k takto pojmenované větvi není trvalou součástí commitů. Název může přežít třeba ve zprávě o sloučení nebo v pull requestu. Fossil uchovává pojmenování větví jako součást synchronizované historie, takže i uzavřenou větev lze dál rozpoznat. Při návratu k dávnému experimentu je to užitečnější než samotný graf bez názvů.

Sdílet práci a uchovat její historii

Fossil usnadňuje sdílení práce i při samotném ukládání změn. Ve výchozím nastavení má zapnutý autosync: při commitu komunikuje se vzdáleným repozitářem a po uložení odešle změny, takže odpadá samostatný push, na který lze zapomenout. Synchronizace navíc běžně zahrnuje všechny sdílené větve, ne pouze jednu vybranou.

Pro malý, úzce spolupracující tým SQLite je to přirozený režim, protože si vývojáři důvěřují a chtějí průběžně vidět práci ostatních. Fossil přitom zůstává distribuovaným systémem stejně jako Git: umožňuje lokální commity bez sítě a pozdější synchronizaci, autosync lze vypnout. Rozdíl je v tom, jaký způsob spolupráce nabízí rovnou po instalaci.

Ve Fossilu záměrně chybí i příkaz rebase, protože přednost má záznam toho, jak vývoj skutečně probíhal, včetně odboček a následných oprav. Když něco pokazíte, můžete přidat opravný commit nebo změnu vrátit dalším commitem; běžný postup nespočívá v nahrazení staré série novou, uhlazenější historií.

V Gitu má takový úklid své dobré důvody. Před odesláním vlastní dosud nesdílené práce můžete interaktivním rebasem sloučit několik pokusů do jednoho smysluplného commitu, takže kolega při revizi řeší výslednou změnu místo sledu mezikroků. Git umožňuje historii připravit pro čtenáře, Fossil dává přednost zachování původních záznamů. Kdo pravidelně používá rebase a squash, narazí při přechodu na Fossil na podstatnou změnu návyků.

Kde má Git navrch

V jednom souboru může být hotová oprava chyby a vedle ní rozpracovaný refaktoring. V Gitu lze pomocí git add -p připravit commit jen s opravou a refaktoring zatím nechat stranou. Umožňuje to index neboli staging area, kde se obsah příštího commitu sestavuje odděleně od rozpracovaných souborů. Fossil samostatný index nemá, což ukládání změn zjednodušuje, ale nad obsahem commitu neposkytuje tak jemnou kontrolu.

Ke Gitu se navíc přidává prostředí, ve kterém tým spolupracuje. Na GitHubu se kolem pull requestu soustředí diskuse nad kódem i automatické kontroly. GitHub Actions podle událostí v repozitáři spouštějí sestavení a testy, jejichž výsledky se zobrazují přímo u návrhu změny.

Fossil umí přes hooky spouštět automatizaci a připojit CI, ale samotným přenesením commitů by přechod z GitHubu neskončil. Tým by musel upravit i způsob, jak přijímá příspěvky a kontroluje kód. Fossil nabízí společný přenos kódu, wiki a hlášení chyb a průběžné sdílení bez přepisování commitů, což může malému stálému týmu dobře vyhovovat. Tam, kde se spolupráce opírá o GitHub, ovšem mohou mít větší váhu už zavedené postupy a nástroje.

Pro uživatele SQLite navíc volba Fossilu neznamená nutnost opustit Git. Kdo potřebuje zdrojové kódy v Gitu, má k dispozici zrcadlo na GitHubu; vývojáři databáze se kvůli tomu nemusí vzdát prostředí, které si přizpůsobili vlastní práci.