Facebook (vietato nella Federazione Russa) ha pubblicato il sistema di controllo del codice sorgente Sapling, utilizzato nello sviluppo di progetti interni all'azienda. Il sistema mira a fornire un'interfaccia di controllo della versione familiare in grado di adattarsi a repository molto grandi che comprendono decine di milioni di file, commit e rami. Il codice client è scritto in Python e Rust ed è aperto con licenza GPLv2.
Una parte server è stata sviluppata separatamente per un lavoro remoto efficiente con i repository e un file system virtuale per lavorare con una sezione locale di una parte del repository come repository completo (lo sviluppatore vede l'intero repository, ma solo i dati richiesti a cui si accede viene copiato nel sistema locale). Il codice di questi componenti utilizzati nell'infrastruttura di Facebook non è ancora aperto, ma l'azienda ha promesso di pubblicarlo in futuro. Tuttavia, attualmente nel repository Sapling è già possibile trovare i prototipi del server Mononoke (in Rust) e VFS EdenFS (in C++). Questi componenti sono opzionali e per funzionare è sufficiente il client Sapling, che supporta la clonazione di repository Git, l'interazione con server basati su Git LFS e il lavoro con siti di hosting git come GitHub.
L'idea principale del sistema è che quando si interagisce con una parte speciale del server che fornisce l'archiviazione del repository, tutte le operazioni vengono ridimensionate in base al numero di file effettivamente utilizzati nel codice su cui sta lavorando lo sviluppatore e non dipendono da la dimensione totale dell'intero repository. Ad esempio, uno sviluppatore può utilizzare solo una piccola porzione di codice da un repository molto grande e solo quella piccola porzione verrà migrata nel suo sistema, non nell'intero repository. La directory di lavoro viene riempita dinamicamente quando si accede ai file dal repository, il che, da un lato, consente di accelerare notevolmente il lavoro con la propria parte di codice, ma dall'altro comporta un rallentamento quando si accede a nuovi file per il prima volta e richiede un accesso costante alla rete (modalità offline e fornita separatamente per la preparazione dei commit).
Oltre al caricamento adattivo dei dati, Sapling implementa anche ottimizzazioni volte a ridurre il caricamento delle informazioni con la cronologia delle modifiche (ad esempio, 3/4 dei dati in un repository con kernel Linux sono la cronologia delle modifiche). Per lavorare in modo efficace con la cronologia delle modifiche, i dati ad essa associati vengono archiviati in una rappresentazione segmentata che consente di scaricare singole parti del grafico di commit dal server. Il client può richiedere informazioni al server sulla relazione tra diversi commit e scaricare solo la parte necessaria del grafico.
Il progetto si è sviluppato negli ultimi 10 anni ed è stato creato per risolvere i problemi durante l'organizzazione dell'accesso a repository monolitici molto grandi con un ramo principale, che utilizzava l'operazione "rebase" anziché "merge". A quel tempo non esistevano soluzioni aperte per lavorare con tali repository e gli ingegneri di Facebook hanno deciso di creare un nuovo sistema di controllo delle versioni che soddisfacesse le esigenze dell'azienda, invece di dividere i progetti in piccoli repository, cosa che avrebbe portato alla complessità di gestione delle dipendenze (un tempo, per risolvere un problema simile, Microsoft ha creato il livello GVFS). Inizialmente Facebook utilizzava il sistema Mercurial e nella prima fase si sviluppò il progetto Sapling come integrazione a Mercurial. Nel corso del tempo, il sistema si è trasformato in un progetto indipendente con un proprio protocollo, formato di archiviazione e algoritmi, che è stato anche ampliato con la capacità di interagire con i repository Git.
Per lavoro, viene offerta l'utilità della riga di comando "sl", che implementa concetti tipici, flussi di lavoro e un'interfaccia familiare agli sviluppatori che hanno familiarità con Git e Mercurial. La terminologia e i comandi in Sapling sono leggermente diversi da Git e sono più vicini a Mercurial. Ad esempio, invece dei rami, vengono utilizzati i "segnalibri" (i rami con nome non sono supportati), per impostazione predefinita, quando si esegue clone/pull, non viene caricato l'intero repository, ma solo il ramo principale, non vi è alcuna marcatura preliminare dei commit ( area di staging), invece di “git fetch” viene utilizzato il comando “sl” pull", invece di "git pull" - "sl pull -rebase", invece di "git checkout COMMIT" - "sl goto COMMIT", invece di "git reflog" - "sl journal", per annullare una modifica invece di "git checkout - FILE" viene specificato "sl revert FILE" e "." viene utilizzato per identificare il ramo "HEAD". Ma in generale, i concetti generali di branch e operazioni clone/pull/push/commit/rebase vengono preservati.
Tra le funzionalità aggiuntive del toolkit Sapling spicca il supporto per “smartlog”, che consente di valutare visivamente lo stato del proprio repository, evidenziare le informazioni più importanti e filtrare i dettagli non importanti. Ad esempio, quando esegui l'utility sl senza argomenti, sullo schermo vengono visualizzate solo le modifiche locali (le altre sono ridotte a icona), vengono mostrati lo stato dei rami esterni, i file modificati e le nuove versioni dei commit. Inoltre, viene offerta un'interfaccia web interattiva, che rende possibile navigare rapidamente attraverso lo smart log, modificare l'albero e i commit.
Un altro notevole miglioramento di Sapling è che rende più semplice correggere e risolvere gli errori e ripristinare uno stato precedente. Ad esempio, i comandi “sl undo”, “sl redo”, “sl uncommit” e “sl unamend” vengono offerti per eseguire il rollback di molte operazioni; i comandi “sl hide” e “sl unhide” vengono utilizzati per nascondere temporaneamente i commit; e per la navigazione interattiva attraverso i vecchi stati e tornare al punto specificato con il comando “sl undo -i comando”. Sapling supporta anche il concetto di stack di commit, che consente di organizzare revisioni passo passo suddividendo funzionalità complesse in una serie di modifiche incrementali più piccole e più comprensibili (da una struttura di base a una funzione finita).
Sono state preparate diverse aggiunte per Sapling, inclusa l'interfaccia ReviewStack per la revisione delle modifiche (codice sotto GPLv2), che consente di elaborare richieste pull su GitHub e utilizzare una visualizzazione stack delle modifiche. Inoltre, sono state pubblicate integrazioni per l'integrazione con gli editor VSCode e TextMate, nonché l'implementazione dell'interfaccia e del server ISL (Interactive SmartLog).
Fonte: opennet.ru