Facebook (verbied in die Russiese Federasie) het die Sapling-bronbeheerstelsel gepubliseer, wat gebruik word in die ontwikkeling van interne maatskappyprojekte. Die stelsel beoog om 'n bekende weergawebeheerkoppelvlak te verskaf wat kan skaal vir baie groot bewaarplekke wat oor tienmiljoene lêers, commits en takke strek. Die kliëntkode is geskryf in Python en Rust, en is oop onder die GPLv2-lisensie.
'n Bedienerdeel is afsonderlik ontwikkel vir doeltreffende afgeleë werk met bewaarplekke en 'n virtuele lêerstelsel om met 'n plaaslike deel van 'n deel van die bewaarplek as 'n volledige bewaarplek te werk (die ontwikkelaar sien die hele bewaarplek, maar slegs die vereiste data waartoe toegang verkry word word na die plaaslike stelsel gekopieer). Die kode vir hierdie komponente wat in Facebook se infrastruktuur gebruik word, is nog nie oop nie, maar die maatskappy het belowe om dit in die toekoms te publiseer. Tans in die Sapling-bewaarplek kan u egter reeds prototipes van die Mononoke-bediener (in Rust) en VFS EdenFS (in C++) vind. Hierdie komponente is opsioneel en die Sapling-kliënt is genoeg om te werk, wat die kloning van Git-bewaarplekke ondersteun, interaksie met bedieners gebaseer op Git LFS en werk met git-gasheerwebwerwe soos GitHub.
Die hoofgedagte van die stelsel is dat wanneer daar interaksie is met 'n spesiale bedienerdeel wat berging van die bewaarplek bied, alle bewerkings afgeskaal word na gelang van die aantal lêers wat werklik gebruik word in die kode waaraan die ontwikkelaar werk, en nie afhanklik is van die totale grootte van die hele bewaarplek. Byvoorbeeld, 'n ontwikkelaar mag slegs 'n klein gedeelte van die kode van 'n baie groot bewaarplek gebruik en slegs daardie klein gedeelte sal na sy stelsel gemigreer word, nie die hele bewaarplek nie. Die werksgids word dinamies gevul soos toegang tot lêers van die bewaarplek verkry word, wat jou aan die een kant toelaat om die werk met jou deel van die kode aansienlik te bespoedig, maar aan die ander kant lei tot 'n verlangsaming wanneer toegang tot nuwe lêers vir die eerste keer en vereis konstante toegang tot die netwerk (apart verskaf en vanlyn modus vir die voorbereiding van commits).
Benewens aanpasbare data-laai, implementeer Sapling ook optimaliserings wat daarop gemik is om die laai van inligting met die geskiedenis van veranderinge te verminder (byvoorbeeld, 3/4 van die data in 'n bewaarplek met die Linux-kern is die geskiedenis van veranderinge). Om effektief met die geskiedenis van veranderinge te werk, word die data wat daarmee geassosieer word in 'n gesegmenteerde voorstelling gestoor wat jou toelaat om individuele dele van die commit-grafiek van die bediener af te laai. Die kliënt kan inligting van die bediener aanvra oor die verhouding tussen verskeie commits en slegs die nodige deel van die grafiek aflaai.
Die projek het oor die afgelope 10 jaar ontwikkel en is geskep om probleme op te los wanneer toegang tot baie groot monolitiese bewaarplekke met een meestertak georganiseer word, wat die "rebase"-operasie gebruik het in plaas van "merge". Op daardie tydstip was daar geen oop oplossings om met sulke bewaarplekke te werk nie, en Facebook-ingenieurs het besluit om 'n nuwe weergawebeheerstelsel te skep wat aan die behoeftes van die maatskappy sou voldoen, in plaas daarvan om projekte in klein bewaarplekke te verdeel, wat sou lei tot die kompleksiteit van afhanklikheidbestuur (op een slag, om 'n soortgelyke probleem op te los, het Microsoft GVFS-laag geskep). Aanvanklik het Facebook die Mercurial-stelsel gebruik en die Sapling-projek in die eerste stadium wat as 'n toevoeging tot Mercurial ontwikkel is. Met verloop van tyd het die stelsel omskep in 'n onafhanklike projek met sy eie protokol, stoorformaat en algoritmes, wat ook uitgebrei is met die vermoë om met Git-bewaarplekke te kommunikeer.
Vir werk word 'n opdragreëlhulpmiddel "sl" aangebied, wat tipiese konsepte, werkvloeie en 'n koppelvlak implementeer wat bekend is aan ontwikkelaars wat vertroud is met Git en Mercurial. Die terminologie en opdragte in Sapling verskil effens van Git en is nader aan Mercurial. Byvoorbeeld, in plaas van takke, word "boekmerke" gebruik (benoemde takke word nie ondersteun nie), by verstek, wanneer kloon/trek uitgevoer word, word nie die hele bewaarplek gelaai nie, maar slegs die hooftak, daar is geen voorlopige merk van commits nie ( staging area), in plaas van "git fetch" word die "sl" opdrag gebruik pull", in plaas van "git pull" - "sl pull -rebase", in plaas van "git checkout COMMIT" - "sl goto COMMIT", in plaas van "git reflog" - "sl joernaal", om 'n verandering te kanselleer in plaas van "git checkout - FILE" "sl revert FILE" is gespesifiseer, en "." word gebruik om die "HEAD" tak te identifiseer. Maar oor die algemeen word die algemene konsepte van takke en kloon/trek/stoot/pleeg/rebase-operasies bewaar.
Onder die bykomende kenmerke van die Sapling-gereedskapstel is ondersteuning vir “slimlog” uit, wat jou in staat stel om die toestand van jou bewaarplek visueel te assesseer, die belangrikste inligting uit te lig en onbelangrike besonderhede uit te filter. Byvoorbeeld, wanneer jy die sl-nutsprogram sonder argumente laat loop, word net jou eie plaaslike veranderinge op die skerm vertoon (ander word geminimaliseer), die toestand van eksterne takke, veranderde lêers en nuwe weergawes van commits word gewys. Daarbenewens word 'n interaktiewe webkoppelvlak aangebied, wat dit moontlik maak om vinnig deur die slim log te navigeer, boom te verander en commits.
Nog 'n noemenswaardige verbetering in Sapling is dat dit dit makliker maak om foute reg te stel en op te los en na 'n vorige toestand terug te keer. Byvoorbeeld, die opdragte "sl undo", "sl redo", "sl uncommit" en "sl unamend" word aangebied om baie bewerkings terug te rol; die opdragte "sl hide" en "sl unhide" word gebruik om commits tydelik te verberg; en vir interaktiewe navigasie deur ou state en keer terug na die gespesifiseerde punt met die opdrag "sl undo -i command". Sapling ondersteun ook die konsep van 'n commit-stapel, wat jou toelaat om stap-vir-stap resensies te organiseer deur komplekse funksionaliteit op te breek in 'n stel kleiner, meer verstaanbare inkrementele veranderinge (van 'n basiese raamwerk tot 'n voltooide funksie).
Verskeie toevoegings is vir Sapling voorberei, insluitend die ReviewStack-koppelvlak vir die hersiening van veranderinge (kode onder GPLv2), wat jou toelaat om trekversoeke op GitHub te verwerk en 'n stapelaansig van veranderinge te gebruik. Daarbenewens is byvoegings gepubliseer vir integrasie met VSCode- en TextMate-redigeerders, sowel as die implementering van die ISL (Interactive SmartLog) koppelvlak en bediener.
Bron: opennet.ru