आर्क एक monorepository के लिए एक संस्करण नियंत्रण प्रणाली है। यैंडेक्स रिपोर्ट

संस्करण नियंत्रण प्रणाली लंबे समय से डेवलपर्स के लिए एक दैनिक उपकरण है। बड़े मोनोरेपोज़िटरीज़ में, उनके लिए आवश्यकताएं बहुत विशिष्ट हैं। इस वजह से, कंपनियां या तो मौजूदा समाधानों को अनुकूलित करती हैं, जैसा कि फेसबुक मर्क्यूरियल और माइक्रोसॉफ्ट के साथ गिट के साथ करता है, या अपने स्वयं के सिस्टम विकसित करता है: गूगल पर पाइपर और सिटीसी और यैंडेक्स पर आर्क वीसीएस।

रिपोर्ट में, डेवलपर व्लादिमीर किख्टनको किख्त बताता है कि क्यों यांडेक्स को अपने स्वयं के संस्करण नियंत्रण प्रणाली की आवश्यकता थी और यह कैसे काम करता है। एक साधारण डेवलपर की ओर से इस पर विचार करें: स्रोत कोड का उपयोग कैसे करें, विकास के लिए एक शाखा सेट करें और परिवर्तनों को एक सामान्य कोड आधार में एकीकृत करें। हम हुड के नीचे देखते हैं - हम काम की प्रतिलिपि के साथ आभासी फ़ाइल प्रणाली में डेटा के आंतरिक प्रतिनिधित्व और इसके प्रदर्शन के बारे में सीखते हैं। हम वर्चुअल फ़ाइल सिस्टम में वीसीएस कार्यों को लागू करने में कठिनाइयों पर चर्चा करेंगे और जब डेटा को लोड किया जाएगा। चलो इस बारे में बात करते हैं कि रिपॉजिटरी के सर्वर इन्फ्रास्ट्रक्चर की विश्वसनीयता कैसे सुनिश्चित करें। अंत में, आप रिपोर्ट का अनौपचारिक रिकॉर्ड देख सकते हैं।

- शुभ दोपहर सभी, मेरा नाम व्लादिमीर है। आप सभी ने बाइक नहीं लिखने के बारे में भाषण सुना। मेरी रिपोर्ट बैरिकेड के दूसरी तरफ होगी।

दरअसल, यैंडेक्स में एक मोनोरेपोजिटरी है जिसमें बहुत सारे कोड हैं। और हम इस निष्कर्ष पर पहुंचे कि हम अपने स्वयं के संस्करण नियंत्रण प्रणाली विकसित कर रहे हैं।



हमें ऐसी जिंदगी कैसे मिली? ऐतिहासिक रूप से, यह मोनोरेपोजिटरी एसवीएन में हमारे साथ रहती थी। यह ट्रंक-आधारित विकास का अभ्यास करता है। बहुत कम अपवादों वाली कोई शाखा नहीं है। सभी कोड को पहले ट्रंक में जाना चाहिए, और फिर पूर्ण हो जाना चाहिए।

रिपॉजिटरी की वृद्धि के साथ, इसके साथ काम करने का एकमात्र संभव तरीका चयनात्मक चेकआउट था, क्योंकि यह एसवीएन में समर्थित है। संपूर्ण रिपॉजिटरी को अपने आप में अपलोड करना पूरी तरह से असंभव नहीं है, लेकिन इसके साथ काम करना बहुत मुश्किल है।



हमारी समस्या का पैमाना क्या है? यहां कुछ संख्याएं हैं: 6 मिलियन, लगभग 2 मिलियन व्यक्तिगत फाइलें। रिपॉजिटरी के पूरे इतिहास के साथ कुल आकार 2 टीबी है। यह स्पष्ट करने के लिए कि अन्य विशिष्ट रिपॉजिटरी की तुलना में इन नंबरों का क्या मतलब है, यहां एक ग्राफ है। GitHub, 1 MB पर GitHub माध्यिका माध्य भंडार का आकार है। GitHub पर 90 वां प्रतिशत मेरे सहयोगियों ने "मेरी मां की प्रेमिका के बेटे का भंडार" कहा। और बाकी सब कुछ प्रसिद्ध बड़े भंडार हैं।



जहाँ तक मुझे पता है, दुनिया में सबसे बड़ा भंडार Google के पास है। इसके आकार का एक अनुमान 2015 में एक लेख से दिया गया है - शायद तब से वे बड़े हो गए हैं। जैसा कि आप देख सकते हैं, पैमाना लघुगणक है। यह देखा जा सकता है कि हम भी काफी बड़े हैं।

इस संपूर्ण रिपॉजिटरी को डाउनलोड करने का प्रयास करते समय विभिन्न संस्करण नियंत्रण प्रणालियां कैसे काम करती हैं? स्वाभाविक रूप से, हमने तुरंत अपने संस्करण नियंत्रण प्रणाली को विकसित करना शुरू नहीं किया। हमने अपनी रिपॉजिटरी को अलग-अलग सिस्टम में बदलने की कोशिश की। सबसे गंभीर प्रयास मर्कुरियल के साथ किया गया था। और ठेठ संचालन के समय के परिणाम अभी भी हमारे अनुरूप नहीं हैं।



रिपोर्ट की तैयारी के दौरान, git-svn, दुर्भाग्य से, हमारे पूरे भंडार को परिवर्तित नहीं कर सका। कम संख्या के कुछ स्लाइस को रूपांतरित किया, इसलिए मैं यह अनुमान नहीं लगा सकता कि इतिहास के काम से संबंधित कितने ऑपरेशन हैं। एक सेगमेंट में वे तेज हैं, और यह 6 मिलियन के लिए कैसा होगा यह बहुत स्पष्ट नहीं है।

अंत में हमारे संस्करण नियंत्रण प्रणाली के लिए नंबर हैं। आप तुरंत अपने आप को एक काम की नकल प्राप्त कर सकते हैं। पहली शुरुआत में, लॉग ऑपरेशन थोड़ा धीमा हो जाता है, दूसरी शुरुआत में, सब कुछ जल्दी से काम करता है।

और आखिरी अंक। चूंकि हमारा संस्करण नियंत्रण प्रणाली सभी डेटा को आलसी तरीके से लोड करता है, केवल उन स्रोत कोड जिन्हें हमने वास्तव में काम किया था, जिनका हम वास्तव में उपयोग करते थे, डिस्क पर हैं। यह पूरी डाउनलोड करने की तुलना में काफी कम है।



हमने इसे कैसे हासिल किया? मुख्य विशेषता: हमारे द्वारा बनाई गई कार्य प्रतिलिपि डिस्क पर एक वास्तविक फ़ाइल नहीं है। यह एक वर्चुअल फाइल सिस्टम है। लिनक्स और मैक पर, यह फ्यूज के साथ विंडोज पर, प्रॉजेएफएस के साथ किया जाता है। हम सभी डेटा को आलसी तरीके से लोड करते हैं, इसलिए जितना डिस्क स्पेस उपयोग किया जाता है, वास्तव में हमें जरूरत है, हम सब कुछ पहले से लोड करने की कोशिश नहीं कर रहे हैं। और हम सर्वर पर सभी तरह के भारी ऑपरेशन करते हैं। विशेष रूप से - लॉग का संचालन और कुछ और।



हमारे संस्करण नियंत्रण प्रणाली का इंटरफ़ेस, Git को दोहराता है, इसलिए मैं यह नहीं दिखाता कि एक सामान्य वर्कफ़्लो कैसा दिखता है। गित की कल्पना करो। सब कुछ समान है: वांछित संशोधन प्राप्त करने के लिए चेकआउट, शाखाएं बनाने के लिए शाखा, कमिट्स के लिए प्रतिबद्ध है, उसी तरह से स्टैश भी समर्थित है। यह दृष्टिकोण क्या देता है? हम प्रवेश सीमा को काफी कम कर देते हैं। यांडेक्स के अंदर और बाहर अधिकांश डेवलपर्स गिट के साथ काम कर सकते हैं। उन्हें कुछ नया सीखने की जरूरत नहीं है।

दूसरी ओर, हमारे पास गिट के प्रतिस्थापन में गिरावट का कोई लक्ष्य नहीं है। मैं इस बारे में बाद में और विस्तार से बात करूंगा। सभी प्रकार की गिट टीमों का समर्थन करने के लिए पागल लगता है, हम शायद ही उन सभी की जरूरत है।



मैं आपको इनसाइट्स के बारे में थोड़ा बताऊंगा कि यह कैसे काम करता है। चलो डेटा मॉडल से शुरू करते हैं। हमारा डेटा मॉडल कुछ भिन्नताओं के साथ भौगोलिक एक के समान है। उसी तरह, हमारे अंदर पैदा होने वाली सभी वस्तुएँ अपरिवर्तनीय हैं, उन्हें उनकी सामग्री के एक हैश द्वारा संबोधित किया जाता है, और अंदर उन्हें फ्लैटबफ़र में संग्रहीत किया जाता है।



संरचना कैसी दिखती है? प्रतिबद्ध वस्तुएं हैं, प्रत्येक प्रतिबद्ध में एक अलग या कई पूर्वजों हैं। और इस तरह वे कुछ डीएजी (निर्देशित चक्रीय ग्राफ) कहानियों का निर्माण करते हैं।



हमारे पास जो कुछ है और जो तुरंत Git में नहीं दिखाई दिया, वह पीढ़ी संख्या है। एक साधारण एल्गोरिथ्म का उपयोग करते हुए, हम पेड़ की जड़ से एक निश्चित दूरी पर विचार करते हैं। हमें इसकी आवश्यकता क्यों है? यह सभी वस्तुओं की संरचना में सिलना है, एक बार तय हो गया है, और फिर कभी नहीं बदलता है।

एक संस्करण नियंत्रण प्रणाली के लिए एक काफी महत्वपूर्ण संचालन दो कमिट के लिए सबसे छोटा सामान्य पूर्वज ढूंढ रहा है। मूल संस्करण में, इसे केवल चौड़ाई में चारों ओर जाकर लागू किया जा सकता है, कुछ दो बिंदुओं से शुरू होकर, सभी कमिट्स को एक या किसी अन्य चिह्न के साथ वहां तक ​​पहुंचाते हुए, जैसे ही वे एक ऐसा कमिटमेंट पाते हैं जिसमें ये दोनों चिन्ह होते हैं, कम से कम सामान्य पूर्वज होता है।

भोले-भाले कार्यान्वयन में यह कैसे काम करेगा? कुछ इस तरह से: चारों ओर जाओ और हमारी वांछित कमिटमेंट खोजें।



समस्या बी के साथ है, जो बहुत ही कम है। ऐसा लगता है कि हम इसमें नहीं जा सकते थे, लेकिन हमने इसे देखा। और जितना अधिक हमारे पास एक उदाहरण के उपयोग से एक शाखा और एक ट्रंक के बीच अंतर होता है, उतना अधिक अतिरिक्त हम मिलेंगे। एक मोनोरेपोजिटरी के मामले में, जब ट्रंक के लिए आने की दर काफी अधिक होती है, तो यह दूरी बहुत बड़ी हो सकती है। और इस तरह के हजारों अतिरिक्त आवागमन होंगे।





मामले में जब पीढ़ी संख्याएं होती हैं, तो हम क्रॉल करते समय प्राथमिकता कतार का उपयोग कर सकते हैं, और क्रॉल कुछ इस तरह दिखाई देगा: एक बार - और तुरंत आपको जो चाहिए वह मिल जाएगा।



यह हमारे मॉडल के बीच अंतर का एक उदाहरण है। गिट में, यह बात पहले से समर्थित थी, उन्होंने पीढ़ी संख्या टाइमस्टैम्प का इस्तेमाल किया, लेकिन यह केवल तभी काम करेगा जब कमिट बनाने का समय कमिट ग्राफ के अनुरूप हो।



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

इस अनुकूलन का एक और प्लस यह है कि यह पूरी तरह से स्थानीय है। इन नंबरों का उपयोग करने के लिए, हमें पूरे कमिट ग्राफ की आवश्यकता नहीं है। और आमतौर पर हमारे पास यह बिल्कुल नहीं होता है, हमारे साथ यह आलसी लोड होता है। जितना कम हम आलसी लोड करते हैं, उतना बेहतर हम जीते हैं।

कमिट्स के अलावा, मॉडल गिट के समान है। प्रत्येक एक निश्चित वृक्ष वस्तु की ओर इशारा करता है, वृक्ष में रिकॉर्ड होते हैं, प्रत्येक रिकॉर्ड या तो एक और पेड़ होता है, और इस तरह से डायरेक्टरी पदानुक्रम हमें दिखाया जाता है, या यह एक बूँद, कुछ फ़ाइल है। प्लस में हमारे पास BlobRef जैसी चीज़ है, जब फ़ाइल बहुत बड़ी होती है, हम इसे टुकड़ों में विभाजित करते हैं और इसे एक विशेष ऑब्जेक्ट में प्रस्तुत करते हैं। वह सब, जैसा कि गिट में है।



हम Git में क्या पसंद नहीं करते हैं? इस बात को हम कॉपी-इंफो कहते हैं। यदि फ़ाइल को किसी प्रकार की प्रतिबद्ध में कॉपी किया गया था, तो Git इस जानकारी को किसी भी तरह से सहेजता नहीं है, और फिर इसे अलग-अलग स्थिति और स्थितियों को दिखाने के लिए इसे पुनरावृत्तियों के साथ पुनर्स्थापित करने का प्रयास करता है। हम इस जानकारी को ग्राफ़ में सहेजते हैं। रिकॉर्ड्स में इस कमेटी के रिपॉजिटरी के अंदर के रास्ते के लिए कुछ कॉपी-इंफो लिंक हो सकता है, जिसके द्वारा हम जानते हैं कि यह फाइल इस कमिट में कॉपी की गई थी।

डिडुप्लीकेशन भी होता है, जैसा कि साइड में होता है, यह बूँद एक बार जमा हो जाती है। लेकिन समर्पण सभी समान होगा, क्योंकि फ़ाइल की सामग्री में बदलाव नहीं हुआ है, यह हैश द्वारा काट दिया गया है।

बैकएंड की व्यवस्था कैसे की जाती है? यदि Git में वितरित संस्करण नियंत्रण प्रणाली है, तो उसे किसी भी बैकएंड की आवश्यकता नहीं है। हमें यह विशेष रूप से तीव्र रूप से महसूस होता है जब गिटहब नीचे होता है। हम स्पष्ट रूप से समझते हैं कि गिट को बैकएंड की आवश्यकता नहीं है। हमारा सिस्टम क्लाइंट-सर्वर है, यह सर्वर के सभी डेटा को स्टोर करता है, और उन ऑब्जेक्ट को डाउनलोड करने के लिए सर्वर की उपलब्धता की आवश्यकता होती है जो क्लाइंट पर अभी तक नहीं हैं।



सभी डेटा हम यैंडेक्स डेटाबेस में संग्रहीत करते हैं। यह एक बहुत अच्छा डेटाबेस है जो लेनदेन, विश्वसनीयता का आवश्यक स्तर प्रदान करता है। इसमें वह सब कुछ है जो हमें चाहिए, और इस चीज ने हमें कई समस्याओं से बचाया।

इसके लिए धन्यवाद, बैकएंड खुद पूरी तरह से स्टेटलेस है, पूरा राज्य डेटाबेस में है, और बैकएंड हम बहुत आसानी से स्केल कर सकते हैं जितनी हमें ज़रूरत है।

और बातचीत के लिए कि ग्राहकों के साथ, चौराहे के साथ, हम जीआरपीसी का उपयोग करते हैं, आज इसके बारे में एक विस्तृत रिपोर्ट थी।



हमारा सिस्टम SVN के साथ कैसे एकीकृत है? एसवीएन रिपॉजिटरी जीना जारी रखती है। इसके अलावा, हमारे संस्करण नियंत्रण प्रणाली अभी तक आत्मनिर्भर नहीं है। वह इस हिस्से में कैसे काम करती है? प्रारंभ में, कुछ कनवर्टर घटक है जो एसवीएन रिपॉजिटरी की स्थिति पर नज़र रखता है और एसवीएन कमिट्स को आर्क कमिट्स में बदल देता है - हमारे संस्करण नियंत्रण प्रणाली।

अगला, एक क्लाइंट है जो एक कार्यशील प्रतिलिपि बनाता है और डेटा के लिए सर्वर पर जाता है। जब कोई डेवलपर कुछ करता है, तो उसे पहले आर्क सर्वर पर भेजा जाता है, लेकिन ट्रंक पर जाने के लिए इन परिवर्तनों के लिए, हमारी मुख्य शाखा, उन्हें पूल अनुरोध प्रणाली और कोड समीक्षा प्रणाली से गुजरना होगा। यहां एक और सेवा आती है जो आर्क की शाखाओं की निगरानी करती है, और यदि उन्हें अपडेट किया जाता है, तो हमारे सिस्टम कोड की समीक्षा के लिए एक पूल अनुरोध भेजता है। अगला कोड समीक्षा प्रणाली है, जब यह तय हो जाता है कि इस पैच को मर्ज करने की आवश्यकता है, तो यह एसवीएन को भेज देता है। यह बिल्कुल सरल नहीं है: यह एक निश्चित मात्रा में मेटाडेटा जोड़ता है कि यह प्रतिबद्ध वास्तव में आर्क से इस तरह की एक शाखा का विलय है। और फिर यह कमिट पहले से ही कनवर्टर को देखता है, इस मेटा-डेटा को इसमें पाता है और आर्क सर्वर में एक कमिट बनाता है। यह आवागमन का चक्र है। इसलिए, जबकि हम SVN के बिना नहीं रह सकते, क्योंकि हमारे पास SVN में ट्रंक है।

मुख्य शाखा लगातार हमारे सर्वर के साथ सिंक्रनाइज़ होती है, लेकिन हम इसे सीधे करने की अनुमति नहीं देते हैं।



बैकएंड की विश्वसनीयता के बारे में। बेशक, हमारी योजना है कि सभी यैंडेक्स डेवलपर्स इस चीज का उपयोग करेंगे, इसलिए हमारे लिए यह महत्वपूर्ण है कि यह टूट न जाए। यह एक इंट्रा-इंडेक्स मानक है: हमारी सेवाओं को किसी भी डेटा सेंटर की विफलता से बचना चाहिए। संस्करण नियंत्रण प्रणाली कोई अपवाद नहीं है। यहाँ, हम इस तथ्य से बहुत बचते हैं कि YDB इसका समर्थन करता है। और हमारे बैकएंड स्टेटलेस हैं, अलग-अलग हिस्सों को थोड़ा अलग तरीके से लागू किया जाता है। आर्क ऑब्जेक्ट पर काम करने वाले सर्वर शाखाओं पर काम करते हैं, वे स्टेटलेस, प्रतिकृति होते हैं। एसवीएन से लगातार परिवर्तित होने वाले कन्वर्टर्स को सक्रिय-सक्रिय योजना के अनुसार दोहराया जाता है। कई कन्वर्टर्स एक साथ काम कर रहे हैं, वे एक ही समय में परिवर्तित होते हैं, और जिस क्षण वे आर्क शाखा को अपडेट करने की कोशिश करते हैं, वे संघर्षों को हल करते हैं। एक सफल हुआ, दूसरा असफल रहा। वह आगे कुछ बदलने की कोशिश कर रहा है।

पूल अनुरोध सेवा को मास्टर-दास द्वारा दोहराया जाता है। एक मुख्य काम कर रहा है। यदि यह विफल रहता है, तो YDB के माध्यम से एक नया चयन किया जाता है। सेमाफोरस जैसी अद्भुत चीज है, जिसकी पहुंच, विश्वसनीयता की गंभीर गारंटी है। सेमाफोर तक पहुंच पूरी तरह से धारावाहिक है। हम दोनों पूल अनुरोध खोज सेवा के लिए और नेताओं के चयन के लिए सेमाफोर का उपयोग करते हैं।

क्लाइंट कैसे काम करता है, इसके बारे में थोड़ा। यह हमारे संस्करण नियंत्रण प्रणाली का सबसे कठिन हिस्सा है, क्योंकि एक आभासी फ़ाइल प्रणाली है। वास्तव में, हम अपने दम पर फाइलों पर सभी कार्यों को लागू करने के लिए मजबूर हैं। मैं कुछ बुनियादी कार्यों पर जाऊंगा, जब हम उन्हें करते हैं, तो उंगलियों पर मोटे तौर पर वर्णन करते हैं कि क्या होता है।



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



यदि हम पढ़ने के लिए फ़ाइल खोलते हैं, तो हम कुछ भी नहीं कर सकते हैं, लेकिन सीधे हमारे ब्लॉब से डेटा देते हैं।



यहां वह क्षण है जब हम फ़ाइल को इंडेक्स में जोड़ते हैं। इस बिंदु पर, आपको यह देखने की आवश्यकता है कि क्या हमारे पास कुछ भौतिक है। क्या कोई फाइल बदल गई है यदि यह है, तो इसके लिए एक बूँद बनाएँ और इसे सूचकांक में सहेजें।



अगला ऑपरेशन चाप स्थिति है। यह दिलचस्प है क्योंकि यह बात है कि इस तरह के आकारों में पारंपरिक संस्करण नियंत्रण प्रणाली धीमी है, क्योंकि इसे पूरी फ़ाइल ट्री को पार करना पड़ता है। हमें संपूर्ण फ़ाइल ट्री के आसपास जाने की आवश्यकता नहीं है, क्योंकि फ़ाइलों को बदलने के सभी अनुरोध हमारे फ्यूज-ड्राइवर के माध्यम से जाते हैं, और हम तुरंत जानते हैं कि कौन सी फाइलें परिवर्तनों के लिए जांचने योग्य हैं। हम जांच करते हैं कि हम सूचकांक में लिखने में क्या कामयाब रहे, और जवाब प्रिंट करें।



प्रतिबद्ध समय। सब कुछ स्पष्ट होने लगता है। एक इंडेक्स है, हमने पहले ही इन ऑब्जेक्ट्स के लिए ब्लॉब्स बनाए हैं, ट्री ऑब्जेक्ट बनाए हैं जो इस राज्य के अनुरूप हैं, एक नई कमिट ऑब्जेक्ट बनाते हैं, इसे ऑब्जेक्ट स्टोरेज पर लिखते हैं।



अगला, हम नई प्रति के लिए काम की प्रतिलिपि को स्विच करते हैं। यह एक पेचीदा ऑपरेशन है, यह स्पष्ट रूप से चेकआउट कमांड के साथ किया जा सकता है। और यहाँ आप सोच सकते हैं कि हमारे सभी स्थानीय परिवर्तन पहले ही भौतिक हो चुके हैं, हम यह मान सकते हैं कि हमें फिर से ऐसी फाइलें देनी चाहिए जो नए कमिट से भौतिक न हों। और वह यह है। बाद के सभी ऑपरेशनों को बस दूसरे पेड़ पर भेजा जाता है और बूँदें दी जाती हैं।



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

लेकिन एल्गोरिदम की जटिलता के संदर्भ में, हमने यहां कुछ भी नहीं खोया: स्थानीय परिवर्तनों के ये सभी पेड़ किए गए परिवर्तनों के आनुपातिक हैं। इसलिए, हमें इन परिचालनों के साथ पूरे भंडार के आसपास नहीं जाना चाहिए, वे अभी भी बहुत जल्दी काम करते हैं।

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



हमारे संस्करण नियंत्रण प्रणाली में, ट्रंक-आधारित विकास के लिए समर्थन नेल्ड है। सबसे पहले, जो मैंने पहले ही कहा है: सभी परिवर्तन पूल अनुरोधों और ट्रंक के माध्यम से जाते हैं। कुछ और बिंदु हैं। हमारे पास समूह शाखा का समर्थन नहीं है। आर्क में निर्मित शाखाएं एक विशिष्ट उपयोगकर्ता से जुड़ी होती हैं, और केवल वह ही वहां प्रतिबद्ध हो सकता है। यह हमें लंबे समय तक रहने वाली शाखाओं से बचने की अनुमति देता है। एसवीएन में, यह विशेष रूप से नहीं था, क्योंकि शाखाओं को बनाने के लिए असुविधाजनक है। और आर्क में उन्हें करना सुविधाजनक है, और यदि इसे नियंत्रित नहीं किया जाता है, तो हमें डर है कि हमारी मोनो-रिपॉजिटरी के कुछ हिस्से अपनी शाखाओं के लिए निकल जाएंगे और वहां अपना विकास करेंगे। यह उस मॉडल के विपरीत है जिसे हम करना चाहते हैं।



दूसरे, हमारे पास मर्ज कमांड नहीं है। शाखाओं के सभी विलय हमारे सख्त नियंत्रण में होते हैं। हम अब रिलीज के लिए शाखाएं विकसित कर रहे हैं, जिसमें विलय करना भी संभव होगा। यह भी कुछ उपयोगकर्ता टीम द्वारा नहीं किया जाएगा, लेकिन सर्वर मशीनरी द्वारा, सबसे अधिक संभावना है।



हमारी योजनाएं क्या हैं? 20% मोनोरेपोजिटरी डेवलपर्स पहले से ही हमारे संस्करण नियंत्रण प्रणाली का उपयोग करते हैं। हम पहले से ही कुछ प्रकार के शिशु अवस्था से उभरे हैं, यह एक गंभीर रूप से उपयोग की जाने वाली प्रणाली है, इसे केवल इस तरह से बाहर फेंकना असंभव है। अंतिम लक्ष्य यांडेक्स में मुख्य संस्करण नियंत्रण प्रणाली बनना है। हमें शेष 80% डेवलपर्स को आश्वस्त करना चाहिए कि हम काफी स्थिर, विश्वसनीय और प्रयोग करने योग्य हैं। यह स्पष्ट है कि इसके लिए आपको सभी बग्स को ठीक करना होगा और उन विशेषताओं को समाप्त करना होगा जो कि Git में हैं।

स्वाभाविक रूप से, कुछ परिप्रेक्ष्य में, हम आत्मनिर्भर बनने की योजना बनाते हैं, कनवर्टर को छोड़ देते हैं या इसे विपरीत दिशा में तैनात करते हैं, ताकि पहले सभी परिवर्तन आर्क में जाएं, और फिर सबसे लगातार प्रोग्रामर के लिए एसवीएन के लिए।

अब हमारे सामने एक बड़ी चुनौती है - हमारे ऑटो असेंबली में संस्करण नियंत्रण प्रणाली का एकीकरण, हमारे CI और अन्य पाइपलाइन में। चुनौती यह है कि लोग आत्मा में कमजोर हैं, वे धीरे-धीरे कोड टाइप करते हैं और धीरे-धीरे प्रतिबद्ध होते हैं। और वे कोड को बहुत धीरे-धीरे डाउनलोड करते हैं। और रोबोट इस खामी से वंचित हैं।

— , CI Arc, - . , . . , ++- , , . .

. « Git». : Git. , , .

. Git . , . - . , checkout reset, . , , . : Git. « , ». Git .

. Git, git begin-wave-stash?

:
— .

— , Git ? — , , , . , . Git . , . .