Úplná lokální kopie repozitáře je funkce pro offline práci, ne zákon verzování
Git dává každému klientovi celou historii. To je skvělé, když pracuješ v letadle nebo když neexistuje centrální server. Anthropic ale narazil na opačnou situaci. Skoro všichni klienti jeho monorepa jsou agenti a CI joby, které jsou trvale online. Pro ně je úplná kopie čistá zátěž. Autoři to shrnují tak, že vlastnosti, díky kterým je git skvělý pro distribuovanou offline práci, začaly škálování přímo podkopávat.
Čísla, při kterých se ten předpoklad láme
Mezi květnem a zářím 2026 vzrostl počet mergů z přibližně 2 500 na více než 30 000 denně. Historie hlavní větve má skoro 100 GB, komprimovaná pracovní kopie přes 25 GB. CI dělá zhruba 25 milionů checkoutů denně. Kdyby každý fetchoval naivně, šlo by o víc než 600 PB přenosu za den.
Několik stovek interních git mirrorů to dlouho drželo, ale s každým dalším nárůstem bylo těžší je provozovat. Podstatné je, že žádný z těch problémů nebyl chybou v kódu gitu. Git dělal přesně to, k čemu byl navržen: replikoval všechno ke všem.
Server drží historii, klient jen cache
Scion obrací rozdělení práce. Server počítá historii, blame, commity, merge i rebase. Klient má omezenou cache a spravuje pracovní kopii, a ta je navíc volitelná. Spousta CI jobů nepotřebuje checkout vůbec, protože bisect nebo revert zavolá jako API.
Základní jednotkou je changeset v write-ahead logu. Na rozdíl od git commitu neukazuje na celý strom. Vyjmenuje jen soubory změněné vůči prvnímu rodiči, s content-addressed odkazy na bloby. Commit tak stojí úměrně velikosti změny, ne velikosti repozitáře. Neexistují packfily ani zámky napříč servery a posun refu je compare-and-swap nad jedním řádkem ve Spanneru.
Fetch se vyjednává podle toho, co klient chce, ne podle toho, co už má. Klient jde od kořenového stromu a dotahuje chybějící objekty. Každý požadavek míří na neměnný objekt, takže odpovědět může libovolná vrstva cache a přerušený přenos se dá navázat. Sparse checkout nepotřebuje žádnou speciální podporu: nechtěné stromy se prostě nevyžádají. Každá vrstva cache drží hit rate přes 99 %, infrastruktura spotřebuje zhruba 200× méně CPU a paměti než původní mirrory a checkout trvá sekundy místo minut.
Changeset je pravda, všechno ostatní je odvozené
Changeset, který zná jen rozdíl, neumí levně odpovědět na otázku „kdo naposledy změnil tenhle řádek“. Scion proto staví odvozená data: blame, historii cesty a skip listy nad grafem commitů. Každý typ je definovaný rekurzivně z rodičů, dá se spočítat hned i líně a klient jeho vnitřní tvar nevidí.
Rain z blogu sunshowers upozorňuje, že stejný návrh měl už Mononoke, serverová část Sapling v Metě: bonsai changesety jako primární záznam a k nim asynchronně počítané indexy. Spor o atribuci stranou, ta shoda je poučná. Když se dva týmy nezávisle dostanou ke stejnému tvaru, nejspíš ho diktuje problém. Formát dobrý pro zápis a přenos bývá špatný pro dotazy, takže dotazové struktury se oddělí a odvozují.
Co si z toho odnést
Až budeš navrhovat úložiště pro systém, kde dominují agenti a joby, ověř si nejdřív, jestli jsou klienti opravdu offline. Pokud ne, replikace všeho ke všem je drahý pozůstatek a výpočty patří na server.
Odděl záznam změn od indexů pro dotazy. Záznam drž malý a neměnný, indexy odvozuj a měň, kdy potřebuješ. Neměnné adresovatelné objekty jsou přitom to, co dělá cache triviální.
Scion sám přenosný není, protože s ním padá i code review, search a CI. Přenosná je otázka, kterou si autoři položili: který předpoklad nástroje přestal platit pro lidi, kteří ho dnes používají.