Facebook (interdit en Fédération de Russie) a publié le système de contrôle de source Sapling, utilisé dans le développement de projets internes à l'entreprise. Le système vise à fournir une interface de contrôle de version familière, capable de s'adapter à de très grands référentiels couvrant des dizaines de millions de fichiers, de commits et de branches. Le code client est écrit en Python et Rust et est ouvert sous licence GPLv2.
Une partie serveur a été développée séparément pour un travail à distance efficace avec des référentiels et un système de fichiers virtuel pour travailler avec une tranche locale d'une partie du référentiel en tant que référentiel complet (le développeur voit l'intégralité du référentiel, mais uniquement les données requises auxquelles il accède est copié sur le système local). Le code de ces composants utilisés dans l'infrastructure de Facebook n'est pas encore ouvert, mais l'entreprise a promis de le publier à l'avenir. Cependant, actuellement dans le référentiel Sapling, vous pouvez déjà trouver des prototypes du serveur Mononoke (en Rust) et du VFS EdenFS (en C++). Ces composants sont facultatifs et le client Sapling suffit pour fonctionner, qui prend en charge le clonage des référentiels Git, l'interaction avec des serveurs basés sur Git LFS et le travail avec des sites d'hébergement git tels que GitHub.
L'idée principale du système est que lors de l'interaction avec une partie serveur spéciale qui assure le stockage du référentiel, toutes les opérations sont mises à l'échelle en fonction du nombre de fichiers réellement utilisés dans le code sur lequel le développeur travaille, et ne dépendent pas de la taille totale de l'ensemble du référentiel. Par exemple, un développeur peut n'utiliser qu'une petite partie du code d'un très grand référentiel et seule cette petite partie sera migrée vers son système, et non l'intégralité du référentiel. Le répertoire de travail est rempli dynamiquement au fur et à mesure de l'accès aux fichiers du référentiel, ce qui, d'une part, vous permet d'accélérer considérablement le travail avec votre partie de code, mais d'autre part entraîne un ralentissement lors de l'accès à de nouveaux fichiers pour le la première fois et nécessite un accès constant au réseau (fourni séparément et mode hors ligne pour préparer les commits).
En plus du chargement adaptatif des données, Sapling met également en œuvre des optimisations visant à réduire le chargement d'informations avec l'historique des modifications (par exemple, les 3/4 des données d'un référentiel avec le noyau Linux sont l'historique des modifications). Pour travailler efficacement avec l'historique des modifications, les données qui y sont associées sont stockées dans une représentation segmentée qui vous permet de télécharger des parties individuelles du graphique de validation depuis le serveur. Le client peut demander des informations au serveur sur la relation entre plusieurs commits et télécharger uniquement la partie nécessaire du graphique.
Le projet s'est développé au cours des 10 dernières années et a été créé pour résoudre les problèmes liés à l'organisation de l'accès à de très grands référentiels monolithiques avec une branche principale, qui utilisaient l'opération « rebase » au lieu de « fusionner ». À cette époque, il n'existait pas de solutions ouvertes pour travailler avec de tels référentiels, et les ingénieurs de Facebook ont décidé de créer un nouveau système de contrôle de version qui répondrait aux besoins de l'entreprise, au lieu de diviser les projets en petits référentiels, ce qui entraînerait une complexité accrue. gestion des dépendances (à une époque, pour résoudre un problème similaire, Microsoft a créé la couche GVFS). Initialement, Facebook a utilisé le système Mercurial et le projet Sapling a été développé dans un premier temps en complément de Mercurial. Au fil du temps, le système s'est transformé en un projet indépendant avec son propre protocole, format de stockage et algorithmes, qui a également été étendu avec la possibilité d'interagir avec les référentiels Git.
Pour le travail, un utilitaire de ligne de commande « sl » est proposé, qui implémente des concepts typiques, des flux de travail et une interface familière aux développeurs familiarisés avec Git et Mercurial. La terminologie et les commandes de Sapling sont légèrement différentes de celles de Git et sont plus proches de Mercurial. Par exemple, à la place des branches, des « signets » sont utilisés (les branches nommées ne sont pas prises en charge), par défaut, lors de l'exécution de clone/pull, ce n'est pas tout le référentiel qui est chargé, mais seulement la branche principale, il n'y a pas de marquage préalable des commits ( zone de transit), au lieu de « git fetch », la commande « sl » est utilisée pull", au lieu de "git pull" - "sl pull -rebase", au lieu de "git checkout COMMIT" - "sl goto COMMIT", au lieu de "git reflog" - "sl journal", pour annuler une modification au lieu de "git checkout - FILE" "sl revert FILE" est spécifié, et "." est utilisé pour identifier la branche "HEAD". Mais en général, les concepts généraux de branches et d’opérations clone/pull/push/commit/rebase sont conservés.
Parmi les fonctionnalités supplémentaires de la boîte à outils Sapling, on distingue la prise en charge du « smartlog », qui vous permet d'évaluer visuellement l'état de votre référentiel, de mettre en évidence les informations les plus importantes et de filtrer les détails sans importance. Par exemple, lorsque vous exécutez l'utilitaire sl sans arguments, seules vos propres modifications locales sont affichées à l'écran (les autres sont réduites), l'état des branches externes, les fichiers modifiés et les nouvelles versions des commits sont affichés. De plus, une interface Web interactive est proposée, qui permet de naviguer rapidement dans le journal intelligent, l'arborescence des modifications et les validations.
Une autre amélioration notable de Sapling est qu’il facilite la correction et la résolution des erreurs et le retour à un état antérieur. Par exemple, les commandes « sl undo », « sl redo », « sl uncommit » et « sl unamend » sont proposées pour annuler de nombreuses opérations ; les commandes « sl hide » et « sl unhide » sont utilisées pour masquer temporairement les commits ; et pour une navigation interactive à travers les anciens états et revenir au point spécifié avec la commande « sl undo -i command ». Sapling prend également en charge le concept de pile de validation, qui vous permet d'organiser des révisions étape par étape en divisant des fonctionnalités complexes en un ensemble de modifications incrémentielles plus petites et plus compréhensibles (d'un cadre de base à une fonction finie).
Plusieurs ajouts ont été préparés pour Sapling, notamment l'interface ReviewStack de révision des modifications (code sous GPLv2), qui permet de traiter les pull request sur GitHub et d'utiliser une vue pile des modifications. De plus, des ajouts ont été publiés pour l'intégration avec les éditeurs VSCode et TextMate, ainsi que la mise en œuvre de l'interface et du serveur ISL (Interactive SmartLog).
Source: opennet.ru