Facebook (forbudt i Russland) har publisert Sapling kildekodestyringssystem som brukes i utviklingen av selskapets interne prosjekter. Systemet tar sikte på å gi et kjent versjonsgrensesnitt som kan skaleres til veldig store depoter som spenner over titalls millioner filer, commits og grener. Klientkoden er skrevet i Python og Rust, og er åpen under GPLv2-lisensen.
Separat ble det utviklet en serverdel for effektivt eksternt arbeid med depoter og et virtuelt filsystem for å jobbe med en lokal del av en del av depotet som med et fullstendig depot (utvikleren ser hele depotet, men bare de forespurte dataene kopieres til det lokale systemet, som du får tilgang til). Koden for disse komponentene som brukes i Facebook-infrastrukturen er ennå ikke åpen, men selskapet lovet å publisere den i fremtiden. Imidlertid kan prototyper av Mononoke-serveren (i Rust) og VFS EdenFS (i C++) allerede finnes i Sapling-depotet. Disse komponentene er valgfrie og Sapling-klienten er nok til å fungere, som støtter kloning av Git-lagre, samhandling med servere basert på Git LFS og arbeid med git-verter som GitHub.
Hovedideen med systemet er at når du samhandler med en spesiell serverdel som gir lagring av depotet, skaleres alle operasjoner avhengig av antall filer som faktisk brukes 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, i stedet for hele depotet, vil bli overført til systemet hans. Arbeidskatalogen fylles dynamisk, ettersom filer fra depotet åpnes, noe som på den ene siden lar deg gjøre arbeidet med din del av koden betydelig raskere, men på den annen side fører til en nedgang når du først åpner nye filer og krever konstant tilgang til nettverket (separat levert og offline-modus for forberedelse av forpliktelser).
I tillegg til adaptiv datalasting, implementerer Sapling også optimaliseringer som tar sikte på å redusere lasting av informasjon med en endringshistorikk (for eksempel er 3/4 av dataene i et depot med Linux-kjernen historikk for endringer). 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 forpliktelser og kun laste ned den nødvendige delen av grafen.
Prosjektet har blitt utviklet i løpet av de siste 10 årene og ble opprettet for å løse problemer ved organisering av tilgang til svært store monolittiske depoter med én mastergren, der praksisen med å bruke «rebase»-operasjonen i stedet for «merge» ble praktisert. På den tiden fantes det ingen åpne løsninger for å jobbe med slike depoter, og Facebooks ingeniører bestemte seg for å lage et nytt versjonskontrollsystem som dekker selskapets behov, i stedet for å dele opp prosjekter i små depoter, noe som ville føre til mer komplisert avhengighetshåndtering (på en gang, for å løse et lignende problem, opprettet Microsoft GVFS-laget). Opprinnelig brukte Facebook Mercurial-systemet og Sapling-prosjektet ble opprinnelig utviklet som et tillegg til Mercurial. Over tid forvandlet systemet seg til et uavhengig prosjekt med egen protokoll, lagringsformat og algoritmer, som også ble utvidet med muligheten til å samhandle med Git-repositories.
For arbeid foreslås kommandolinjeverktøyet "sl", 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. For eksempel brukes "bokmerker" i stedet for grener (navngitte grener støttes ikke), som standard, når du utfører kloning / pull, er ikke hele depotet lastet, men bare hovedgrenen, det er ingen forhåndsmerking av forpliktelser ( staging area), i stedet for "git fetch" brukes "sl"-kommandoen pull", i stedet for "git pull" - "sl pull --rebase", i stedet for "git checkout COMMIT" - "sl goto COMMIT", i stedet for av "git reflog" - "sl journal", for å tilbakestille endringen i stedet for "git checkout - FILE" "sl revert FILE" er spesifisert, og "." brukes til å identifisere "HEAD"-grenen. Men generelt er de generelle konseptene for grener og klone/pull/push/commit/rebase operasjoner bevart.
Blant tilleggsfunksjonene til Sapling-verktøysettet skiller det seg ut støtte for en "smart logg" (smartlog), som lar deg visuelt vurdere tilstanden til depotet ditt, fremheve den viktigste informasjonen og filtrere 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 grener, endrede filer og nye versjoner av commits vises. I tillegg tilbys et interaktivt web-grensesnitt, som gjør det mulig å raskt navigere gjennom smartloggen, endre tre og commits.
En annen bemerkelsesverdig forbedring i Sapling er forenklingen av prosessen med å fikse og analysere feil, og gå tilbake til en tidligere tilstand. For eksempel, kommandoene "sl undo", "sl redo", "sl uncommit" og "sl unamend" tilbys for å rulle tilbake mange operasjoner, "sl hide" og "sl unhide"-kommandoer for å midlertidig skjule forpliktelser, og interaktiv navigering gjennom gamle tilstander og returner til det angitte punktet kommandoen "sl undo -i command". Sapling støtter også konseptet med en commit stack, som lar deg organisere en trinnvis gjennomgang ved å bryte ned kompleks funksjonalitet i et sett med mindre og mer forståelige inkrementelle endringer (fra et grunnleggende rammeverk til en ferdig funksjon).
Det er utarbeidet flere tillegg for Sapling, inkludert ReviewStack-grensesnittet for gjennomgang av endringer (kode under GPLv2), som lar deg behandle pull-forespørsler på GitHub og bruke en stackvisning av endringer. I tillegg er det publisert tillegg for integrasjon med VSCode og TextMate editorer, samt implementering av ISL (Interactive SmartLog) grensesnitt og server.
Kilde: opennet.ru