Sapling subliniază ușurința de utilizare în timp ce scalarea la cele mai mari depozite din lume.
Facebook a fost dezvăluit printr-o postare pe blog sistemul de management al codului sursă Puiet utilizate în dezvoltarea proiectelor interne ale companiei. Sistemul își propune să ofere o interfață de control al versiunilor familiar care se poate scala la depozite foarte mari, care acoperă zeci de milioane de fișiere, comite și ramuri.
Ideea principală a sistemului este că, prin interacțiunea cu o parte specială a serverului care oferă depozitare, toate operațiunile sunt scalate în funcție de numărul de fișiere utilizate efectiv în codul la care lucrează dezvoltatorul și nu depind de dimensiunea totală a întregului depozit.
De exemplu, un dezvoltator poate folosi doar o mică parte de cod dintr-un depozit foarte mare și numai această mică parte, și nu întregul depozit, va fi transferat în sistemul său. Directorul de lucru este umplut dinamic, pe măsură ce sunt accesate fișierele de depozit, ceea ce, pe de o parte, vă permite să accelerați semnificativ lucrul cu partea dvs. de cod, dar, pe de altă parte, îl încetinește atunci când îl accesați pentru prima dată la fișiere noi și necesită acces constant la rețea (furnizat separat și modul de pregătire offline-commit).
Pe lângă încărcarea adaptivă a datelor, Sapling implementează, de asemenea, optimizări menite să reducă încărcarea de informații cu un istoric al modificărilor. (de exemplu, 3/4 din datele dintr-un depozit cu nucleul Linux reprezintă istoricul modificărilor).
Pentru a lucra eficient cu istoricul modificărilor, datele asociate cu acesta sunt stocate într-o vizualizare segmentată, care vă permite să descărcați părți separate ale graficului de comitere de pe server. Clientul poate cere serverului informații despre relația mai multor confirmări și poate descărca doar partea necesară a graficului.
Proiectul a fost în dezvoltare în ultimii 10 ani și a fost creat pentru a rezolva probleme la accesarea depozitelor monolitice foarte mari cu o ramură master, unde se practica practica folosirii operației „rebase” în loc de „merge”.
La acel moment, nu existau soluții deschise pentru lucrul cu astfel de depozite, iar inginerii Facebook au decis să creeze un nou sistem de control al versiunilor care să răspundă nevoilor companiei, mai degrabă decât să împartă proiectele în depozite mici, ceea ce ar duce la un management mai complicat al dependenței ( la un moment dat, pentru a rezolva o problemă similară, Microsoft a creat stratul GVFS).
Inițial, Facebook a folosit sistemul Mercurial iar proiectul Sapling a fost dezvoltat inițial ca o completare la Mercurial. Cu timpul, sistemul a devenit un proiect independent cu propriul protocol, format de stocare și algoritmi, care a fost, de asemenea, extins cu capacitatea de a interacționa cu depozitele Git.
Pentru munca, este propus utilitarul de linie de comandă „sl”, care implementează concepte tipice, fluxuri de lucru și o interfață familiară dezvoltatorilor familiarizați cu Git și Mercurial. Terminologia și comenzile din Sapling sunt ușor diferite de Git și mai apropiate de Mercurial.
Printre caracteristicile suplimentare de Sapling, evidențiază suport pentru „înregistrare inteligentă” (smartlog), care vă permite să evaluați vizual starea depozitului dvs. evidențiați cele mai importante informații și filtrați detaliile minore. De exemplu, atunci când rulați utilitarul sl fără argumente, sunt afișate doar propriile modificări locale (cele străine sunt restrânse), se afișează starea ramurilor externe, fișierele modificate și versiunile noi ale commit-urilor. În plus, este furnizată o interfață web interactivă pentru navigarea rapidă prin jurnalul inteligent, arborele de modificare și comiterea.
O altă îmbunătățire notabilă în Sapling este aceea face mult mai ușor procesul de remediere și analiză a erorilor și revenirea la o stare anterioară. De exemplu, comenzile „sl undo”, „sl redo”, „sl uncommit” și „sl unmend” sunt sugerate pentru a inversa multe operațiuni, „sl hide” și „sl unhide” pentru ascunderea temporară a comiterilor și pentru navigarea interactivă. afirmă Sapling, de asemenea, susține conceptul de stivă de comitere, care vă permite să organizați o revizuire pas cu pas prin defalcarea funcționalității complexe într-un set incremental mai mic și mai ușor de înțeles de modificări (de la un cadru de bază la o caracteristică finală).
Separat, o parte de server a fost dezvoltată pentru lucrul eficient la distanță cu depozite și un sistem de fișiere virtual pentru a lucra cu o porțiune locală a unei părți a depozitului ca și cum ar fi un depozit complet (dezvoltatorul vede întregul depozit, dar numai datele solicitate sunt copiate în sistemul local, care este accesat).
Codul pentru aceste componente folosite în infrastructura Facebook nu este încă deschis, dar compania a promis că îl va lansa în viitor. Cu toate acestea, prototipurile serverului Mononoke (în Rust) și VFS EdenFS (în C++) pot fi găsite deja în depozitul Sapling. Aceste componente sunt opționale și este suficient pentru a lucra cu clientul Sapling, care acceptă clonarea depozitelor Git, interacțiunea cu serverele bazate pe Git LFS și lucrul cu gazde git precum GitHub.
Mai multe plugin-uri au fost pregătite pentru Sapling, inclusiv interfața ReviewStack pentru revizuirea modificărilor (cod sub GPLv2), care vă permite să procesați solicitări de extragere pe GitHub și să utilizați o vizualizare a stivei de modificări.
Daca esti interesat sa afli mai multe despre el, poti consulta detaliile În următorul link.