Facebook (заборонено в РФ) опублікував систему управління вихідними текстами Sapling, що застосовується під час розробки внутрішніх проектів компанії. Система націлена на надання звичного інтерфейсу управління версіями, який може масштабуватися для великих репозиторіїв, що охоплюють десятки мільйонів файлів, коммітів і гілок. Код клієнта написаний мовами Python та Rust, і відкритий під ліцензією GPLv2.
Окремо розроблено серверну частину для ефективної віддаленої роботи з репозиторіями та віртуальну файлову систему для роботи з локальним зрізом частини репозиторію як з повним репозиторієм (розробник бачить весь репозиторій, але на локальну систему копіюються лише затребувані дані, до яких здійснюються звернення). Код даних компонентів, що використовується в інфраструктурі Facebook, поки не відкритий, але компанія обіцяла опублікувати його в майбутньому. Тим не менш, в даний час в репозиторії Sapling вже можна знайти прототипи сервера Mononoke (язиком Rust) і VFS EdenFS (С++). Дані компоненти не є обов'язковими і для роботи достатньо клієнта Sapling, який підтримує клонування Git-репозиторіїв, взаємодію з серверами на базі Git LFS і роботу з git-хостингами, такими як GitHub.
Основна ідея системи в тому, що при взаємодії зі спеціальною серверною частиною, що забезпечує зберігання репозиторію, всі операції масштабуються в залежності від кількості файлів, що реально використовуються в коді, над яким працює розробник, і не залежать від загального розміру репозиторію. Наприклад, розробник може використовувати лише невелику порцію коду з дуже великого репозиторію і його систему буде перенесена лише ця невелика частина, а чи не весь репозиторій. Заповнення робочого каталогу проводиться динамічно, у міру звернення до файлів з репозиторію, що з одного боку дозволяє суттєво прискорити роботу зі своєю частиною коду, але з іншого боку призводить до уповільнення при першому зверненні до нових файлів і потребує постійного доступу до мережі (окремо передбачений і offline-режим підготовки комітів).
Крім адаптивного завантаження даних у Sapling також реалізовані та оптимізації, спрямовані на скорочення завантаження інформації з історією змін (наприклад, 3/4 даних у репозиторії з ядром Linux припадає на історію змін). Для ефективної роботи з історією змін, пов'язані з нею даних, зберігаються в сегментованому поданні, що дозволяє завантажувати з сервера окремі частини графа коммітів. Клієнт може запросити у сервера інформацію про зв'язок кількох коммітів та завантажити лише необхідну частину графа.
Проект розвивається протягом останніх 10 років і був створений для вирішення проблем при організації доступу до дуже великих монолітних репозиторій з однією master-гілкою, в яких практикувалося застосування операції rebase замість merge. У той час відкриті рішення для роботи з подібними репозиторіями були відсутні і інженери Facebook вирішили створити нову систему управління версіями, що відповідає потребам компанії, замість дроблення проектів на дрібні репозиторії, що призвело б до ускладнення управління залежностями (свого часу для вирішення аналогічної проблеми компанія Microsoft створила прошарок GVFS). Спочатку в Facebook застосовувалася система Mercurial і проект Sapling першому етапі розвивався як доповнення до Mercurial. Згодом система трансформувалася у самостійний проект зі своїм протоколом, форматом зберігання та алгоритмами, який також був розширений можливістю взаємодії з Git-репозиторіями.
Для роботи пропонується утиліта командного рядка «sl», що реалізує типові концепції, робочі процеси та інтерфейс, звичні для розробників, знайомих із Git та Mercurial. Термінологія та команди у Sapling трохи відрізняються від Git та ближчі до Mercurial. Наприклад, замість гілок використовуються «закладки» (іменовані гілки не підтримуються), за замовчуванням при виконанні clone/pull завантажується не весь репозиторій, а лише основна гілка, відсутня попереднє маркування комітів (staging area), замість «git fetch» застосовується команда «sl pull», замість «git pull» — «sl pull —rebase», замість «git checkout COMMIT» — «sl goto COMMIT», замість «git reflog»-«sl journal», для скасування зміни замість «git checkout — FILE» вказується "sl revert FILE", а для ідентифікації гілки "HEAD" застосовується ".". Але загалом, загальні концепції гілок та операцій clone/pull/push/commit/rebase зберігаються.
З додаткових можливостей інструментарію Sapling виділяється підтримка «розумного лога» (smartlog), що дозволяє наочно оцінити стан свого репозиторію, виділити найважливішу інформацію та відсіяти другорядні деталі. Наприклад, при запуску утиліти sl без аргументів на екран виводяться лише власні локальні зміни (чужі згортаються), показується стан зовнішніх гілок, змінені файли та нові версії коммітів. Додатково пропонується інтерактивний web-інтерфейс, що дає можливість швидко переміщатися по розумному логу, дереву змін та комітам.
Іншим помітним поліпшенням Sapling є спрощення процесу виправлення і розбору помилок, і повернення до минулого стану. Наприклад, для відкату багатьох операцій пропонуються команди "sl undo", "sl redo", "sl uncommit" і "sl unamend", для тимчасового приховування коммітів команди "sl hide" і "sl unhide", а для інтерактивної навігації за старими станами та поверненню до зазначеної точки команда "sl undo -i command". У Sapling також підтримується концепція стека коммітів, що дозволяє організувати покрокове рецензування через дроблення складної функціональності на набір з невеликих і зрозуміліших інкрементальних змін (від базового каркасу до готової функції).
Для Sapling підготовлено кілька доповнень, серед яких інтерфейс для рецензування змін ReviewStack (код під GPLv2), що дозволяє обробляти pull-запити на GitHub та використовувати стекове представлення змін. Крім того, опубліковано доповнення для інтеграції з редакторами VSCode та TextMate, а також реалізація інтерфейсу та сервера ISL (Interactive SmartLog).
Джерело: opennet.ru