Sapling kładzie nacisk na łatwość użytkowania podczas skalowania do największych światowych repozytoriów.
Prezentacja Facebooka poprzez wpis na blogu system zarządzania kodem źródłowym Drzewko wykorzystywane w rozwoju wewnętrznych projektów firmy. System ma na celu zapewnienie interfejsu kontroli wersji znajomy, który można skalować do bardzo dużych repozytoriów obejmujących dziesiątki milionów plików, zatwierdzeń i gałęzi.
Główną ideą systemu jest to, że poprzez interakcję ze specjalną częścią serwera, która zapewnia przechowywanie repozytorium, skalowanie wszystkich operacji na podstawie liczby plików faktycznie używane w kodzie, nad którym pracuje programista, i nie są zależne od całkowitego rozmiaru całego repozytorium.
Na przykład programista może użyć tylko niewielkiej części kodu z bardzo dużego repozytorium i tylko ta niewielka część, a nie całe repozytorium, zostanie przeniesiona do jego systemu. Katalog roboczy jest wypełniany dynamicznie w miarę uzyskiwania dostępu do plików repozytorium, co z jednej strony pozwala znacznie przyspieszyć pracę z Twoją częścią kodu, ale z drugiej spowalnia ją, gdy uzyskujesz do niej dostęp przez pierwszy raz do nowych plików i wymaga stałego dostępu do sieci (dostarczany oddzielnie i tryb przygotowania do zatwierdzenia offline).
Oprócz adaptacyjnego ładowania danych, Sapling wdraża również optymalizacje mające na celu zmniejszenie obciążenia informacyjnego historią zmian. (na przykład 3/4 danych w repozytorium z jądrem Linuksa to historia zmian).
Aby efektywnie pracować z historią zmian, dane z nią związane są przechowywane w widoku segmentowym, co umożliwia pobieranie z serwera poszczególnych części grafu zatwierdzeń. Klient może poprosić serwer o informację o powiązaniu kilku potwierdzeń i pobrać tylko niezbędną część wykresu.
Projekt był rozwijany przez ostatnie 10 lat i został stworzony w celu rozwiązywania problemów podczas uzyskiwania dostępu do bardzo dużych monolitycznych repozytoriów z gałęzią główną, gdzie praktykowano praktykę używania operacji „rebase” zamiast „merge”.
W tamtym czasie nie było otwartych rozwiązań do pracy z takimi repozytoriami, a inżynierowie Facebooka postanowili stworzyć nowy system kontroli wersji, który odpowiadałby potrzebom firmy, zamiast dzielić projekty na małe repozytoria, co prowadziłoby do bardziej skomplikowanego zarządzania zależnościami ( kiedyś, aby rozwiązać podobny problem, Microsoft stworzył warstwę GVFS).
Początkowo Facebook korzystał z systemu Mercurial a projekt Sapling był początkowo rozwijany jako dodatek do Mercurial. Z czasem system stał się samodzielnym projektem z własnym protokołem, formatem przechowywania i algorytmami, który został również rozszerzony o możliwość interakcji z repozytoriami Git.
Do pracy, proponowane jest narzędzie wiersza poleceń „sl”, który implementuje typowe koncepcje, przepływy pracy i interfejs znany programistom znającym Git i Mercurial. Terminologia i polecenia w Sapling są nieco inne niż w Git i bliższe Mercurialowi.
Wśród dodatkowych funkcji Sapling, podkreśla obsługa „inteligentnej rejestracji” (smartlog), który pozwala wizualnie ocenić stan Twojego repozytorium, podkreśl najważniejsze informacje i odfiltruj drobne szczegóły. Na przykład, gdy uruchamiasz narzędzie sl bez argumentów, wyświetlane są tylko twoje własne zmiany lokalne (obce są zwinięte), wyświetlany jest status gałęzi zewnętrznych, zmienione pliki i nowe wersje zatwierdzeń. Ponadto dostępny jest interaktywny interfejs sieciowy umożliwiający szybką nawigację po inteligentnym dzienniku, drzewie zmian i zatwierdzeniach.
Kolejną godną uwagi poprawą w Sapling jest to znacznie ułatwia proces poprawiania i analizowania błędów oraz przywracania poprzedniego stanu. Na przykład polecenia „sl undo”, „sl redo”, „sl uncommit” i „sl unmend” sugerowane są do cofania wielu operacji, „sl hide” i „sl unhide” do tymczasowego ukrywania zatwierdzeń i interaktywnej nawigacji. stwierdza, że Sapling obsługuje również koncepcję stosu zatwierdzeń, która pozwala organizować przegląd krok po kroku, dzieląc złożoną funkcjonalność na mniejsze, bardziej zrozumiałe przyrostowe zestawy zmian (od podstawowej struktury do ostatecznej funkcji).
Osobno, opracowano część serwerową do efektywnej pracy zdalnej z repozytoriami oraz wirtualny system plików do pracy z lokalną częścią części repozytorium, tak jakby było to kompletne repozytorium (programista widzi całe repozytorium, ale tylko żądane dane są kopiowane do lokalnego systemu, do którego uzyskuje się dostęp).
Kod dla tych komponentów wykorzystywanych w infrastrukturze Facebooka nie jest jeszcze otwarty, ale firma obiecała udostępnić go w przyszłości. Jednak prototypy serwera Mononoke (w Rust) i VFS EdenFS (w C++) można już znaleźć w repozytorium Sapling. Te komponenty są opcjonalne, a do pracy wystarczy klient Sapling, który obsługuje klonowanie repozytoriów Git, interakcję z serwerami opartymi na Git LFS i pracę z hostami git, takimi jak GitHub.
Dla Sapling przygotowano kilka wtyczek, w tym interfejs ReviewStack do przeglądania zmian (kod na licencji GPLv2), który umożliwia przetwarzanie żądań ściągania na GitHub i korzystanie z widoku stosu zmian.
Jeśli chcesz dowiedzieć się więcej na ten temat, możesz zapoznać się ze szczegółami W poniższym linku.