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).
Source: opennet.ru