Facebook (Venäjän federaatiossa kielletty) julkaisi Sapling-lähteenhallintajärjestelmän, jota käytettiin yrityksen sisäisten projektien kehittämisessä. Järjestelmän tavoitteena on tarjota tuttu versionhallintaliittymä, joka skaalautuu erittäin suuriin arkistoihin, jotka kattavat kymmeniä miljoonia tiedostoja, sitoumuksia ja haarautumisia. Asiakaskoodi on kirjoitettu Pythonilla ja Rustilla, ja se on avoinna GPLv2-lisenssillä.
Palvelinosa on kehitetty erikseen tehokkaaseen etätyöskentelyyn tietovarastojen kanssa ja virtuaalinen tiedostojärjestelmä arkiston osan paikallisen osion kanssa työskentelyyn täydellisenä arkistona (kehittäjä näkee koko arkiston, mutta vain tarvittavat tiedot, joihin pääsee käsiksi kopioidaan paikalliseen järjestelmään). Näiden Facebookin infrastruktuurissa käytettyjen komponenttien koodi ei ole vielä auki, mutta yhtiö on luvannut julkaista sen tulevaisuudessa. Tällä hetkellä Sapling-arkistosta löytyy kuitenkin jo prototyyppejä Mononoke-palvelimesta (Rustissa) ja VFS EdenFS:stä (C++:ssa). Nämä komponentit ovat valinnaisia ja Sapling-asiakasohjelma riittää toimimaan, mikä tukee Git-tietovarastojen kloonausta, vuorovaikutusta Git LFS:ään perustuvien palvelimien kanssa ja työskentelyä Git-isännöintisivustojen, kuten GitHubin, kanssa.
Järjestelmän perusideana on, että kun ollaan vuorovaikutuksessa erityisen palvelinosan kanssa, joka tarjoaa arkiston tallennusta, kaikki toiminnot skaalataan riippuen siitä, kuinka monta tiedostoa todella käytetään kehittäjän työskentelemässä koodissa, eivätkä ne ole riippuvaisia koko arkiston kokonaiskoko. Esimerkiksi kehittäjä voi käyttää vain pientä osaa koodista erittäin suuresta tietovarastosta, ja vain tämä pieni osa siirretään hänen järjestelmään, ei koko tietovarastoa. Työhakemisto täyttyy dynaamisesti, kun arkiston tiedostoja käytetään, mikä toisaalta mahdollistaa huomattavasti työskentelyn nopeuttamisen oman koodin osan kanssa, mutta toisaalta hidastaa uusien tiedostojen käyttöä ensimmäistä kertaa ja vaatii jatkuvan pääsyn verkkoon (erikseen toimitettu ja offline-tila sitoumusten valmistelua varten).
Mukautuvan tiedonlatauksen lisäksi Sapling toteuttaa myös optimointeja, joilla pyritään vähentämään tiedon latautumista muutoshistorian mukaan (esim. 3/4 Linux-ytimen arkistossa olevista tiedoista on muutoshistoriaa). Jotta muutoshistoriaa voidaan käsitellä tehokkaasti, siihen liittyvät tiedot tallennetaan segmentoituun esitykseen, jonka avulla voit ladata yksittäisiä toimituskaavion osia palvelimelta. Asiakas voi pyytää palvelimelta tietoja useiden toimitusten välisestä suhteesta ja ladata vain tarvittavan osan kaaviosta.
Projektia on kehitetty viimeisen 10 vuoden aikana, ja se luotiin ratkaisemaan ongelmia, kun järjestettiin pääsy erittäin suuriin monoliittisiin arkistoihin yhdellä päähaaralla, joka käytti "rebase"-toimintoa "yhdistämisen" sijaan. Tuolloin ei ollut avoimia ratkaisuja työskennellä tällaisten arkiston kanssa, ja Facebookin insinöörit päättivät luoda uuden versionhallintajärjestelmän, joka vastaisi yrityksen tarpeita, sen sijaan että jakaisivat projekteja pieniin arkistoihin, mikä johtaisi monimutkaisuuteen. riippuvuuden hallinta (Microsoft loi aikoinaan GVFS-kerroksen ratkaistakseen samanlaisen ongelman). Aluksi Facebook käytti Mercurial-järjestelmää ja ensimmäisessä vaiheessa Mercurialin lisäyksenä kehitettyä Sapling-projektia. Ajan myötä järjestelmä muuttui itsenäiseksi projektiksi omalla protokollalla, tallennusmuodolla ja algoritmeilla, jota myös laajennettiin mahdollisuudella toimia vuorovaikutuksessa Git-varastojen kanssa.
Työhön tarjotaan komentorivityökalu ”sl”, joka toteuttaa tyypillisiä konsepteja, työnkulkuja ja Gitin ja Mercurialin tunteville kehittäjille tutun käyttöliittymän. Saplingin terminologia ja komennot eroavat hieman Gitistä ja ovat lähempänä Mercurialia. Esimerkiksi haarojen sijasta käytetään "kirjanmerkkejä" (nimettyjä haaroja ei tueta), oletusarvoisesti kloonausta/vetoa suoritettaessa ei ladata koko arkistoa, vaan vain päähaara, toimitusten alustavaa merkintää ei ole ( lavastusalue), "git fetch" sijaan käytetään "sl"-komentoa pull", "git pull" sijaan - "sl pull -rebase", "git checkout COMMIT" sijaan - "sl goto COMMIT" "git reflog" - "sl journal", jos haluat peruuttaa muutoksen "git checkout - FILE" sijaan "sl revert FILE" on määritetty, ja "." käytetään tunnistamaan "HEAD"-haara. Mutta yleisesti ottaen yleiset käsitteet haaroista ja kloonaa/pull/push/commit/rebase-operaatioista säilyvät.
Sapling-työkalupakin lisäominaisuuksista erottuu "smartlog"-tuki, jonka avulla voit arvioida visuaalisesti arkistosi tilaa, korostaa tärkeimmät tiedot ja suodattaa pois merkityksettömät yksityiskohdat. Esimerkiksi kun suoritat sl-apuohjelman ilman argumentteja, vain omat paikalliset muutokset näkyvät näytöllä (muut on minimoitu), ulkoisten haarojen tila, muuttuneet tiedostot ja uudet toimitusversiot näytetään. Lisäksi tarjolla on interaktiivinen verkkokäyttöliittymä, jonka avulla on mahdollista navigoida nopeasti älylokin läpi, muuttaa puuta ja tehdä sitoumuksia.
Toinen merkittävä parannus Saplingissa on, että se helpottaa virheiden korjaamista ja ratkaisemista sekä paluuta aiempaan tilaan. Esimerkiksi komentoja "sl undo", "sl redo", "sl uncommit" ja "sl unamend" tarjotaan peruuttamaan monia toimintoja; komentoja "sl hide" ja "sl unhide" käytetään tilapäisesti piilottamaan sitoumukset; ja interaktiivista navigointia vanhojen tilojen läpi ja palaa määritettyyn pisteeseen komennolla "sl undo -i -komento". Sapling tukee myös toimituspinon käsitettä, jonka avulla voit järjestää vaiheittaiset tarkastelut jakamalla monimutkaiset toiminnot pienemmiksi, ymmärrettävämmiksi lisämuutoksiksi (peruskehyksestä valmiiksi funktioksi).
Saplingiin on tehty useita lisäyksiä, mukaan lukien ReviewStack-käyttöliittymä muutosten tarkistamiseen (koodi GPLv2:ssa), jonka avulla voit käsitellä vetopyyntöjä GitHubissa ja käyttää muutosten pinonäkymää. Lisäksi on julkaistu lisäyksiä VSCode- ja TextMate-editorien integrointiin sekä ISL (Interactive SmartLog) -rajapinnan ja palvelimen toteuttamiseen.
Lähde: opennet.ru