Отдельно разработана серверная часть для эффективной удалённой работы с репозиториями и виртуальная файловая система для работы с локальным срезом части репозитория как с полным репозиторием (разработчик видит весь репозиторий, но на локальную систему копируются только востребованные данные, к которым осуществляются обращения). Используемый в инфраструктуре 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).
Источник: http://www.opennet.ru/opennews/art.shtml?num=58123