Sapling legger vekt på brukervennlighet mens den skaleres til verdens største depoter.
Facebook avduket gjennom et blogginnlegg kildekodestyringssystemet ungtrær brukes i utviklingen av interne prosjekter i selskapet. Systemet har som mål å gi et versjonskontrollgrensesnitt kjente som kan skaleres til veldig store depoter som spenner over titalls millioner filer, commits og filialer.
Hovedideen med systemet er at ved å samhandle med en spesiell del av serveren som gir lagerlagring, alle operasjoner skaleres basert på antall filer faktisk brukt i koden utvikleren jobber med, og er ikke avhengig av den totale størrelsen på hele depotet.
For eksempel kan en utvikler bare bruke en liten del av koden fra et veldig stort depot, og bare denne lille delen, og ikke hele depotet, vil bli overført til systemet deres. Arbeidskatalogen fylles dynamisk, ettersom depotfilene åpnes, noe som på den ene siden lar deg gjøre arbeidet betydelig raskere med din del av koden, men på den annen side bremser den ned når du får tilgang til den for første gang til nye filer og krever konstant nettverkstilgang (gis separat og offline-forpliktelses-forberedelsesmodus).
I tillegg til adaptiv datalasting, Sapling implementerer også optimaliseringer rettet mot å redusere informasjonsbelastningen med en historikk med endringer. (for eksempel er 3/4 av dataene i et depot med Linux-kjernen endringshistorikk).
For å jobbe effektivt med endringshistorikken, lagres dataene knyttet til den i en segmentert visning, som lar deg laste ned separate deler av commit-grafen fra serveren. Klienten kan be serveren om informasjon om forholdet til flere bekreftelser og kun laste ned den nødvendige delen av grafen.
Prosjektet har vært under utvikling de siste 10 årene og ble opprettet for å løse problemer ved tilgang til veldig store monolittiske depoter med en mastergren, der praksisen med å bruke "rebase"-operasjonen i stedet for "merge" ble praktisert.
På den tiden var det ingen åpne løsninger for å jobbe med slike depoter, og Facebook-ingeniører bestemte seg for å lage et nytt versjonskontrollsystem som ville møte selskapets behov, i stedet for å dele opp prosjekter i små depoter, noe som ville føre til mer komplisert avhengighetsstyring ( på en gang, for å løse et lignende problem, opprettet Microsoft GVFS-laget).
I utgangspunktet brukte Facebook Mercurial-systemet og Sapling-prosjektet ble opprinnelig utviklet som et tillegg til Mercurial. Over tid ble systemet et selvstendig prosjekt med sin egen protokoll, lagringsformat og algoritmer, som også ble utvidet med muligheten til å samhandle med Git-depoter.
For arbeid, kommandolinjeverktøyet "sl" er foreslått, som implementerer typiske konsepter, arbeidsflyter og et grensesnitt kjent for utviklere som er kjent med Git og Mercurial. Terminologien og kommandoene i Sapling er litt forskjellig fra Git og nærmere Mercurial.
Blant tilleggsfunksjonene av Sapling, fremhever støtte for "smart registrering" (smartlog), som lar deg visuelt vurdere statusen til depotet ditt, fremhev den viktigste informasjonen og filtrer ut mindre detaljer. For eksempel, når du kjører sl-verktøyet uten argumenter, vises bare dine egne lokale endringer (utenlandske endringer er kollapset), statusen til eksterne filialer, endrede filer og nye versjoner av forpliktelser vises. I tillegg er det et interaktivt nettgrensesnitt for rask navigering gjennom smartloggen, endringstreet og commits.
En annen bemerkelsesverdig forbedring i Sapling er det det gjør prosessen med å fikse og analysere feil og gå tilbake til en tidligere tilstand mye enklere. For eksempel er kommandoene "sl undo", "sl redo", "sl uncommit" og "sl unmend" foreslått for å reversere mange operasjoner, "sl hide" og "sl unhide" for midlertidig å skjule forpliktelser og for interaktiv navigering. stater Sapling støtter også konseptet med en commit stack, som lar deg organisere en gjennomgang trinn for trinn ved å bryte ned kompleks funksjonalitet i et mindre, mer forståelig inkrementell sett med endringer (fra et grunnleggende rammeverk til en endelig funksjon).
Hver for seg, en serverdel ble utviklet for effektivt eksternt arbeid med repositories og et virtuelt filsystem for å jobbe med en lokal del av en del av depotet som om det var et komplett depot (utvikleren ser hele depotet, men bare de forespurte dataene kopieres til det lokale systemet, som er tilgjengelig).
Koden for disse komponentene som brukes i Facebooks infrastruktur er ikke åpen ennå, men selskapet har lovet å gi den ut i fremtiden. Imidlertid kan Mononoke-serveren (i Rust) og VFS EdenFS (i C++)-prototypene allerede finnes i Sapling-depotet. Disse komponentene er valgfrie og Sapling-klienten er nok å jobbe med, som støtter kloning av Git-repositories, samhandling med Git LFS-baserte servere og arbeid med git-verter som GitHub.
Det er utarbeidet flere plugins for Sapling, inkludert ReviewStack-grensesnittet for gjennomgang av endringer (kode under GPLv2), som lar deg behandle pull-forespørsler på GitHub og bruke en endringsstabelvisning.
Hvis du er interessert i å vite mer om det, kan du se detaljene I den følgende lenken.