Sapling enfatiza la facilidad de uso al tiempo que escala a los repositorios más grandes del mundo.

Facebook dio a conocer mediante una publicación de blog el sistema de gestión de código 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 escalar a repositorios muy grandes que abarquen decenas de millones de archivos, confirmaciones y ramas.

La idea principal del sistema es que al interactuar con una parte especial del servidor que proporciona almacenamiento de repositorio, todas las operaciones se escalan según la cantidad de archivos realmente utilizados en el código en el que está trabajando el desarrollador, y no dependen del total del tamaño de todo el repositorio.

Por ejemplo, un desarrollador puede usar solo una pequeña porción de código de un repositorio muy grande, y solo esta pequeña porción, y no todo el repositorio, se transferirá a su sistema. 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, lo ralentiza cuando accede por primera vez a nuevos archivos y requiere acceso constante a la red (se proporciona por separado y fuera de línea-modo de preparación de compromisos).

Además de la carga de datos adaptable, Sapling también implementa optimizaciones destinadas a reducir la carga de información con un historial de cambios (por ejemplo, 3/4 de los datos en un repositorio con el kernel de Linux es un historial de cambios).

Para trabajar de manera efectiva con el historial de cambios, los datos asociados con él se almacenan en una vista segmentada, lo que le permite descargar del servidor partes separadas del gráfico de confirmación. El cliente puede solicitar al servidor información sobre la relación de varias confirmaciones y descargar solo la parte necesaria del gráfico.

El proyecto ha estado en desarrollo durante los últimos 10 años y fue creado para resolver problemas al acceder a repositorios monolíticos muy grandes con una rama maestra, en los que se practicaba la práctica de usar la operación «rebase» en lugar de «merge».

En ese momento, no había soluciones abiertas para trabajar con dichos repositorios, y los ingenieros de Facebook decidieron crear un nuevo sistema de control de versiones que satisfaga las necesidades de la empresa, en lugar de dividir los proyectos en pequeños repositorios, lo que llevaría a una gestión de dependencias más complicada (en un momento, para resolver un problema similar, Microsoft creócapa GVFS).

Inicialmente, Facebook utilizó el sistema Mercurial y el proyecto Sapling se desarrolló inicialmente como una adición 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 los repositorios de Git.

Para el trabajo, se propone la 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 más cercanos a Mercurial.

Entre las características adicionales de Sapling, se destaca el soporte para un «registro inteligente» (smartlog), que permite evaluar visualmente el estado de su repositorio, resaltar la información más importante y filtrar detalles menores. Por ejemplo, cuando ejecuta la utilidad sl sin argumentos, solo se muestran sus propios cambios locales (los foráneos se contraen), se muestran 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 por el registro inteligente, el árbol de cambios y las confirmaciones.

Otra mejora notable en Sapling es que hace que el proceso de corregir y analizar errores y volver a un estado anterior sea mucho más fácil. Por ejemplo, se sugieren los comandos «sl undo», «sl redo», «sl uncommit» y «sl unmend» para revertir muchas operaciones, «sl hide» y «sl unhide» para ocultar temporalmente las confirmaciones y para la navegación interactiva a través de estados Sapling también admite el concepto de una pila de confirmaciones, que le permite organizar una revisión paso a paso al desglosar la funcionalidad compleja en un conjunto de cambios incrementales más pequeños y más comprensibles (desde un marco básico hasta una característica final).

Por separado, se desarrolló una parte del servidor para un trabajo remoto efectivo con repositorios y un sistema de archivos virtual para trabajar con una porción local de una parte del repositorio como si fuera un repositorio completo (el desarrollador ve todo el repositorio, pero solo se copian los datos solicitados) al sistema local, a los que se accede).

El código de estos componentes utilizados en la infraestructura de Facebook aún no está abierto, pero la empresa se comprometió a publicarlo en el futuro. Sin embargo, los prototipos del servidor Mononoke (en Rust) y VFS EdenFS (en C++) ya se pueden encontrar en el repositorio de Sapling. Estos componentes son opcionales y basta el cliente Sapling para trabajar, que soporta la clonación de repositorios Git, interactuando con servidores basados ​​en Git LFSy trabajando con hosts git como GitHub.

Se han preparado varios complementos para Sapling, incluida la interfaz ReviewStack para revisar cambios (código bajo GPLv2), que permite procesar solicitudes de extracción en GitHub y usar una vista de pila de cambios.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.