Facebook (malpermesita en la Rusa Federacio) publikigis la Sapling fontkontrolsistemon, uzitan en la disvolviĝo de internaj firmaaj projektoj. La sistemo celas disponigi konatan version-kontrolinterfacon kiu povas skali por tre grandaj deponejoj enhavantaj dekojn da milionoj da dosieroj, kommits kaj branĉoj. La klientokodo estas skribita en Python kaj Rust, kaj estas malfermita sub la permesilo GPLv2.
Servila parto estis evoluigita aparte por efika fora laboro kun deponejoj kaj virtuala dosiersistemo por labori kun loka tranĉaĵo de parto de la deponejo kiel kompleta deponejo (la programisto vidas la tutan deponejon, sed nur la bezonatajn datumojn kiuj estas aliritaj. estas kopiita al la loka sistemo). La kodo por ĉi tiuj komponantoj uzataj en la infrastrukturo de Facebook ankoraŭ ne estas malfermita, sed la kompanio promesis publikigi ĝin estonte. Tamen nuntempe en la deponejo Sapling vi jam povas trovi prototipojn de la servilo Mononoke (en Rust) kaj VFS EdenFS (en C++). Ĉi tiuj komponantoj estas laŭvolaj kaj la kliento Sapling sufiĉas por funkcii, kiu subtenas klonadon de Git-deponejoj, interagante kun serviloj bazitaj sur Git LFS kaj laborante kun git-gastigaj retejoj kiel GitHub.
La ĉefa ideo de la sistemo estas, ke interagante kun speciala servila parto, kiu provizas stokadon de la deponejo, ĉiuj operacioj estas skalitaj depende de la nombro da dosieroj efektive uzataj en la kodo, pri kiu la programisto laboras, kaj ne dependas de. la tuta grandeco de la tuta deponejo. Ekzemple, programisto povas uzi nur malgrandan parton de kodo de tre granda deponejo kaj nur tiu malgranda parto estos migrita al sia sistemo, ne la tuta deponejo. La labordosierujo estas plenigita dinamike kiam dosieroj de la deponejo estas aliritaj, kio, unuflanke, ebligas al vi signife akceli laboron kun via parto de la kodo, sed aliflanke kondukas al malrapidiĝo kiam vi aliras novajn dosierojn por la kodo. unuafoje kaj postulas konstantan aliron al la reto (aparte provizita kaj eksterreta reĝimo por prepari komitaĵojn).
Krom adapta ŝarĝo de datumoj, Sapling ankaŭ efektivigas optimumigojn celantajn redukti la ŝarĝon de informoj kun la historio de ŝanĝoj (ekzemple, 3/4 el la datumoj en deponejo kun la Linukso-kerno estas la historio de ŝanĝoj). Por efike labori kun la historio de ŝanĝoj, la datumoj asociitaj kun ĝi estas stokitaj en segmentita reprezento, kiu ebligas al vi elŝuti individuajn partojn de la kommit-grafo de la servilo. La kliento povas peti informojn de la servilo pri la rilato inter pluraj komitaĵoj kaj elŝuti nur la necesan parton de la grafikaĵo.
La projekto disvolviĝis dum la pasintaj 10 jaroj kaj estis kreita por solvi problemojn dum organizado de aliro al tre grandaj monolitaj deponejoj kun unu majstra branĉo, kiu uzis la operacion "rebaze" anstataŭ "kunfandi". En tiu tempo, ekzistis neniuj malfermaj solvoj por labori kun tiaj deponejoj, kaj Facebook-inĝenieroj decidis krei novan version-kontrolsistemon kiu renkontus la bezonojn de la firmao, anstataŭe de dividi projektojn en malgrandajn deponejojn, kio kondukus al la komplekseco de administrado de dependeco (foje, por solvi similan problemon, Microsoft kreis GVFS-tavolon). Komence, Facebook uzis la Mercurial-sistemon kaj la Sapling-projekton ĉe la unua etapo evoluigita kiel aldono al Mercurial. Kun la tempo, la sistemo transformiĝis en sendependan projekton kun sia propra protokolo, stokadformato kaj algoritmoj, kiu ankaŭ estis vastigita kun la kapablo interagi kun Git-deponejoj.
Por laboro, komandlinia utileco "sl" estas ofertita, kiu efektivigas tipajn konceptojn, laborfluojn kaj interfacon konatan al programistoj konataj kun Git kaj Mercurial. La terminologio kaj komandoj en Sapling estas iomete malsamaj de Git kaj estas pli proksimaj al Mercurial. Ekzemple, anstataŭ branĉoj, "legosignoj" estas uzataj (nomitaj branĉoj ne estas subtenataj), defaŭlte, dum ekzekuto de klono/tiro, ne la tuta deponejo estas ŝarĝita, sed nur la ĉefa branĉo, ne estas antaŭsigna markado de kommits ( staging areo), anstataŭ "git fetch" la komando "sl" estas uzata pull", anstataŭ "git pull" - "sl pull -rebase", anstataŭ "git checkout COMMIT" - "sl goto COMMIT", anstataŭe de "git reflog" - "sl journal", por nuligi ŝanĝon anstataŭ "git checkout - FILE" "sl revert FILE" estas specifita, kaj "." estas uzata por identigi la branĉon "HEAD". Sed ĝenerale, la ĝeneralaj konceptoj de branĉoj kaj klono/tiro/puŝo/commit/rebase operacioj estas konservitaj.
Inter la aldonaj funkcioj de la ilaro Sapling elstaras subteno por "smartlog", kiu ebligas al vi vide taksi la staton de via deponejo, reliefigi la plej gravajn informojn kaj filtri negravajn detalojn. Ekzemple, kiam vi rulas la sl-ilaĵon sen argumentoj, nur viaj propraj lokaj ŝanĝoj estas montrataj sur la ekrano (aliaj estas minimumigitaj), la stato de eksteraj branĉoj, ŝanĝitaj dosieroj kaj novaj versioj de kommits estas montritaj. Aldone, interaga TTT-interfaco estas ofertita, kiu ebligas rapide navigi tra la inteligenta protokolo, ŝanĝi arbon kaj transigi.
Alia rimarkinda plibonigo en Sapling estas, ke ĝi faciligas ripari kaj solvi erarojn kaj reveni al antaŭa stato. Ekzemple, la komandoj "sl malfari", "sl redo", "sl uncommit" kaj "sl unamend" estas ofertitaj por retrorigi multajn operaciojn; la komandoj "sl hide" kaj "sl unhide" estas uzataj por provizore kaŝi kommitaĵojn; kaj por interaga navigado tra malnovaj ŝtatoj kaj reveni al la specifita punkto kun la komando "sl malfari -i komando". Sapling ankaŭ subtenas la koncepton de kommit-stako, kiu ebligas al vi organizi paŝon post paŝo recenzojn rompante kompleksajn funkciojn en aron de pli malgrandaj, pli kompreneblaj pliigaj ŝanĝoj (de baza kadro ĝis finita funkcio).
Pluraj aldonoj estis preparitaj por Sapling, inkluzive de la interfaco ReviewStack por revizii ŝanĝojn (kodo sub GPLv2), kiu permesas vin prilabori tirpetojn en GitHub kaj uzi stakan vidon de ŝanĝoj. Krome, aldonoj estis publikigitaj por integriĝo kun VSCode kaj TextMate-redaktistoj, same kiel la efektivigo de la ISL (Interactive SmartLog) interfaco kaj servilo.
fonto: opennet.ru