Facebook (Krievijā aizliegts) publicējis uzņēmuma iekšējo projektu izstrādē izmantoto pirmkoda pārvaldības sistēmu Sapling. Sistēmas mērķis ir nodrošināt pazīstamu versiju interfeisu, kas var tikt mērogots līdz ļoti lielām krātuvēm, kas aptver desmitiem miljonu failu, saistību un atzarojumu. Klienta kods ir rakstīts Python un Rust, un tas ir atvērts saskaņā ar GPLv2 licenci.
Atsevišķi tika izstrādāta servera daļa efektīvam attālinātam darbam ar krātuvēm un virtuālā failu sistēma darbam ar repozitorija daļas lokālo daļu kā ar pilnu repozitoriju (izstrādātājs redz visu repozitoriju, bet tiek kopēti tikai pieprasītie dati vietējai sistēmai, kurām tiek piekļūts). Šo Facebook infrastruktūrā izmantoto komponentu kods vēl nav atklāts, taču uzņēmums solīja to publicēt nākotnē. Taču Mononoke servera (Rust valodā) un VFS EdenFS (C++ valodā) prototipus jau var atrast Sapling repozitorijā. Šie komponenti nav obligāti, un darbam pietiek ar Sapling klientu, kas atbalsta Git repozitoriju klonēšanu, mijiedarbību ar serveriem, kuru pamatā ir Git LFS, un darbu ar Git resursdatoriem, piemēram, GitHub.
Sistēmas galvenā ideja ir tāda, ka, mijiedarbojoties ar īpašu servera daļu, kas nodrošina repozitorija glabāšanu, visas darbības tiek mērogotas atkarībā no failu skaita, kas faktiski tiek izmantoti kodā, ar kuru izstrādātājs strādā, un nav atkarīgas no visas repozitorija kopējais lielums. Piemēram, izstrādātājs var izmantot tikai nelielu koda daļu no ļoti liela repozitorija, un tikai šī mazā daļa, nevis visa repozitorija, tiks pārsūtīta uz viņa sistēmu. Darba direktorijs tiek aizpildīts dinamiski, jo tiek piekļūti faili no repozitorija, kas, no vienas puses, ļauj ievērojami paātrināt darbu ar savu koda daļu, bet, no otras puses, noved pie palēninājuma, kad pirmo reizi piekļūstat jauni faili un nepieciešama pastāvīga piekļuve tīklam (atsevišķi nodrošināts un bezsaistes režīms saistību sagatavošanai).
Papildus adaptīvajai datu ielādei Sapling ievieš arī optimizācijas, kuru mērķis ir samazināt informācijas ielādi ar izmaiņu vēsturi (piemēram, 3/4 datu repozitorijā ar Linux kodolu ir izmaiņu vēsture). Lai efektīvi strādātu ar izmaiņu vēsturi, ar to saistītie dati tiek glabāti segmentētā skatā, kas ļauj no servera lejupielādēt atsevišķas izpildes diagrammas daļas. Klients var lūgt serverim informāciju par vairāku apņemšanos saistību un lejupielādēt tikai nepieciešamo grafika daļu.
Projekts ir izstrādāts pēdējo 10 gadu laikā un radīts, lai risinātu problēmas, organizējot piekļuvi ļoti lielām monolītām krātuvēm ar vienu galveno atzaru, kurā tika praktizēta "apvienojuma" vietā izmantot operāciju "rebase". Tolaik nebija atvērtu risinājumu darbam ar šādiem repozitorijiem, un Facebook inženieri nolēma izveidot jaunu, uzņēmuma vajadzībām atbilstošu versiju kontroles sistēmu, nevis sadalīt projektus mazos krātuvēs, kas radītu sarežģītāku atkarību pārvaldību. (vienā reizē, lai atrisinātu līdzīgu problēmu, Microsoft izveidoja GVFS slāni). Sākotnēji Facebook izmantoja Mercurial sistēmu, un projekts Sapling sākotnēji tika izstrādāts kā Mercurial papildinājums. Laika gaitā sistēma pārtapa par neatkarīgu projektu ar savu protokolu, uzglabāšanas formātu un algoritmiem, kas tika paplašināts arī ar iespēju mijiedarboties ar Git krātuvēm.
Darbam tiek piedāvāta komandrindas utilīta “sl”, kas ievieš tipiskas koncepcijas, darbplūsmas un saskarni, kas pazīstama izstrādātājiem, kuri pārzina Git un Mercurial. Sapling terminoloģija un komandas nedaudz atšķiras no Git un ir tuvākas Mercurial. Piemēram, zaru vietā tiek izmantotas “grāmatzīmes” (nosauktās filiāles netiek atbalstītas), pēc noklusējuma, veicot klonēšanu / izvilkšanu, netiek ielādēta visa repozitorija, bet tikai galvenā filiāle, nav veikta iepriekšēja saistību marķēšana ( inscenēšanas apgabals), "git fetch" vietā tiek izmantota komanda "sl" pull", "git pull" vietā - "sl pull --rebase", "git checkout COMMIT" vietā - "sl goto COMMIT". no "git reflog" - "sl journal", lai atsauktu izmaiņas, nevis "git checkout - FILE", ir norādīts "sl revert FILE", un "." tiek izmantots, lai identificētu filiāli "HEAD". Bet kopumā tiek saglabāti vispārīgie jēdzieni par atzariem un operācijām clone/pull/push/commit/rebase.
Starp Sapling rīku komplekta papildu funkcijām izceļas “viedā žurnāla” (smartlog) atbalsts, kas ļauj vizuāli novērtēt repozitorija stāvokli, izcelt svarīgāko informāciju un filtrēt mazākās detaļas. Piemēram, palaižot utilītu sl bez argumentiem, tiek parādītas tikai jūsu vietējās izmaiņas (svešās tiek sakļautas), tiek parādīts ārējo zaru statuss, mainītie faili un jaunas izpildes versijas. Papildus tiek piedāvāts interaktīvs tīmekļa interfeiss, kas ļauj ātri pārvietoties viedajā žurnālā, mainīt koku un veikt saistības.
Vēl viens ievērojams Sapling uzlabojums ir kļūdu labošanas un parsēšanas procesa vienkāršošana un atgriešanās iepriekšējā stāvoklī. Piemēram, komandas "sl undo", "sl redo", "sl uncommit" un "sl unamend" tiek piedāvātas, lai atsauktu daudzas darbības, komandas "sl hide" un "sl unhide", lai īslaicīgi paslēptu saistības, un interaktīva navigācija caur vecos stāvokļus un atgrieziet norādītajā punktā komandu "sl undo -i komanda". Sapling atbalsta arī commit steck koncepciju, kas ļauj organizēt soli pa solim pārskatīšanu, sadalot sarežģīto funkcionalitāti mazāku un saprotamāku pakāpenisku izmaiņu komplektā (no pamata ietvara līdz gatavai funkcijai).
Programmai Sapling ir sagatavoti vairāki papildinājumi, tostarp ReviewStack saskarne izmaiņu pārskatīšanai (kods saskaņā ar GPLv2), kas ļauj apstrādāt izvilkšanas pieprasījumus vietnē GitHub un izmantot izmaiņu steka skatu. Papildus ir publicēti papildinājumi integrācijai ar VSCode un TextMate redaktoriem, kā arī ISL (Interactive SmartLog) interfeisa un servera ieviešanai.
Avots: opennet.ru