Facebook (verboden in de Russische Federatie) publiceerde het Sapling-broncontrolesysteem, dat wordt gebruikt bij de ontwikkeling van interne bedrijfsprojecten. Het systeem streeft ernaar een vertrouwde interface voor versiebeheer te bieden die kan worden geschaald voor zeer grote opslagplaatsen met tientallen miljoenen bestanden, commits en branches. De clientcode is geschreven in Python en Rust en is open onder de GPLv2-licentie.
Er is afzonderlijk een servergedeelte ontwikkeld voor efficiënt werken op afstand met repositories en een virtueel bestandssysteem voor het werken met een lokaal deel van een deel van de repository als een volledige repository (de ontwikkelaar ziet de gehele repository, maar alleen de benodigde gegevens waartoe toegang wordt verkregen wordt gekopieerd naar het lokale systeem). De code voor deze componenten die in de infrastructuur van Facebook worden gebruikt, is nog niet open, maar het bedrijf heeft beloofd deze in de toekomst te publiceren. Momenteel kun je in de Sapling-repository echter al prototypes vinden van de Mononoke-server (in Rust) en VFS EdenFS (in C++). Deze componenten zijn optioneel en de Sapling-client is voldoende om te werken, die het klonen van Git-repository's ondersteunt, interactie met servers gebaseerd op Git LFS en werken met git-hostingsites zoals GitHub.
Het belangrijkste idee van het systeem is dat bij interactie met een speciaal serveronderdeel dat opslag van de repository biedt, alle bewerkingen worden geschaald afhankelijk van het aantal bestanden dat daadwerkelijk wordt gebruikt in de code waaraan de ontwikkelaar werkt, en niet afhankelijk zijn van de totale grootte van de gehele repository. Een ontwikkelaar kan bijvoorbeeld slechts een klein deel van de code uit een zeer grote repository gebruiken en alleen dat kleine gedeelte wordt naar zijn systeem gemigreerd, en niet de hele repository. De werkmap wordt dynamisch gevuld naarmate bestanden uit de repository worden benaderd, waardoor u enerzijds het werk met uw deel van de code aanzienlijk kunt versnellen, maar aan de andere kant leidt tot een vertraging bij het openen van nieuwe bestanden voor de de eerste keer en vereist constante toegang tot het netwerk (apart geleverd en offline modus voor het voorbereiden van commits).
Naast adaptief laden van gegevens implementeert Sapling ook optimalisaties gericht op het verminderen van het laden van informatie met de geschiedenis van wijzigingen (3/4 van de gegevens in een repository met de Linux-kernel is bijvoorbeeld de geschiedenis van wijzigingen). Om effectief met de geschiedenis van wijzigingen te kunnen werken, worden de daaraan gekoppelde gegevens opgeslagen in een gesegmenteerde weergave waarmee u afzonderlijke delen van de commit-grafiek van de server kunt downloaden. De client kan informatie opvragen bij de server over de relatie tussen verschillende commits en alleen het noodzakelijke deel van de grafiek downloaden.
Het project heeft zich de afgelopen tien jaar ontwikkeld en is in het leven geroepen om problemen op te lossen bij het organiseren van toegang tot zeer grote monolithische repository's met één masterbranch, die de bewerking 'rebase' gebruikte in plaats van 'merge'. Destijds waren er nog geen open oplossingen voor het werken met dergelijke repositories, en Facebook-ingenieurs besloten een nieuw versiebeheersysteem te creëren dat aan de behoeften van het bedrijf zou voldoen, in plaats van projecten op te splitsen in kleine repositories, wat zou leiden tot de complexiteit van afhankelijkheidsbeheer (om een soortgelijk probleem op te lossen, heeft Microsoft ooit een GVFS-laag gemaakt). Aanvankelijk gebruikte Facebook het Mercurial-systeem en het Sapling-project werd in de eerste fase ontwikkeld als aanvulling op Mercurial. In de loop van de tijd transformeerde het systeem in een onafhankelijk project met een eigen protocol, opslagformaat en algoritmen, dat ook werd uitgebreid met de mogelijkheid om te communiceren met Git-repository's.
Voor werk wordt een opdrachtregelhulpprogramma “sl” aangeboden, dat typische concepten, workflows en een interface implementeert die bekend is bij ontwikkelaars die bekend zijn met Git en Mercurial. De terminologie en commando's in Sapling verschillen enigszins van die van Git en liggen dichter bij Mercurial. In plaats van branches worden bijvoorbeeld “bladwijzers” gebruikt (benoemde branches worden niet ondersteund). Bij het uitvoeren van clone/pull wordt standaard niet de hele repository geladen, maar alleen de hoofdbranch, er is geen voorafgaande markering van commits ( staging area), in plaats van “git fetch” wordt het “sl” commando gebruikt pull", in plaats van "git pull" - "sl pull -rebase", in plaats van "git checkout COMMIT" - "sl goto COMMIT", in plaats van "git reflog" - "sl journal", om een wijziging te annuleren in plaats van "git checkout - FILE" "sl revert FILE" is gespecificeerd, en "." wordt gebruikt om de "HEAD" branch te identificeren. Maar over het algemeen blijven de algemene concepten van branches en kloon/pull/push/commit/rebase-operaties behouden.
Onder de extra functies van de Sapling-toolkit valt de ondersteuning voor “smartlog” op, waarmee u de status van uw repository visueel kunt beoordelen, de belangrijkste informatie kunt markeren en onbelangrijke details kunt filteren. Wanneer u bijvoorbeeld het hulpprogramma sl zonder argumenten uitvoert, worden alleen uw eigen lokale wijzigingen op het scherm weergegeven (andere worden geminimaliseerd), de status van externe branches, gewijzigde bestanden en nieuwe versies van commits worden weergegeven. Daarnaast wordt er een interactieve webinterface aangeboden, die het mogelijk maakt om snel door de slimme log te navigeren, de boomstructuur te wijzigen en commits te doen.
Een andere opmerkelijke verbetering in Sapling is dat het gemakkelijker wordt om fouten op te lossen en op te lossen en terug te keren naar een eerdere staat. De commando's "sl undo", "sl redo", "sl uncommit" en "sl unamend" worden bijvoorbeeld aangeboden om veel bewerkingen terug te draaien; de commando's "sl hide" en "sl unhide" worden gebruikt om commits tijdelijk te verbergen; en voor interactieve navigatie door oude staten en terugkeren naar het opgegeven punt met het commando “sl undo -i command”. Sapling ondersteunt ook het concept van een commit-stack, waarmee u stapsgewijze beoordelingen kunt organiseren door complexe functionaliteit op te splitsen in een reeks kleinere, begrijpelijker incrementele wijzigingen (van een basisframework tot een voltooide functie).
Er zijn verschillende toevoegingen voorbereid voor Sapling, waaronder de ReviewStack-interface voor het beoordelen van wijzigingen (code onder GPLv2), waarmee u pull-aanvragen op GitHub kunt verwerken en een stapelweergave van wijzigingen kunt gebruiken. Daarnaast zijn er aanvullingen gepubliceerd voor integratie met VSCode- en TextMate-editors, evenals de implementatie van de ISL (Interactive SmartLog) interface en server.
Bron: opennet.ru