Docelowi odbiorcy Deweloperzy systemów kontroli źródła, tak jak Git i Mercurial.
Pochodzenie
Nastrój Lekko zainteresowany.
Język Obcy. Moim pierwszym język jest angielki. Jeśli zobaczysz błąd, niezależnie od tego, czy chodzi o pisownię, gramatykę czy dobór słow, skomentuj to!

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. “source control system”], żeby sobie z tym radzić, o nazwie “Arc”.

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. “generation numbers”] do obliczania “merge-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. “virtual filesystem”, “VFS”].
    • Używają FUSE na macOS, chociaż wsparcie VFS’ów 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’a.
  • W ramach systemu code review, zatwierdzenie Arc’a będzie przedkładane w zatwierdzenie SVN’a, w tym dodatkowe metadane z Arc’a.
  • Niezauważalnie używa zatwierdzenia dla “working copy” aby przeprowadzać niektóre algorytmy, który zawierać “untracked” 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