फेसबुकले नयाँ स्रोत नियन्त्रण प्रणाली बिरुवा अनावरण गरेको छ

फेसबुक (रूसी संघमा प्रतिबन्धित) ले बिरुवा स्रोत नियन्त्रण प्रणाली प्रकाशित गर्‍यो, आन्तरिक कम्पनी परियोजनाहरूको विकासमा प्रयोग गरिन्छ। प्रणालीले एक परिचित संस्करण नियन्त्रण इन्टरफेस प्रदान गर्ने लक्ष्य राखेको छ जसले लाखौं फाइलहरू, कमिटहरू र शाखाहरू फैलिएको धेरै ठूला भण्डारहरूको लागि मापन गर्न सक्छ। क्लाइन्ट कोड Python र Rust मा लेखिएको छ, र GPLv2 लाइसेन्स अन्तर्गत खुला छ।

एक सर्भर पार्ट रिपोजिटरीहरु संग कुशल रिमोट काम को लागी अलग गरी विकसित गरिएको छ र एक पूर्ण भण्डार को रूप मा भण्डार को एक भाग को एक स्थानीय टुक्रा संग काम को लागी एक भर्चुअल फाइल प्रणाली को लागी (विकासकर्ताले सम्पूर्ण रिपोजिटरी देख्छ, तर पहुँच गरिएको आवश्यक डेटा मात्र। स्थानीय प्रणालीमा प्रतिलिपि गरिएको छ)। फेसबुकको पूर्वाधारमा प्रयोग हुने यी कम्पोनेन्टका लागि कोड अझै खुलेको छैन, तर कम्पनीले भविष्यमा प्रकाशित गर्ने वाचा गरेको छ। जे होस्, हाल Sapling भण्डारमा तपाईंले पहिले नै Mononoke सर्भर (Rust मा) र VFS EdenFS (C++ मा) को प्रोटोटाइपहरू फेला पार्न सक्नुहुन्छ। यी कम्पोनेन्टहरू ऐच्छिक छन् र Sapling क्लाइन्ट काम गर्नको लागि पर्याप्त छ, जसले Git भण्डारहरू क्लोन गर्न, Git LFS मा आधारित सर्भरहरूसँग अन्तर्क्रिया गर्न र GitHub जस्ता git होस्टिङ साइटहरूसँग काम गर्न समर्थन गर्दछ।

प्रणालीको मुख्य विचार यो हो कि भण्डारको भण्डारण प्रदान गर्ने विशेष सर्भर भागसँग अन्तर्क्रिया गर्दा, विकासकर्ताले काम गरिरहेको कोडमा वास्तवमा प्रयोग गरिएका फाइलहरूको संख्याको आधारमा सबै कार्यहरू मापन गरिन्छ, र यसमा निर्भर हुँदैन। सम्पूर्ण भण्डारको कुल आकार। उदाहरणको लागि, एक विकासकर्ताले धेरै ठूलो भण्डारबाट कोडको सानो भाग मात्र प्रयोग गर्न सक्छ र केवल त्यो सानो भाग उसको प्रणालीमा माइग्रेट हुनेछ, सम्पूर्ण भण्डारमा होइन। कार्य डाइरेक्टरी गतिशील रूपमा भरिएको छ जब रिपोजिटरीबाट फाइलहरू पहुँच गरिन्छ, जसले एकातिर, तपाइँलाई कोडको तपाइँको भागको साथ कामको गति बढाउन अनुमति दिन्छ, तर अर्कोतर्फ नयाँ फाइलहरू पहुँच गर्दा सुस्तता निम्त्याउँछ। पहिलो पटक र नेटवर्कमा निरन्तर पहुँच चाहिन्छ (छुट्टै प्रदान गरिएको र कमिटहरू तयार गर्न अफलाइन मोड)।

अनुकूलन डेटा लोडिङको अतिरिक्त, Sapling ले परिवर्तनहरूको इतिहासको साथ जानकारीको लोडिङ घटाउने उद्देश्यले अनुकूलनहरू पनि लागू गर्दछ (उदाहरणका लागि, लिनक्स कर्नेलको साथ भण्डारमा डेटाको 3/4 परिवर्तनहरूको इतिहास हो)। परिवर्तनहरूको इतिहाससँग प्रभावकारी रूपमा काम गर्न, यससँग सम्बन्धित डाटालाई खण्डित प्रतिनिधित्वमा भण्डार गरिएको छ जसले तपाईंलाई सर्भरबाट कमिट ग्राफको व्यक्तिगत भागहरू डाउनलोड गर्न अनुमति दिन्छ। ग्राहकले धेरै कमिटहरू बीचको सम्बन्धको बारेमा सर्भरबाट जानकारी अनुरोध गर्न सक्छ र ग्राफको आवश्यक भाग मात्र डाउनलोड गर्न सक्छ।

यो परियोजना विगत १० वर्षमा विकास भइरहेको छ र एउटा मास्टर शाखाको साथ धेरै ठूला मोनोलिथिक भण्डारहरूमा पहुँच व्यवस्थित गर्दा समस्याहरू समाधान गर्न सिर्जना गरिएको थियो, जसले "मर्ज" को सट्टा "रिबेस" अपरेशन प्रयोग गर्‍यो। त्यस समयमा, त्यस्ता रिपोजिटरीहरूसँग काम गर्नका लागि कुनै खुला समाधानहरू थिएनन्, र फेसबुक इन्जिनियरहरूले नयाँ संस्करण नियन्त्रण प्रणाली सिर्जना गर्ने निर्णय गरे जसले कम्पनीको आवश्यकताहरू पूरा गर्दछ, परियोजनाहरूलाई साना भण्डारहरूमा विभाजन गर्नुको सट्टा, जसले जटिलता निम्त्याउँछ। निर्भरता व्यवस्थापन (एक पटक, समान समस्या समाधान गर्न, माइक्रोसफ्टले GVFS तह सिर्जना गर्यो)। सुरुमा, फेसबुकले मर्क्यूरियल प्रणाली प्रयोग गर्‍यो र पहिलो चरणमा सेपलिंग परियोजनालाई मर्कुरियलको अतिरिक्तको रूपमा विकसित गरियो। समयको साथ, प्रणाली यसको आफ्नै प्रोटोकल, भण्डारण ढाँचा र एल्गोरिदमको साथ एक स्वतन्त्र परियोजनामा ​​परिणत भयो, जुन Git भण्डारहरूसँग अन्तरक्रिया गर्ने क्षमताको साथ विस्तार गरिएको थियो।

कामको लागि, कमांड लाइन उपयोगिता "sl" प्रस्ताव गरिएको छ, जसले विशिष्ट अवधारणाहरू, कार्यप्रवाहहरू र Git र Mercurial सँग परिचित विकासकर्ताहरूलाई परिचित इन्टरफेस लागू गर्दछ। Sapling मा शब्दावली र आदेशहरू Git भन्दा अलि फरक छन् र Mercurial को नजिक छन्। उदाहरणका लागि, शाखाहरूको सट्टा, "बुकमार्कहरू" प्रयोग गरिन्छ (नाम गरिएका शाखाहरू समर्थित छैनन्), पूर्वनिर्धारित रूपमा, क्लोन/पुल कार्यान्वयन गर्दा, सम्पूर्ण भण्डार लोड हुँदैन, तर मुख्य शाखा मात्र, त्यहाँ कमिटहरूको कुनै प्रारम्भिक चिन्ह छैन ( स्टेजिङ एरिया), "git fetch" को सट्टा "sl" कमाण्ड पुल प्रयोग गरिन्छ, "git pull" - "sl pull-rebase" को सट्टा, "git checkout COMMIT" - "sl goto COMMIT" को सट्टा। "git reflog" - "sl journal", "git checkout - FILE" को सट्टा परिवर्तन रद्द गर्न "sl revert FILE" निर्दिष्ट गरिएको छ, र "." लाई "HEAD" शाखा पहिचान गर्न प्रयोग गरिन्छ। तर सामान्यतया, शाखाहरू र क्लोन/पुल/पुश/कमिट/रिबेस अपरेसनहरूको सामान्य अवधारणाहरू संरक्षित छन्।

Sapling Toolkit को अतिरिक्त सुविधाहरू मध्ये, "smartlog" को लागि समर्थन बाहिर खडा छ, जसले तपाइँलाई तपाइँको भण्डारको अवस्था दृश्यात्मक रूपमा मूल्याङ्कन गर्न, सबैभन्दा महत्त्वपूर्ण जानकारी हाइलाइट गर्न र महत्वहीन विवरणहरू फिल्टर गर्न अनुमति दिन्छ। उदाहरणका लागि, जब तपाइँ तर्कहरू बिना sl उपयोगिता चलाउनुहुन्छ, केवल तपाइँको आफ्नै स्थानीय परिवर्तनहरू स्क्रिनमा प्रदर्शित हुन्छन् (अरूलाई न्यूनतम गरिएको छ), बाह्य शाखाहरूको स्थिति, परिवर्तन गरिएका फाइलहरू र कमिटहरूको नयाँ संस्करणहरू देखाइन्छ। थप रूपमा, एक अन्तरक्रियात्मक वेब इन्टरफेस प्रस्ताव गरिएको छ, जसले स्मार्ट लग, परिवर्तन रूख र कमिटहरू मार्फत द्रुत रूपमा नेभिगेट गर्न सम्भव बनाउँछ।

बिरुवामा अर्को उल्लेखनीय सुधार यो हो कि यसले त्रुटिहरू ठीक गर्न र समाधान गर्न र अघिल्लो अवस्थामा फर्काउन सजिलो बनाउँछ। उदाहरणका लागि, आदेशहरू "sl undo", "sl redo", "sl uncommit" र "sl unamend" धेरै कार्यहरू रोल ब्याक गर्न प्रस्ताव गरिन्छ; आदेशहरू "sl hide" र "sl unhide" अस्थायी रूपमा कमिटहरू लुकाउन प्रयोग गरिन्छ; र पुरानो अवस्थाहरू मार्फत अन्तरक्रियात्मक नेभिगेसनको लागि र "sl undo -i आदेश" आदेशको साथ निर्दिष्ट बिन्दुमा फर्कनुहोस्। बिरुवाले कमिट स्ट्याकको अवधारणालाई पनि समर्थन गर्दछ, जसले तपाईंलाई जटिल कार्यक्षमतालाई सानो, थप बुझ्न सकिने वृद्धिशील परिवर्तनहरू (आधारभूत ढाँचाबाट समाप्त कार्यमा) को सेटमा तोडेर चरण-दर-चरण समीक्षाहरू व्यवस्थित गर्न अनुमति दिन्छ।

बिरुवाका लागि धेरै थपहरू तयार गरिएको छ, परिवर्तनहरू समीक्षा गर्नको लागि समीक्षा स्ट्याक इन्टरफेस सहित (GPLv2 अन्तर्गत कोड), जसले तपाईंलाई GitHub मा पुल अनुरोधहरू प्रशोधन गर्न र परिवर्तनहरूको स्ट्याक दृश्य प्रयोग गर्न अनुमति दिन्छ। थप रूपमा, VSCode र TextMate सम्पादकहरू, साथै ISL (Interactive SmartLog) इन्टरफेस र सर्भरको कार्यान्वयनको लागि थपहरू प्रकाशित गरिएको छ।

स्रोत: opennet.ru