Facebook-მა წარმოადგინა ახალი კოდის მართვის სისტემა Sapling

ფეისბუქმა (რუსეთში აკრძალული) გამოაქვეყნა Sapling წყაროს კოდის მართვის სისტემა, რომელიც გამოიყენება კომპანიის შიდა პროექტების შემუშავებაში. სისტემა მიზნად ისახავს უზრუნველყოს ნაცნობი ვერსიების ინტერფეისი, რომელიც შეიძლება მასშტაბური იყოს ძალიან დიდ საცავებამდე, რომელიც მოიცავს ათობით მილიონ ფაილს, ვალდებულებას და ფილიალს. კლიენტის კოდი იწერება Python-ში და Rust-ში და ღიაა GPLv2 ლიცენზიით.

ცალკე, შეიქმნა სერვერის ნაწილი საცავებთან ეფექტური დისტანციური მუშაობისთვის და ვირტუალური ფაილური სისტემა საცავის ნაწილის ლოკალურ ნაწილთან მუშაობისთვის, როგორც სრული საცავისთვის (დეველოპერი ხედავს მთელ საცავს, მაგრამ მხოლოდ მოთხოვნილი მონაცემები კოპირებულია. ადგილობრივ სისტემაში, რომლებზეც წვდომა ხდება). ფეისბუქის ინფრასტრუქტურაში გამოყენებული ამ კომპონენტების კოდი ჯერ არ არის გახსნილი, მაგრამ კომპანია დაპირდა, რომ გამოაქვეყნებს მას მომავალში. თუმცა, Mononoke სერვერის პროტოტიპები (Rust-ში) და VFS EdenFS (C++-ში) უკვე შეგიძლიათ ნახოთ Sapling საცავში. ეს კომპონენტები არჩევითია და საკმარისია Sapling კლიენტი იმუშაოს, რომელიც მხარს უჭერს Git საცავების კლონირებას, Git LFS-ზე დაფუძნებულ სერვერებთან ინტერაქციას და გიტ ჰოსტებთან მუშაობას, როგორიცაა GitHub.

სისტემის მთავარი იდეა ის არის, რომ სერვერის სპეციალურ ნაწილთან ურთიერთობისას, რომელიც უზრუნველყოფს საცავების შენახვას, ყველა ოპერაცია მასშტაბირებულია იმ ფაილების რაოდენობის მიხედვით, რომლებიც რეალურად გამოიყენება კოდში, რომელზეც მუშაობს დეველოპერი და არ არის დამოკიდებული. მთელი საცავის მთლიანი ზომა. მაგალითად, დეველოპერს შეუძლია გამოიყენოს კოდის მხოლოდ მცირე ნაწილი ძალიან დიდი საცავიდან და მხოლოდ ეს მცირე ნაწილი, ვიდრე მთელი საცავი, გადაეცემა მის სისტემას. სამუშაო დირექტორია ივსება დინამიურად, რადგან წვდომა ხდება საცავიდან ფაილებზე, რაც, ერთი მხრივ, საშუალებას გაძლევთ მნიშვნელოვნად დააჩქაროთ მუშაობა კოდის თქვენს ნაწილთან, მაგრამ, მეორე მხრივ, იწვევს შენელებას, როდესაც პირველად შედიხართ. ახალი ფაილები და მოითხოვს მუდმივ წვდომას ქსელში (ცალკე მოწოდებული და ოფლაინ-რეჟიმი კომიტების მომზადებისთვის).

მონაცემთა ადაპტაციური დატვირთვის გარდა, Sapling ასევე ახორციელებს ოპტიმიზაციას, რომელიც მიზნად ისახავს ინფორმაციის ჩატვირთვის შემცირებას ცვლილებების ისტორიით (მაგალითად, Linux-ის ბირთვის მქონე საცავში არსებული მონაცემების 3/4 არის ცვლილებების ისტორია). ცვლილებების ისტორიასთან ეფექტურად მუშაობისთვის, მასთან დაკავშირებული მონაცემები ინახება სეგმენტურ ხედში, რაც საშუალებას გაძლევთ ჩამოტვირთოთ commit გრაფის ცალკეული ნაწილები სერვერიდან. კლიენტს შეუძლია სერვერს სთხოვოს ინფორმაცია რამდენიმე commit-ის ურთიერთობის შესახებ და ჩამოტვირთოს გრაფის მხოლოდ აუცილებელი ნაწილი.

პროექტი შემუშავდა ბოლო 10 წლის განმავლობაში და შეიქმნა პრობლემების გადასაჭრელად, როდესაც ორგანიზებას უწევდა წვდომას ძალიან დიდ მონოლითურ საცავებში ერთი სამაგისტრო ფილიალით, რომელშიც პრაქტიკაში იყო გამოყენებული "rebase" ოპერაციის ნაცვლად "შერწყმის" პრაქტიკა. იმ დროს არ არსებობდა ღია გადაწყვეტილებები ასეთ საცავებთან მუშაობისთვის და ფეისბუქის ინჟინრებმა გადაწყვიტეს შეექმნათ ახალი ვერსიის კონტროლის სისტემა, რომელიც აკმაყოფილებს კომპანიის საჭიროებებს, ნაცვლად პროექტების მცირე საცავებად დაყოფისა, რაც გამოიწვევს დამოკიდებულების უფრო რთულ მართვას. (ერთ დროს, მსგავსი პრობლემის გადასაჭრელად, Microsoft-მა შექმნა GVFS ფენა). თავდაპირველად Facebook-მა გამოიყენა Mercurial სისტემა და Sapling პროექტი თავდაპირველად განვითარდა Mercurial-ის დამატებით. დროთა განმავლობაში სისტემა გარდაიქმნა დამოუკიდებელ პროექტად საკუთარი პროტოკოლით, შენახვის ფორმატით და ალგორითმებით, რომელიც ასევე გაფართოვდა Git საცავებთან ურთიერთობის შესაძლებლობით.

სამუშაოსთვის შემოთავაზებულია "sl" ბრძანების ხაზის პროგრამა, რომელიც ახორციელებს ტიპურ კონცეფციებს, სამუშაო პროცესებს და ინტერფეისს, რომელიც ნაცნობია დეველოპერებისთვის, რომლებიც იცნობენ Git-სა და Mercurial-ს. Sapling-ში ტერმინოლოგია და ბრძანებები ოდნავ განსხვავდება Git-ისგან და უფრო ახლოსაა Mercurial-თან. მაგალითად, "სანიშნეები" გამოიყენება ფილიალების ნაცვლად (დასახელებული ფილიალები არ არის მხარდაჭერილი), ნაგულისხმევად, კლონირების / გაყვანის შესრულებისას, არ იტვირთება მთელი საცავი, არამედ მხოლოდ მთავარი ფილიალი, არ არის ჩადენილი წინასწარი მონიშვნა ( დადგმის არე), „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" ფილიალის იდენტიფიცირებისთვის. მაგრამ ზოგადად, განშტოების და კლონირება/გაყვანის/დაძაბვის/დასრულების/რებაზის ოპერაციების ზოგადი ცნებები შენარჩუნებულია.

Sapling ინსტრუმენტარიუმის დამატებით მახასიათებლებს შორის გამოირჩევა „ჭკვიანი ჟურნალის“ (smartlog) მხარდაჭერა, რომელიც საშუალებას გაძლევთ ვიზუალურად შეაფასოთ თქვენი საცავის მდგომარეობა, მონიშნოთ ყველაზე მნიშვნელოვანი ინფორმაცია და გაფილტროთ უმნიშვნელო დეტალები. მაგალითად, როდესაც თქვენ აწარმოებთ sl პროგრამას არგუმენტების გარეშე, ნაჩვენებია მხოლოდ თქვენი ადგილობრივი ცვლილებები (უცხოები იშლება), ნაჩვენებია გარე ფილიალების სტატუსი, შეცვლილი ფაილები და კომისიის ახალი ვერსიები. გარდა ამისა, შემოთავაზებულია ინტერაქტიული ვებ-ინტერფეისი, რომელიც შესაძლებელს ხდის სწრაფად ნავიგაციას ჭკვიანი ჟურნალში, შეცვალოს ხე და ჩააბაროს.

Sapling-ის კიდევ ერთი შესამჩნევი გაუმჯობესება არის შეცდომების გამოსწორებისა და ანალიზის პროცესის გამარტივება და წინა მდგომარეობაზე დაბრუნება. მაგალითად, ბრძანებები "sl undo", "sl redo", "sl uncommit" და "sl unamend" სთავაზობენ მრავალი ოპერაციების დასაბრუნებლად, "sl hide" და "sl unhide" ბრძანებები დროებით დამალვა commits და ინტერაქტიული ნავიგაცია. ძველ მდგომარეობებს და მითითებულ წერტილს დაუბრუნეთ ბრძანება "sl undo -i command". Sapling ასევე მხარს უჭერს commit stack-ის კონცეფციას, რომელიც საშუალებას გაძლევთ მოაწყოთ ნაბიჯ-ნაბიჯ მიმოხილვა რთული ფუნქციების დაყოფით მცირე და უფრო გასაგები დამატებითი ცვლილებების ნაკრებად (ძირითადი ჩარჩოდან დასრულებულ ფუნქციამდე).

Sapling-ისთვის მომზადებულია რამდენიმე დამატება, მათ შორის ReviewStack ინტერფეისი ცვლილებების განხილვისთვის (კოდი GPLv2-ის ქვეშ), რომელიც საშუალებას გაძლევთ დაამუშავოთ pull-ის მოთხოვნები GitHub-ზე და გამოიყენოთ ცვლილებების სტეკის ხედი. გარდა ამისა, გამოქვეყნებულია დამატებები VSCode და TextMate რედაქტორებთან ინტეგრაციისთვის, ასევე ISL (Interactive SmartLog) ინტერფეისისა და სერვერის განსახორციელებლად.

წყარო: opennet.ru