Docelowi odbiorcy: deweloperzy system贸w kontroli 藕r贸d艂a, tak jak Git i Mercurial.

Ostatnio by艂 przeciek koda z Yandex. Ja nie spradza艂em plik贸w, ale temat w艂a艣nie przypomina nam, 偶e Yandex utrzymuje swoje du偶e monorepo, a nawet zbudowa艂 w艂asny system kontroli 藕r贸d艂a [ang. 鈥渟ource control system鈥漖, 偶eby sobie z tym radzi膰, o nazwie 鈥淎rc鈥.

Oryginalny artyku艂 z Yandex (2020): https://habr.com/ru/company/yandex/blog/482926/

Kr贸tkie notatki (pierwotnie opublikowane na Discordzie):

  • Wydaje si臋, 偶e jest oparty nad SVN na back-end.
  • Prowadzaj膮 trunk-based development.
  • 6 mln zatwierdze艅, 2 mln plik贸w, 2TB rozmiar repo.
  • Wypr贸bowali Mercurial, ale nie rozwi膮za艂 problem贸w wydajno艣ci.
  • U偶ywaj膮 numery generacji [ang. 鈥済eneration numbers鈥漖 do obliczania 鈥渕erge-bases鈥.
  • Prawdopodobnie oparty nad Gitem do front-end UI, ale narzekaj膮, 偶e UI Gita jest z艂y, wi臋c go ulepszaj膮.
  • U偶ywany wewn臋trznie przez 20% deweloperzy w momencie napisania.
  • Ci臋偶ko u偶ywa wirtualnego system plik贸w [ang. 鈥渧irtual filesystem鈥, 鈥淰FS鈥漖.
    • U偶ywaj膮 FUSE na macOS, chocia偶 wsparcie VFS鈥櫭硍 na macOS jest niestabilne w tym czasie; mo偶e zmienili od tamtego czasu?
  • U偶ywa Yandex Database (YDB) jako baz臋 danych na back-end, z jakim艣 narz臋dziem przek艂adania z SVN鈥檃.
  • W ramach systemu code review, zatwierdzenie Arc鈥檃 b臋dzie przedk艂adane w zatwierdzenie SVN鈥檃, w tym dodatkowe metadane z Arc鈥檃.
  • Niezauwa偶alnie u偶ywa zatwierdzenia dla 鈥渨orking copy鈥 aby przeprowadza膰 niekt贸re algorytmy, kt贸ry zawiera膰 鈥渦ntracked鈥 pliki, poniewa偶 zaopatrzywa VFS.

W sumie, nie wydaje mi si臋, 偶e ma wiele do awansowania system贸w kontroli wersji w por贸wnaniu z du偶ymi firmami tech, takimi jak Google i Meta.

Komentarze