Sapling наголошує на простоті використання при масштабуванні до найбільших у світі сховищ.
Facebook представлений через публікацію в блозі систему керування вихідним кодом Саджанець використовується при розробці внутрішніх проектів компанії. Система має на меті забезпечити інтерфейс контролю версій знайомий, який можна масштабувати до дуже великих сховищ, що охоплюють десятки мільйонів файлів, комітів і гілок.
Основна ідея системи полягає в тому, що, взаємодіючи зі спеціальною частиною сервера, яка забезпечує зберігання репозиторію, масштабування всіх операцій залежить від кількості файлів фактично використовуються в коді, над яким працює розробник, і не залежать від загального розміру всього сховища.
Наприклад, розробник може використовувати лише невелику частину коду з дуже великого репозиторію, і лише ця невелика частина, а не весь репозиторій, буде передана в його систему. Робоча директорія заповнюється динамічно, у міру звернення до файлів репозиторію, що, з одного боку, дозволяє істотно прискорити роботу з вашою частиною коду, а з іншого боку, уповільнює її при зверненні до нього на перший раз до нових файлів і вимагає постійного доступу до мережі (надається окремо та режим підготовки офлайн-коміту).
На додаток до адаптивного завантаження даних, Sapling також реалізує оптимізацію, спрямовану на зменшення інформаційного навантаження з історією змін. (наприклад, 3/4 даних у сховищі з ядром Linux – це історія змін).
Для ефективної роботи з історією змін пов’язані з нею дані зберігаються в сегментованому поданні, що дозволяє завантажувати окремі частини графіка комітів із сервера. Клієнт може запитати у сервера інформацію про зв'язок кількох підтверджень і завантажити лише необхідну частину графа.
Проект розроблявся протягом останніх 10 років і був створений для вирішення проблем під час доступу до дуже великих монолітних репозиторіїв з головною гілкою, де практикувалася практика використання операції «rebase» замість «merge».
На той момент не було відкритих рішень для роботи з такими репозитаріями, і інженери Facebook вирішили створити нову систему контролю версій, яка б відповідала потребам компанії, а не розбивати проекти на невеликі репозиторії, що призвело б до більш складного управління залежностями ( свого часу для вирішення подібної проблеми Microsoft створила рівень GVFS).
Спочатку Facebook використовував систему Mercurial і проект Sapling спочатку був розроблений як додаток до Mercurial. Згодом система стала самостійним проектом з власним протоколом, форматом зберігання та алгоритмами, які також були розширені можливістю взаємодії зі сховищами Git.
Для роботи, пропонується утиліта командного рядка "sl", який реалізує типові концепції, робочі процеси та інтерфейс, знайомий розробникам, знайомим із Git і Mercurial. Термінологія та команди в Sapling дещо відрізняються від Git і ближчі до Mercurial.
Серед додаткових функцій саджанця, висвітлює в підтримка «розумної реєстрації» (smartlog), що дозволяє візуально оцінити стан вашого сховища, виділіть найважливішу інформацію та відфільтруйте другорядні деталі. Наприклад, коли ви запускаєте утиліту sl без аргументів, відображаються лише ваші локальні зміни (чужі згортаються), відображається стан зовнішніх гілок, змінених файлів і нових версій комітів. Крім того, надається інтерактивний веб-інтерфейс для швидкої навігації по інтелектуальному журналу, дереву змін і комітам.
Ще одне помітне вдосконалення Sapling полягає в тому, що це значно полегшує процес виправлення та аналізу помилок і повернення до попереднього стану. Наприклад, команди «sl undo», «sl redo», «sl uncommit» і «sl unmend» пропонуються для скасування багатьох операцій, «sl hide» і «sl unhide» для тимчасового приховування комітів і для інтерактивної навігації. стверджує, що Sapling також підтримує концепцію стека фіксації, яка дозволяє організувати перегляд крок за кроком, розбиваючи складну функціональність на менший, більш зрозумілий поступовий набір змін (від базової основи до кінцевої функції).
Окремо, розроблено серверну частину для ефективної віддаленої роботи з репозитаріями і віртуальна файлова система для роботи з локальною частиною частини сховища, як якщо б це був повний репозиторій (розробник бачить весь репозиторій, але лише запитані дані копіюються в локальну систему, до якої здійснюється доступ).
Код цих компонентів, які використовуються в інфраструктурі Facebook, ще не відкритий, але компанія пообіцяла опублікувати його в майбутньому. Однак прототипи сервера Mononoke (в Rust) і VFS EdenFS (в C++) вже можна знайти в репозиторії Sapling. Ці компоненти є необов’язковими, і для роботи достатньо клієнта Sapling, який підтримує клонування сховищ Git, взаємодію з серверами на основі Git LFS і роботу з хостами git, такими як GitHub.
Для Sapling підготовлено кілька плагінів, включаючи інтерфейс ReviewStack для перегляду змін (код під GPLv2), який дозволяє обробляти запити на отримання на GitHub і використовувати подання стеку змін.
Якщо вам цікаво дізнатися більше про це, ви можете ознайомитися з деталями У наступному посиланні.