Facebook (забаронены ў РФ) апублікаваў сістэму кіравання зыходнымі тэкстамі Sapling, якая прымяняецца пры распрацоўцы ўнутраных праектаў кампаніі. Сістэма нацэлена на прадастаўленне звыклага інтэрфейсу кіравання версіямі, які можа маштабавацца для вельмі буйных рэпазітароў, якія ахопліваюць дзясяткі мільёнаў файлаў, коммітаў і галінак. Код кліента напісаны на мовах Python і Rust, і адчынены пад ліцэнзіяй GPLv2.
Асобна распрацавана серверная частка для эфектыўнай выдаленай працы з рэпазітарамі і віртуальная файлавая сістэма для працы з лакальным зрэзам часткі рэпазітара як з поўным рэпазітаром (распрацоўнік бачыць увесь рэпазітар, але на лакальную сістэму капіююцца толькі запатрабаваныя дадзеныя, да якіх ажыццяўляюцца звароты). Выкарыстоўваны ў інфраструктуры Facebook код дадзеных кампанентаў пакуль не адчынены, але кампанія абяцала апублікаваць яго ў будучыні. Тым не менш, у наш час у рэпазітары Sapling ужо можна знайсці прататыпы сервера Mononoke (на мове Rust) і VFS EdenFS (на З++). Дадзеныя кампаненты з'яўляюцца не абавязковымі і для працы дастаткова кліента Sapling, які падтрымлівае кланаванне Git-рэпазітароў, узаемадзеянне з серверамі на базе Git LFS і працу з git-хостынгамі, такімі як GitHub.
Асноўная ідэя сістэмы ў тым, што пры ўзаемадзеянні са спецыяльнай сервернай часткай, якая забяспечвае захоўванне рэпазітара, усе аперацыі маштабуюцца ў залежнасці ад колькасці файлаў, рэальна выкарыстоўваных у кодзе, над якім працуе распрацоўнік, і не залежаць ад агульнага памеру ўсяго рэпазітара. Напрыклад, распрацоўшчык можа выкарыстоўваць толькі невялікую порцыю кода з вельмі вялікага рэпазітара і на яго сістэму будзе перанесена толькі гэтая невялікая частка, а не ўвесь рэпазітар. Запаўненне працоўнага каталога вырабляецца дынамічна, па меры звароту да файлаў з рэпазітара, што з аднаго боку дазваляе істотна паскорыць працу са сваёй часткай кода, але з іншага боку прыводзіць да запаволення пры першым звароце да новых файлаў і патрабуе наяўнасці сталага доступу да сеткі (асобна прадугледжаны і offline-рэжым падрыхтоўкі комітаў).
Акрамя адаптыўнай загрузкі дадзеных у Sapling таксама рэалізаваны і аптымізацыі, накіраваныя на скарачэнне загрузкі інфармацыі з гісторыяй змен (напрыклад, 3/4 дадзеных у рэпазітары з ядром Linux прыходзіцца на гісторыю змен). Для эфектыўнай працы з гісторыяй змен, злучаныя з ёй дадзеных захоўваюцца ў сегментаваным паданні, які дазваляе загружаць з сервера асобныя часткі графа коммітаў. Кліент можа запытаць у сервера інфармацыю аб сувязі некалькіх коммітаў і загрузіць толькі неабходную частку графа.
Праект развіваецца на працягу апошніх 10 гадоў і быў створаны для вырашэння праблем пры арганізацыі доступу да вельмі буйных маналітных рэпазітароў з адной master-галінкай, у якіх практыкавалася прымяненне аперацыі "rebase" замест "merge". У той час адкрытыя рашэнні для працы з падобнымі рэпазітарамі адсутнічалі і інжынеры Facebook вырашылі стварыць новую сістэму кіравання версіямі, якая адпавядае патрэбам кампаніі, замест драбнення праектаў на дробныя рэпазітары, што прывяло б да ўскладнення кіравання залежнасцямі (у свой час для вырашэння аналагічнай праблемы кампанія Microsoft стварыла праслойку GVFS). Першапачаткова ў Facebook ужывалася сістэма Mercurial і праект Sapling на першым этапе развіваўся як дадатак да Mercurial. З часам сістэма трансфармавалася ў самастойны праект са сваім пратаколам, фарматам захоўвання і алгарытмамі, які таксама быў пашыраны магчымасцю ўзаемадзеяння з Git-рэпазітарамі.
Для працы прапануецца ўтыліта каманднага радка "sl", якая рэалізуе тыпавыя канцэпцыі, працоўныя працэсы і інтэрфейс, звыклыя для распрацоўнікаў, знаёмых з Git і Mercurial. Тэрміналогія і каманды ў Sapling крыху адрозніваюцца ад Git і больш блізкія да Mercurial. Напрыклад, замест галінак выкарыстоўваюцца "закладкі" (названыя галінкі не падтрымліваюцца), па змаўчанні пры выкананні clone/pull загружаецца не ўвесь рэпазітар, а толькі асноўная галінка, адсутнічае папярэдняя маркіроўка комітаў (staging area), замест "git fetch" прымяняецца каманда "sl pull", замест "git pull" - "sl pull -rebase", замест "git checkout COMMIT" - "sl goto COMMIT", замест "git reflog" - "sl journal", для адмены змены замест "git checkout - FILE" паказваецца "sl revert FILE", а для ідэнтыфікацыі галінкі "HEAD" ужываецца ".". Але ў цэлым, агульныя канцэпцыі галінак і аперацый clone/pull/push/commit/rebase захоўваюцца.
З дадатковых магчымасцяў інструментара Sapling вылучаецца падтрымка "разумнага лога" (smartlog), які дазваляе наглядна ацаніць стан свайго рэпазітара, вылучыць найбольш важную інфармацыю і адсеяць другарадныя дэталі. Напрыклад, пры запуску ўтыліты sl без аргументаў на экран выводзяцца толькі ўласныя лакальныя змены (чужыя згортваюцца), паказваецца стан вонкавых галінак, змененыя файлы і новыя версіі комітаў. Дадаткова прапануецца інтэрактыўны web-інтэрфейс, які дае магчымасць хутка перамяшчацца па разумным логу, дрэве змен і коммітам.
Іншым прыкметным паляпшэннем у Sapling з'яўляецца спрашчэнне працэсу выпраўлення і разбору памылак, і вяртанні да мінулага стану. Напрыклад, для адкату шматлікіх аперацый прапануюцца каманды "sl undo", "sl redo", "sl uncommit" і "sl unamend", для часовага ўтойвання коммітаў каманды "sl hide" і "sl unhide", а для інтэрактыўнай навігацыі па старых станах і вяртанню да ўказанай кропкі каманда "sl undo -i command". У Sapling таксама падтрымліваецца канцэпцыя стэка коммітаў, якая дазваляе арганізаваць пакрокавае рэцэнзаванне праз драбненне складанай функцыянальнасці на набор з невялікіх і больш зразумелых інкрыментальных змен (ад базавага каркаса да гатовай функцыі).
Для Sapling падрыхтавана некалькі дадаткаў, сярод якіх інтэрфейс для рэцэнзавання змен ReviewStack (код пад GPLv2), які дазваляе апрацоўваць pull-запыты на GitHub і выкарыстоўваць сцяковае ўяўленне змен. Акрамя таго, апублікаваны дадаткі для інтэграцыі з рэдактарамі VSCode і TextMate, а таксама рэалізацыя інтэрфейсу і сервера ISL (Interactive SmartLog).
Крыніца: opennet.ru