Facebook (prohibido en la Federación Rusa) publicó el sistema de control de fuente Sapling, utilizado en el desarrollo de proyectos internos de la empresa. El sistema tiene como objetivo proporcionar una interfaz de control de versiones familiar que pueda escalarse para repositorios muy grandes que abarcan decenas de millones de archivos, confirmaciones y ramas. El código del cliente está escrito en Python y Rust y está abierto bajo la licencia GPLv2.
Se ha desarrollado por separado una parte del servidor para un trabajo remoto eficiente con repositorios y un sistema de archivos virtual para trabajar con una porción local de una parte del repositorio como un repositorio completo (el desarrollador ve el repositorio completo, pero solo se accede a los datos requeridos). se copia al sistema local). El código de estos componentes utilizados en la infraestructura de Facebook aún no está abierto, pero la compañía ha prometido publicarlo en el futuro. Sin embargo, actualmente en el repositorio de Sapling ya se pueden encontrar prototipos del servidor Mononoke (en Rust) y VFS EdenFS (en C++). Estos componentes son opcionales y para funcionar basta con el cliente Sapling, que admite la clonación de repositorios Git, la interacción con servidores basados en Git LFS y el trabajo con sitios de alojamiento git como GitHub.
La idea principal del sistema es que al interactuar con una parte especial del servidor que proporciona almacenamiento del repositorio, todas las operaciones se escalan dependiendo de la cantidad de archivos realmente utilizados en el código en el que está trabajando el desarrollador, y no dependen de el tamaño total de todo el repositorio. Por ejemplo, un desarrollador puede utilizar sólo una pequeña parte del código de un repositorio muy grande y sólo esa pequeña parte se migrará a su sistema, no todo el repositorio. El directorio de trabajo se llena dinámicamente a medida que se accede a los archivos del repositorio, lo que, por un lado, le permite acelerar significativamente el trabajo con su parte del código, pero, por otro lado, provoca una ralentización al acceder a nuevos archivos para el primera vez y requiere acceso constante a la red (modo fuera de línea y proporcionado por separado para preparar confirmaciones).
Además de la carga de datos adaptativa, Sapling también implementa optimizaciones destinadas a reducir la carga de información con el historial de cambios (por ejemplo, 3/4 de los datos en un repositorio con el kernel de Linux es el historial de cambios). Para trabajar eficazmente con el historial de cambios, los datos asociados con él se almacenan en una representación segmentada que le permite descargar partes individuales del gráfico de confirmación desde el servidor. El cliente puede solicitar información al servidor sobre la relación entre varias confirmaciones y descargar solo la parte necesaria del gráfico.
El proyecto se ha desarrollado durante los últimos 10 años y fue creado para resolver problemas al organizar el acceso a repositorios monolíticos muy grandes con una rama maestra, que utilizaba la operación "rebase" en lugar de "fusionar". En ese momento, no existían soluciones abiertas para trabajar con dichos repositorios, y los ingenieros de Facebook decidieron crear un nuevo sistema de control de versiones que satisficiera las necesidades de la empresa, en lugar de dividir los proyectos en pequeños repositorios, lo que llevaría a la complejidad de gestión de dependencias (en un momento, para resolver un problema similar, Microsoft creó la capa GVFS). Inicialmente, Facebook utilizó el sistema Mercurial y en la primera etapa el proyecto Sapling se desarrolló como complemento a Mercurial. Con el tiempo, el sistema se transformó en un proyecto independiente con su propio protocolo, formato de almacenamiento y algoritmos, que también se amplió con la capacidad de interactuar con repositorios Git.
Para trabajar, se ofrece una utilidad de línea de comandos "sl", que implementa conceptos típicos, flujos de trabajo y una interfaz familiar para los desarrolladores familiarizados con Git y Mercurial. La terminología y los comandos en Sapling son ligeramente diferentes a los de Git y están más cerca de Mercurial. Por ejemplo, en lugar de ramas, se utilizan "marcadores" (las ramas con nombre no son compatibles), de forma predeterminada, al ejecutar clonar/extraer, no se carga todo el repositorio, sino solo la rama principal, no hay marcado preliminar de confirmaciones ( área de preparación), en lugar de “git fetch” se usa el comando “sl” pull", en lugar de "git pull" - "sl pull -rebase", en lugar de "git checkout COMMIT" - "sl goto COMMIT", en lugar de "git reflog" - "sl journal", para cancelar un cambio en lugar de "git checkout - FILE" Se especifica "sl revert FILE" y "." se utiliza para identificar la rama "HEAD". Pero, en general, se conservan los conceptos generales de ramas y operaciones clonar/pull/push/commit/rebase.
Entre las características adicionales del kit de herramientas de Sapling, se destaca la compatibilidad con “smartlog”, que le permite evaluar visualmente el estado de su repositorio, resaltar la información más importante y filtrar los detalles sin importancia. Por ejemplo, cuando ejecuta la utilidad sl sin argumentos, solo se muestran en la pantalla sus propios cambios locales (otros se minimizan), se muestra el estado de las ramas externas, los archivos modificados y las nuevas versiones de las confirmaciones. Además, se ofrece una interfaz web interactiva que permite navegar rápidamente a través del registro inteligente, el árbol de cambios y las confirmaciones.
Otra mejora notable en Sapling es que facilita la corrección y resolución de errores y la reversión a un estado anterior. Por ejemplo, los comandos "sl undo", "sl redo", "sl uncommit" y "sl unamend" se ofrecen para revertir muchas operaciones; los comandos "sl hide" y "sl unhide" se utilizan para ocultar temporalmente las confirmaciones; y para navegación interactiva a través de estados antiguos y regresar al punto especificado con el comando “sl undo -i comando”. Sapling también admite el concepto de pila de confirmación, que le permite organizar revisiones paso a paso dividiendo funciones complejas en un conjunto de cambios incrementales más pequeños y comprensibles (desde un marco básico hasta una función terminada).
Se han preparado varias adiciones para Sapling, incluida la interfaz ReviewStack para revisar cambios (código bajo GPLv2), que le permite procesar solicitudes de extracción en GitHub y usar una vista de pila de cambios. Además, se han publicado complementos para la integración con los editores VSCode y TextMate, así como la implementación de la interfaz y el servidor ISL (Interactive SmartLog).
Fuente: opennet.ru