OpenAI मध्ये Git चा विस्तार

गेल्या वर्षभरात आमच्या एकत्रित रिपॉझिटरीचा आकार आणि तिच्यावरील मागणी प्रचंड वेगाने वाढली आहे. Codex मुळे शक्य झालेल्या समवर्ती कामाच्या प्रमाणाला सामावून घेण्यासाठी आमची स्रोत नियंत्रण प्रणाली नव्याने घडवणे गरजेचे असल्याचे स्पष्ट झाले.

अभियांत्रिकीचे कोणतेही काम न थांबवता किंवा आमचा संघ Git कसे वापरतो ते न बदलता, आम्ही Git रिपॉझिटरींसाठी Pando ही नवी पृष्ठभागामागील प्रणाली तयार केली. आता OpenAI च्या एकत्रित रिपॉझिटरीतील सर्व विकासकाम Pando वर चालते. Pando ची रचना दोन महत्त्वाकांक्षी उद्दिष्टांसाठी केली आहे: पहिले म्हणजे, अनेक शाखांत एकाच वेळी पुश करण्यासाठी अनुकूलित आणि अधिक यंत्रे जोडून वाढवता येणारी लेखनक्षमता. दुसरे म्हणजे वाचनाचा थ्रुपुट कमाल करणे, जेणेकरून क्लायंट त्यांच्या उपलब्ध नेटवर्क बँडविड्थचा पूर्ण वापर होईल इतक्या वेगाने डेटा डाउनलोड करू शकतील.

Git प्रोटोकॉल आणि क्लायंटशी सुसंगतता राखून आम्ही ही उद्दिष्टे गाठली. त्यामुळे आमच्या अभियंत्यांना आणि एजंटना त्यांच्या विद्यमान कार्यपद्धतींत Pando सहज स्वीकारता आले. प्रत्यक्ष वापरात Pando ने पुशचा मध्यक विलंब जवळपास एक-पंचमांशावर आणला. ते आता दररोज जवळपास एक पेटाबाइट Git डेटा पुरवते.

नवी स्रोत नियंत्रण प्रणाली तयार करण्यामागची आमची कारणे आणि Git शी सुसंगतता कायम ठेवण्याचा निर्णय आम्ही का घेतला, हे येथे पाहू. Git चा विस्तार करण्याच्या प्रचलित पद्धतींशी आमच्या प्रणालीची तुलना करू आणि OpenAI च्या विस्तारविषयक गरजा पूर्ण करण्यात Pando वैशिष्ट्यपूर्णरीत्या सक्षम का आहे ते सांगू. पुढील वाटचाल आणि एजंटच्या कामाचे प्रचंड प्रमाण समर्थित करण्यासाठी Git मध्ये योगदान देत राहण्याविषयीही चर्चा करू.

Codex ने OpenAI मधील विकासकामाचे प्रमाण आणि वेग बदलला आहे. अभियंते आता खूप अधिक काम समांतरपणे करू शकतात. याचा अर्थ अधिक शाखा, पुश आणि विलीनीकरणे, तसेच विकास वातावरणे, संशोधन कार्ये आणि सतत एकत्रीकरणातून अधिक फेच व क्लोन.

या मागण्या एकमेकांचा भार आणखी वाढवतात. आता एका अभियंत्याचे अनेक बदल एकाच वेळी सतत एकत्रीकरणासाठी तयार असतात आणि प्रत्येक पुशमुळे अनेक कार्ये एकच कमिट मिळवू लागतात.

गेल्या वर्षाच्या अखेरीपासून आमच्या एकत्रित रिपॉझिटरीला आधार देणाऱ्या प्रणालींना या वेगाशी जुळवून घेणे कठीण जाऊ लागले. फेच आणि पुश मंदावले, विलीनीकरणे अयशस्वी झाली आणि विश्वसनीयता कधी कधी 90% च्याही खाली गेली. ही मर्यादा Git चीच होती, की आमची एकत्रित रिपॉझिटरी उपलब्ध करून देण्याच्या पद्धतीची? ईमेलद्वारे कर्नलचे पॅच एकमेकांना पाठवणाऱ्या समुदायातून Git विकसित झाले. दोन दशकांहून अधिक काळ, सॉफ्टवेअर बनवण्याच्या पद्धती बदलत गेल्या तशा विकसकांनी Git भोवतीची आपली साधने जुळवून घेतली. आमच्या एकत्रित रिपॉझिटरीत अडचणी जाणवू लागल्यावरही, त्या आधीच्या कामावरच पुढे उभारणी करता येणे आम्हाला महत्त्वाचे वाटले.

परिचित कार्यपद्धत कायम ठेवून, विविध शाखांतील पुश समांतरपणे हाताळण्यासाठी आणि अनेक वाचकांना एकाच वेळी समान इतिहास देण्यासाठी अंतर्गत प्रणाली नव्याने घडवण्याचा मार्ग आम्हाला दिसला. आमच्या स्रोत नियंत्रण कार्यपद्धतीचा पाया Git ठेवल्याने, क्लायंटमधील सुधारणा OpenAI बाहेरही उपयुक्त ठरू शकणार होत्या. आमच्या Git च्या प्रतीतील⁠(नवीन विंडोमध्ये उघडेल) या सुधारणा मूळ प्रकल्पात योगदान म्हणून देऊन व्यापक समुदायासोबत सामायिक करायच्या होत्या.

स्रोत नियंत्रण प्रणालीच्या विस्ताराचे दोन प्रमुख पैलू आहेत: विविध शाखांत पुश करणारे अनेक लेखक आणि समान इतिहास मिळवणारे अनेक वाचक. Pando दोन्हींसाठी अनुकूलित आहे.

प्रथम, Pando प्रत्येक शाखेतील अद्यतनांचा स्वतंत्रपणे समन्वय करते. असंबंधित शाखांतील अद्यतने समांतरपणे होऊ शकतात आणि शाखा मिळवणाऱ्या वाचकाला त्या आवृत्तीसाठी आवश्यक इतिहास मिळतो. यातील तडजोड अशी की अनेक शाखा पाहणाऱ्या वाचकाला त्या वेगवेगळ्या क्षणांतील स्थितीत दिसू शकतात.

दुसरे, प्रत्येक क्लायंटसाठी वेगळी पॅकफाइल तयार करण्याऐवजी Pando विविध फेचमध्ये पॅकफाइलचा पुनर्वापर करते. पॅकफाइल हे अनेक ऑब्जेक्ट एकत्र संकुचित करण्याचे Git चे स्वरूप आहे. क्लायंटकडे आधीच असलेले काही ऑब्जेक्ट पुन्हा डाउनलोड होऊ शकतात, पण सर्व्हर अल्प संगणनातून तेच बाइट अनेक क्लायंटना देऊ शकतो.

या निवडींमुळे आम्हाला विविध शाखांवरील लेखनक्षमता वाढवता येते आणि कॅशेमधून वाचनाच्या विनंत्या पूर्ण करता येतात. हे एकत्र कसे कार्य करते ते पाहण्यासाठी, Git इतिहास कसा साठवते आणि हस्तांतरित करते, येथून सुरुवात करू.

Git ला रिपॉझिटरीतील दोन भाग परस्परांशी सुसंगत ठेवता आले पाहिजेत: ऑब्जेक्ट आणि संदर्भ.

Git रिपॉझिटरी फाइलची स्थितिचित्रे आणि त्यांना जोडणारा इतिहास ऑब्जेक्टच्या आलेखात नोंदवते. ऑब्जेक्ट हा ब्लॉब, ट्री, कमिट किंवा टॅग असू शकतो. ब्लॉबमध्ये एका फाइलचा मजकूर असतो. ट्री नावे ब्लॉब किंवा इतर ट्रीशी जोडून निर्देशिकेची रचना तयार करतात. कमिट मूळ ट्रीकडे आणि शून्य किंवा अधिक जनक कमिटकडे निर्देश करतात. यातून रिपॉझिटरीचा इतिहास तयार होतो.

ऑब्जेक्टचा प्रकार आणि त्यातील सामग्री यांच्या हॅशवरून त्यांची ओळख ठरते. ऑब्जेक्ट अपरिवर्तनीयही असतात: बदललेली फाइल नोंदवल्यावर नवीन ब्लॉब तयार होतो, तर न बदललेल्या फाइल आणि निर्देशिका विद्यमान ऑब्जेक्ट पुन्हा वापरू शकतात.

शाखा आणि टॅग हे कमिटकडे निर्देश करणारे संदर्भ, म्हणजेच “रेफ”, असतात. शाखेत कमिट केल्यावर नवीन कमिट तयार होतो आणि शाखेचा संदर्भ त्याकडे निर्देश करण्यासाठी अद्यतनित होतो.

Git ऑब्जेक्ट “सुट्या” किंवा “पॅक केलेल्या” स्थितीत साठवते. सुटे ऑब्जेक्ट त्यांच्या ऑब्जेक्ट ओळखचिन्हाने ओळखल्या जाणाऱ्या स्वतंत्र फाइलमध्ये साठवले जातात. पॅक केलेले ऑब्जेक्ट एका पॅकफाइलमध्ये एकत्र साठवले जातात. त्यामुळे समान ऑब्जेक्ट एकमेकांच्या तुलनेतील फरकांच्या रूपात साठवता येतात.

Git मध्ये एखाद्या कमिटपासून त्याचे जनक, ट्री आणि ब्लॉब यांच्या दुव्यांमधून पुढे जाऊन ऑब्जेक्ट सापडत असेल, तर तो त्या कमिटमधून गाठता येणारा ऑब्जेक्ट असतो. फेचदरम्यान क्लायंट सर्व्हरला कोणते कमिट हवे आहेत आणि कोणते आधीच आहेत हे सांगतो. सर्व्हर अपेक्षित कमिटमधून गाठता येणारे ऑब्जेक्ट शोधतो, क्लायंटकडे आधीच असल्याचे माहीत असलेले वगळतो आणि उरलेले Git डिस्कवर वापरते त्याच स्वरूपातील पॅकफाइलमध्ये पाठवतो. पूर्ण क्लोनची सुरुवात कोणत्याही ऑब्जेक्टशिवाय होते. त्यामुळे क्लोन केल्या जाणाऱ्या इतिहासातून गाठता येणारे सर्व ऑब्जेक्ट त्याला आवश्यक असतात.

पुश सर्व्हरला एक किंवा अधिक संदर्भ अद्यतनित करण्यास सांगून ऑब्जेक्ट उलट दिशेने हस्तांतरित करतो. सर्व्हरकडे आधीच असलेले ऑब्जेक्ट पाठवणे टाळण्यासाठी क्लायंट सर्व्हरने जाहीर केलेल्या संदर्भांचा संच वापरतो. त्यामुळे पाठवला जाणारा पॅक विद्यमान ऑब्जेक्टवर अवलंबून असू शकतो: नवीन इतिहास पुन्हा उभारण्यासाठी फक्त तो पॅक मिळणे पुरेसे नसते.

Git रिपॉझिटरीच्या प्रतिकृती राखणे म्हणजे अनेक सर्व्हरवर ऑब्जेक्ट आणि संदर्भ दोन्ही उपलब्ध ठेवणे. प्रतिकृतीने एखाद्या संदर्भाचे नवीन मूल्य देण्याआधी, त्या मूल्यातून गाठता येणारे ऑब्जेक्ट पुरवणे तिला शक्य असले पाहिजे. सेवेला परस्परस्पर्धी संदर्भ-अद्यतनांचा समन्वयही करावा लागतो. म्हणजे एकाच शाखेला त्याच जुन्या अग्रबिंदूपासून वेगवेगळ्या नवीन कमिटकडे नेण्याचा प्रयत्न करणाऱ्या पुशचा. रिपॉझिटरीतील सर्व लेखनावर एकच क्रम लादणाऱ्या प्रणालींमुळे असंबंधित शाखांतील पुशना एकमेकांची वाट पाहावी लागू शकते.

Pando ची रचना करताना, आम्ही Git द्वारे स्रोत नियंत्रणाचा विस्तार करण्याच्या प्रचलित पद्धती तपासल्या: एक पद्धत त्रि-टप्पा कमिटद्वारे रिपॉझिटरीच्या प्रतिकृतींतील संदर्भ-अद्यतनांचा समन्वय करते (3PC, अनेक नोडवर कमिटचा समन्वय करणारा प्रोटोकॉल). दुसरी ब्लॉब संचयातील सामायिक पूर्वलेखन नोंदवहीद्वारे अद्यतनांचा क्रम ठरवते (WAL, बदल लागू करण्यापूर्वी लिहिलेली त्यांची नोंद).

आम्ही अनुकरण केलेल्या त्रि-टप्पा कमिट रचनेत, Git सेवा अनेक प्रतिकृतींवर रिपॉझिटरीची पूर्ण प्रत ठेवते. कोणत्याही सर्व्हरला पुश मिळाल्यावर, आलेल्या पॅकफाइलची प्रत करून ती सर्व प्रतिकृतींना समांतरपणे पाठवली जाते. पुश प्रकाशित करण्यासाठी बहुसंख्य प्रतिकृतींनी संदर्भ-अद्यतन स्वीकारले पाहिजे. हे व्यवस्थापन करणारा सर्व्हर समन्वयक असतो. समन्वयक आणि प्रत्येक इतर प्रतिकृती यांच्यात संवादाच्या अनेक फेऱ्या आवश्यक असतात.

संदर्भ-अद्यतन स्वीकारण्यासाठी, प्रत्येक प्रतिकृती संदर्भाच्या स्वतःकडील प्रतीवर टाळा लावते आणि तो अजूनही क्लायंटला अपेक्षित कमिटकडे निर्देश करतो का हे तपासते. त्यानंतर समन्वयक स्वीकारणाऱ्या प्रतिकृतींना कमिटपूर्व संदेश पाठवतो. बहुसंख्य प्रतिकृतींनी कमिटपूर्व संदेशाची पोच दिल्यावर, समन्वयक त्यांना अद्यतन करण्यास सांगतो. त्यानंतर कोणतीही अद्ययावत प्रतिकृती रिपॉझिटरीच्या स्थानिक प्रतीतून शाखेचा नवीन अग्रबिंदू जाहीर करू शकते.

पूर्ण प्रतिकृती ठेवल्याने वाचनाच्या विनंत्या स्थानिकरीत्या पूर्ण करता येतात. तसेच क्लायंटने कोणतीही प्रतिकृती निवडली तरी सर्व संदर्भांची सुसंगत स्थिती मिळण्याची हमी मिळते. परिणामी, संदर्भ एकावेळी एकच अद्यतनित होतात आणि प्रत्येक पुशसाठी प्रतिकृतींमधील संदर्भ-अद्यतनाचा समन्वय करण्याकरिता संदेशांच्या अनेक येण्या-जाण्याच्या फेऱ्या लागतात.

आवश्यक बहुमताची वाट पाहावी लागल्याने प्रतिकृतींच्या डिस्कची कामगिरी आणि संवादातील विलंब पुशच्या वेळेवर परिणाम करतात. लेखनाचे प्रमाण वाढते तसतसे, प्रतिकृतींना येणारे पॅक आणि वाचनाच्या विनंत्या दोन्हींचा वेग राखावा लागतो.

आम्ही अनुकरण केलेल्या WAL-आधारित रचनेत, संपूर्ण रिपॉझिटरीतील अद्यतनांचा क्रम ठरवण्यासाठी Git सेवा ब्लॉब संचयातील सामायिक मॅनिफेस्ट वापरते. सर्व्हरला पुश मिळाल्यावर, तो आलेली पॅकफाइल ब्लॉब संचयात अपलोड करतो आणि रिपॉझिटरीच्या स्थानिक प्रतीत संदर्भ-अद्यतन तयार करतो. पुश प्रकाशित करण्यासाठी तो ब्लॉब संचयातील सामायिक मॅनिफेस्टमध्ये एक नोंद जोडतो. ती संदर्भ-अद्यतन नोंदवते आणि पॅकफाइलकडे निर्देश करते. त्यानंतर Git सर्व्हर तुलना-आणि-बदल क्रियेद्वारे मॅनिफेस्ट अद्यतनित करतो. ही क्रिया मॅनिफेस्ट अविभाज्यपणे बदलते किंवा बदल नाकारते. दरम्यान दुसऱ्या लेखकाने ते अद्यतनित केले असल्यास, सर्व्हर मधल्या नोंदी वाचतो, स्वतःचे संदर्भ-अद्यतन अजूनही वैध असल्याचे तपासतो आणि आधी अपलोड केलेली पॅकफाइल वापरून पुन्हा प्रयत्न करतो.

लेखक त्यांच्या पॅकफाइल समांतरपणे अपलोड करू शकतात, पण असंबंधित शाखांतील पुशसाठीही त्याच मॅनिफेस्टचे अद्यतन आवश्यक असते. यशस्वी तुलना-आणि-बदलासाठी लागणारा येण्या-जाण्याचा वेळ, रिपॉझिटरी किती वारंवार नवीन मॅनिफेस्ट प्रकाशित करू शकते यावर मर्यादा घालतो. कमी विलंबाचा ब्लॉब संचय हा टप्पा वेगवान करतो. गट करून प्रक्रिया केल्याने एका मॅनिफेस्टद्वारे एकाच वेळी अनेक संदर्भ अद्यतनित करता येतात. मात्र अद्यतने रांगेत ठेवावी लागतात आणि विलंब वाढतो.

ब्लॉब संचय पॅकफाइल समांतरपणे स्वीकारू शकतो, पण सामायिक मॅनिफेस्टची अद्यतने तरीही एकमेकांशी स्पर्धा करतात. केवळ ब्लॉब संचयाची क्षमता वाढवल्याने हा अडथळा दूर होत नाही. प्रत्येक प्रतिकृतीला पॅक स्थानिकरीत्या पुरवण्याआधी ते ब्लॉब संचयातून वाचून अनुक्रमित करावेच लागतात. येणाऱ्या लेखनाचा वेग या कामापेक्षा जास्त झाल्यास, प्रतिकृती मागे पडतात आणि नुकतेच पुश केलेले कमिट मिळवण्यासाठी क्लायंटना जास्त वेळ थांबावे लागते.

याच ठिकाणी Pando महत्त्वाचे ठरते. Git रिपॉझिटरी उपलब्ध करून देण्यासाठी Pando ही नवी रचना आहे. एकाच वेळी पुश करणाऱ्या अनेक क्लायंटना सामावून घेण्यासाठी विस्तार करणे हे तिचे उद्दिष्ट आहे. ते असे कार्य करते:

Pando विकसित करण्यापूर्वी, Git बाबत तडजोड न करता आमच्या गरजा पूर्ण करता येतील असा आमचा अंदाज होता. मात्र, बहुतेक Git प्रणाली ज्या गोष्टी आवश्यक मानतात, त्यांपैकी काहींशी तडजोड करावी लागणार होती:

• संपूर्ण रिपॉझिटरीमध्ये सुसंगता: सर्व संदर्भांचे एका क्षणाचे सुसंगत स्थितिचित्र देण्यासाठी संपूर्ण रिपॉझिटरीत समन्वय आवश्यक असतो. सर्व संदर्भ-अद्यतनांचा एकत्र क्रम ठरवणाऱ्या प्रणालीत, असंबंधित शाखांवरील पुश एकाच समन्वय बिंदूसाठी स्पर्धा करतात.

• प्रत्येक क्लायंटसाठी स्वतंत्र पॅकफाइल: वेगवेगळा स्थानिक इतिहास असलेल्या दोन क्लायंटनी एकच शाखा मिळवल्यास, त्यांच्याकडे आधीच असलेले ऑब्जेक्ट पुन्हा पाठवणे टाळण्यासाठी सर्व्हरला प्रत्येकासाठी वेगळा पॅक तयार करावा लागू शकतो. हे प्रतिसाद तयार करण्यासाठी प्रोसेसरची क्षमता आणि डिस्कवरील वाचन-लेखनाचा खर्च येतो. त्यामुळे मोठ्या संख्येने वाचकांना सेवा देण्यासाठी विस्तार करणे कठीण होते.

त्याऐवजी, लेखनक्षमता वाढवण्यासाठी Pando शिथिल सुसंगतीची पद्धत (कारणात्मक सुसंगती) वापरते आणि वाचनक्षमता वाढवण्यासाठी पॅकफाइलचा पुनर्वापर करते.

क्लायंटने शाखेत पुश केल्यावर, Pando आलेली पॅकफाइल ब्लॉब संचयात अपरिवर्तनीय ब्लॉब म्हणून साठवते. शाखा पुढे सरकते तेव्हा Pando मेटाडेटा संचयात एक संदर्भ-आवृत्ती नोंदवते. त्यात नवीन अग्रबिंदू, तो पुरवणारा पॅक आणि त्या पॅकला आवश्यक असलेल्या आधीच्या संदर्भ-आवृत्त्या असतात. ब्लॉब संचय आणि मेटाडेटा संचय या दोन्हींची क्षमता अधिक यंत्रे जोडून वाढवता येते.

Pando मधून कमिट किंवा संदर्भ मिळवताना संदर्भ-आवृत्त्यांचा संच (पॅकफाइल) क्लायंटला पुन्हा पाठवावा लागतो. यातून मिळवल्या जाणाऱ्या संदर्भ-आवृत्तीच्या निर्मात्या क्लायंटची स्थिती पुन्हा उभी राहते. यामुळे संपूर्ण रिपॉझिटरीमध्ये तुलनेने कमी स्तराची सुसंगतता मिळते, तर स्वतंत्र रेफरन्समधील अपडेट्ससाठी क्रमबद्धता सुनिश्चित होते. एकाच संदर्भात एकाच वेळी पुश करतानाच क्लायंटमध्ये संघर्ष होतो. अनेक शाखा वाचणारा क्लायंट, त्या वाचनांतून संपूर्ण रिपॉझिटरीतील एकाच क्षणाची स्थिती दिसते असे गृहीत धरू शकत नाही.

हा कारणात्मक सुसंगतीचा एक प्रकार आहे. एखादा संदर्भ मिळवण्यासाठी, वाचक तो तयार करणाऱ्या लेखकाचा इतिहास पाहतो. पुशदरम्यान क्लायंट आणि सर्व्हर कोणता इतिहास सामायिक असल्याचे मान्य करतात, हे Pando नियंत्रित करते. त्यामुळे क्लायंटने तयार केलेल्या पॅकफाइल सहज सामायिक करता येतात.

परिणामी, Git क्रियांदरम्यान Pando सर्व संदर्भांची एका क्षणाची स्थिती देत नाही, तसेच क्लोन किंवा फेचमधील संदर्भ-अद्यतनांचा एकत्रित क्रमही देत नाही. उदाहरणार्थ, पूर्ण क्लोनसाठी देवाणघेवाणीची जुळवणी सुरू असताना foo आणि bar या दोन्ही शाखा अद्यतनित झाल्या असे समजा. जुळवणीदरम्यान एका क्लायंटला foo ची आवृत्ती 1 आणि bar ची आवृत्ती 2 दिसू शकते, तर दुसऱ्याला foo ची आवृत्ती 2 आणि bar ची आवृत्ती 1 दिसू शकते. प्रत्यक्षात वापरकर्ते आणि एजंट सर्व संदर्भ-अद्यतनांच्या एकत्रित क्रमावर अवलंबून नसतात; त्यांना एका संदर्भातील अद्यतनांचा क्रम महत्त्वाचा असतो.

तीन सुसंगती पद्धतींच्या या अनुकरणात आम्ही 1,000 क्लायंटपैकी प्रत्येकाला स्वतंत्र शाखा निवडून वारंवार वेगळे कमिट पुश करण्यासाठी संरचित करतो. यात एकूण प्रत्यक्ष कालावधी आणि पुशपासून फेचपर्यंतचा विलंब मोजतो. दुसरे मापन कार्यभारांसाठी महत्त्वाचे आहे. कारण वापरकर्ते व एजंट यांना सहयोग करताना किंवा आवृत्ती नियंत्रणावर अवलंबून इतर प्रणाली वापरताना लागणारा येण्या-जाण्याचा वेळ ते मोजते. या अनुकरणात सर्वसाधारण ते उच्च दर्जाची आभासी यंत्रे आणि ब्लॉब संचय प्रणाली अशा विविध हार्डवेअरचे प्रतिरूप वापरले आहे. या अनुकरणात तीन-टप्प्यातील कमिटसाठी आम्ही संपूर्ण रिपॉझिटरीतील सुसंगती शिथिल केली आहे.

अनुकरणातील तीन टप्प्यातील कमिट प्रणालीच्या डिस्कची क्षमता पूर्ण वापरली गेल्यामुळे भाराखाली लेखन-विलंब लक्षणीय वाढतो. त्याच कारणाने पूर्वलेखन नोंदवही प्रणालींमध्ये वाचन-विलंब लक्षणीय वाढतो, कारण सर्व्हरना नोंदवहीतील वाचनाचा वेग राखणे कठीण जाते. आमच्या एकत्रित रिपॉझिटरीवरील प्रत्यक्ष चाचण्यांमध्ये आणि या अनुकरणातही, भारामध्येही कामगिरीवर परिणाम न होता हजारो क्लायंट एकाच वेळी पुश करू शकतात, हे Pando ने दाखवले.

पुश हाताळताना Pando आलेली पॅकफाइल स्थानिक रिपॉझिटरीत उघडून न ठेवता, थेट ब्लॉब संचयाकडे प्रवाहित करतानाच तिची वैधता तपासते. क्लायंटने फेच सुरू केल्यावर Pando वाचकाला आवश्यक असलेले साठवलेले पॅक निवडते आणि वाचक ते डाउनलोड करतो. कोणत्याही सर्व्हरला स्थानिक रिपॉझिटरीत पॅकफाइल लागू करण्याची किंवा खर्चिक उघडणी व पुनर्बांधणी करण्याची गरज नसते. हे सर्व्हर प्रामुख्याने देवाणघेवाणीची जुळवणी आणि पॅकफाइलची निवड करत असल्याने Pando सर्व्हर सर्वसाधारण हार्डवेअरवर रन करू शकतात.

त्यामुळे क्लायंट, क्लायंट व Pando यांतील नेटवर्क आणि ब्लॉब संचय सेवा यांच्या क्षमतेच्या मर्यादेपर्यंत Pando चा विस्तार करता येतो. पुरेशी क्षमता असल्यास, स्वतंत्र शाखांवर काम करणारा प्रत्येक क्लायंट स्वतःच्या जोडणीच्या कमाल वेगाने पॅक हस्तांतरित करू शकतो. त्याच वेगाने अधिक क्लायंटना सेवा देण्यासाठी आम्ही Pando सर्व्हर जोडू शकतो आणि त्यासोबत मेटाडेटा व ब्लॉब संचयांची क्षमता वाढवू शकतो.

एजंट स्थानिक पातळीवर फाइल संपादित करून कमिट तयार करतो आणि git पुश चालवतो. त्यामुळे शाखा अद्यतनित करण्यासाठी त्या बदलांची पॅकफाइल तयार होते. Pando पॅक स्वीकारते आणि तो ब्लॉब संचयाकडे प्रवाहित करते. एकाच फेरीत डीकोड करून आलेल्या पुशची वैधता तपासल्यानंतर, Pando बहु-कळ व्यवहाराद्वारे आमच्या मेटाडेटा संचयात संदर्भ-आवृत्ती नोंदवते आणि संदर्भ-निर्देशक अविभाज्य क्रियेद्वारे अद्यतनित करते. यामुळे Pando “स्वतः लिहिलेले लगेच वाचता येणे” या स्वरूपाची सुसंगती देऊ शकते. या संपूर्ण लेखन क्रियेसाठी $O(1)$ मेटाडेटा वाचन व लेखन आवश्यक असते.

दुसरा क्लायंट शाखा मिळवतो तेव्हा, त्याच्याकडे आधीच असलेल्या इतिहासाच्या आधारे Pando साठवलेल्या पॅकचा संच निवडते. या क्रियेसाठी $O(\log \Delta)$ मेटाडेटा वाचन आवश्यक असते. येथे $\Delta$ म्हणजे क्लायंटकडे असलेली आणि त्याला हवी असलेली स्थिती यांतील संदर्भ-आवृत्त्यांमधील सर्वांत कमी अंतर. सर्व्हर पॅकफाइलचे URI परत देतो. क्लायंट Express या प्रादेशिक कॅशेमध्ये पॅकफाइल साठवणाऱ्या सेवेद्वारे त्या डाउनलोड करतो.

ही रचना Pando च्या स्थापत्यातील तीन प्रमुख सेवांवर अवलंबून आहे: पुश, फेच आणि कॉम्पॅक्शन.

क्लायंट पुश करतो तेव्हा पारंपरिक Git सर्व्हर सर्व पत्ते उघड करणाऱ्या पोकर खेळाडूसारखा वागतो: तो त्याच्याकडील प्रत्येक शाखा क्लायंटला दाखवतो. मग क्लायंट कमिट, ट्री आणि ब्लॉब एकत्र करून पॅकफाइल तयार करतो. यात सर्व्हरकडे आधीच असल्याचे त्याला माहीत असलेले ऑब्जेक्ट वगळलेले असतात.

अधिक संदर्भ जाहीर केल्यास पुशचा आकार लहान होऊ शकतो. पण त्यामुळे पॅकचा पुनर्वापर कठीणही होऊ शकतो, कारण लेखकाने वगळलेले ऑब्जेक्ट दुसऱ्या क्लायंटकडे नसू शकतात.

Pando वेगळी पद्धत वापरते. सर्व पत्ते उघड करण्याऐवजी, ते क्लायंटला केवळ निवडक शाखा जाहीर करते. हे दोन कारणांसाठी केले जाते:

1. प्रत्येक संदर्भाची सुसंगत स्थिती पुरवणे खर्चिक असते. लाखो शाखा असल्यास, संदर्भ जाहीर करणाऱ्या माहितीचाच आकार 100 MiB पेक्षा जास्त असू शकतो. ही माहिती देण्यासाठी प्रत्येक सर्व्हरला अद्ययावत जुळणी राखावी लागते, ज्यासाठी मोठा समन्वय खर्च येतो; किंवा संदर्भांच्या संख्येनुसार वाढणारी डेटाबेस विचारणा करावी लागते.

2. क्लायंटला संदर्भांचा फक्त उपसंच दिल्याने, तो तयार करत असलेला पॅक सर्व्हरने स्पष्टपणे वगळण्याची परवानगी दिलेल्या ऑब्जेक्टवरच अवलंबून राहतो. अवलंबित्वांचा मागोवा घेतल्याने, एका पुशमध्ये क्लायंटने तयार केलेली पॅकफाइल पुढील फेचच्या प्रतिसादात देऊन Pando तिचा पुनर्वापर करू शकते.

Git सर्व्हर अधिक संदर्भ जाहीर करतो तसतसे, पुश करणाऱ्या क्लायंटना ऑब्जेक्ट वगळण्यासाठी अधिक स्रोत मिळतात आणि ते लहान पॅक तयार करू शकतात. मात्र, या पॅकफाइल पुन्हा वापरण्यासाठी, फेच करणाऱ्या क्लायंटकडे प्रत्येक अवलंबित्व असल्याची खात्री सर्व्हरला करता आली पाहिजे. अन्यथा, क्लायंटला आवश्यक असलेले ऑब्जेक्ट पॅकफाइलमधून वगळले जाऊ शकतात.

दुसरीकडे, Git सर्व्हरने एकही संदर्भ जाहीर केला नाही, तर क्लायंट रिपॉझिटरीचा संपूर्ण इतिहास असलेली पॅकफाइल तयार करेल. ती पॅकफाइल इतर कोणताही क्लायंट वापरू शकतो. पण त्याची मोठी किंमत म्हणजे कोणतीही शाखा मिळवणे प्रत्यक्षात पूर्ण क्लोन करण्यासारखे होते.

मूलभूत सेटिंगनुसार, क्लायंट नवीन वैशिष्ट्य-शाखा पुश करतो तेव्हा Pando आधार म्हणून फक्त एक नियुक्त मुख्य शाखा जाहीर करते. त्यामुळे रिपॉझिटरीतील शाखा वाढल्या तरी जाहीर माहितीचा आकार तोच राहतो, पण त्यासाठी काही तडजोडी कराव्या लागतात. अभियंत्याने एकाच शाखेत अनेकदा पुश केले किंवा एका वैशिष्ट्य-शाखेवर दुसरी उभारली, तर क्लायंटला मुख्य शाखेबाहेरील सर्व काही पुन्हा पाठवावे लागते.

त्यामुळे शाखेतील पुढील पुश मोठे होतात, त्यांत कदाचित पुनरावृत्त ऑब्जेक्ट येतात आणि क्लायंटची अतिरिक्त बँडविड्थ वापरली जाते. आमच्या एकत्रित रिपॉझिटरीत अशा पॅकफाइलचा मध्यक आकार 20 KiB पेक्षा कमी होता आणि 99वे परेंटाइल 3 MiB पेक्षा कमी होते. आमच्यासाठी ही योग्य तडजोड होती, कारण जाहीर केलेल्या मुख्य शाखेचा इतिहास आधीच असलेला वाचक त्या एका पॅकफाइलमधून शाखा मिळवू शकतो.

क्लायंटला कोणते संदर्भ जाहीर करायचे ते निवडल्यानंतर, Pando पुश स्वीकारते आणि मेटाडेटा संचय अद्यतनित करते. Pando मेटाडेटा अद्यतनाचे समकालिक आणि असमकालिक भाग करते. समकालिक मेटाडेटा अद्यतनामुळे क्लायंटना नुकताच अद्यतनित झालेला कमिट लगेच मिळवता येतो. यात नवीन संदर्भ-आवृत्ती लिहिली जाते आणि संदर्भ-निर्देशक तिच्याकडे वळवला जातो. त्यात नवीन अग्रबिंदू, पॅकफाइलच्या जुळवणीसाठी वापरलेली अवलंबित्वे आणि पुश केलेल्या पॅकफाइलचा दुवा साठवला जातो.

त्याच वेळी त्याच व्यवहारात कॉम्पॅक्शनचे नियोजन यांसारखे असमकालिक कामही नोंदवले जाते. खूप मोठ्या पुशसाठी कमिटचा फक्त एक उपसंच समकालिकपणे लिहिला जातो. त्यामुळे पुशचा आकार कितीही असला तरी मेटाडेटा संचयातील वाचन-लेखनाची संख्या स्थिर ठेवता येते.

महत्त्वाचे म्हणजे, Pando सर्व्हर असंबंधित संदर्भांतील पुश स्वतंत्रपणे स्वीकारू शकतात. फक्त संदर्भ-निर्देशक या कळीवर स्पर्धा होते. आम्ही त्याचे संरक्षण तुलना-आणि-बदलासारख्या अविभाज्य क्रियेद्वारे करतो. Pando सर्व्हर, मेटाडेटा संचयाचे विस्तार घटक किंवा ब्लॉब संचय जोडून आम्ही लेखनाचा थ्रुपुट वाढवू शकतो.

क्लायंट फेच करतो तेव्हा तो सर्व्हरला कमिट ओळखचिन्हांचे दोन संच देतो. प्रोटोकॉलमध्ये त्यांना have आणि want असे म्हणतात. पारंपरिक Git सर्व्हर उपलब्ध कमिटमधून गाठता येणारे ऑब्जेक्ट आणि अपेक्षित कमिटमधून गाठता येणारे ऑब्जेक्ट यांतील संच-फरक मोजतो, ते ऑब्जेक्ट संकुचित करतो आणि क्लायंटला पाठवतो. ही क्रिया वेगवान करण्यासाठी मुक्त-स्रोत Git सर्व्हरकडे विविध स्थानिक अनुक्रमणिका असल्या तरी, या पॅकफाइल तयार करण्याचे संगणन खर्चिक असते आणि त्यांना कॅशेत ठेवून पुनर्वापर करणे सहसा कठीण असते.

त्याऐवजी, Pando पुशदरम्यान नोंदवलेल्या कमिट जुळण्या वापरून क्लायंटचे have आणि want शोधते आणि त्या कमिटचा समावेश असलेल्या संदर्भ-आवृत्त्यांचा संच ठरवते. यातील प्रत्येक संदर्भ-आवृत्ती Pando ला आधी मिळालेल्या पॅकफाइलशी जोडलेली असते. याच्या आधारे सर्व्हर क्लायंटला काय आवश्यक आहे ते ठरवतो आणि आवश्यक ऑब्जेक्टचा संच व्यापणाऱ्या पॅकफाइल निवडतो.

Git प्रोटोकॉल क्लोन किंवा फेचच्या HTTP प्रतिसादात फक्त एक पॅकफाइल पाठवण्याची परवानगी देतो. मात्र, Git प्रोटोकॉलमधील तुलनेने दुर्लक्षित packfile-uri वैशिष्ट्यामुळे सर्व्हर अतिरिक्त पॅक स्वतंत्रपणे डाउनलोड करण्यासाठी दुवे देऊ शकतो. Pando केवळ हीच पद्धत वापरते आणि प्रतिसादात एक रिकामी पॅकफाइल पाठवते. या वैशिष्ट्याला पाठबळ देण्यासाठी OpenAI ने मूळ प्रकल्पातील packfile-uri मध्ये अनेक सुधारणा केल्या.

OpenAI च्या प्रणाली अनेक भौगोलिक प्रदेशांत कार्य करतात. त्यामुळे आम्ही प्रत्येक प्रदेशात स्थानिक कॅशेसह Pando समूह राखतो. Express ही पॅक पुरवणारी सेवा आमच्या ब्लॉब संचयाची कॅशे राखते, तर एक स्वतंत्र सेवा मेटाडेटा संचयाची कॅशे राखते. या कॅशेमुळे Pando कमिट ओळखचिन्हाच्या किंवा संदर्भाच्या विशेष वाचनाच्या विनंत्या पूर्णपणे त्या समूहातील कॅशेमधील स्थितीतून पूर्ण करू शकते. पॅकफाइलच्या विनंत्या Express सर्व्हरकडे वळवण्यासाठी आम्ही सुसंगत हॅशिंग वापरतो. 99% पेक्षा जास्त वेळा आवश्यक डेटा कॅशेत मिळतो.

ही कॅशे व्यवस्था अत्यंत जास्त थ्रुपुट देते आणि क्लायंट व Pando यांमधील नेटवर्कची संपूर्ण क्षमता वापरू शकते. या पॅकफाइल URI आणि स्थानिक कॅशे वापरून, केवळ क्लाउड प्रदात्यांची सर्वसाधारण आभासी यंत्रे वापरतानाही क्लोन व फेच क्रिया 10 Gbps नेटवर्क जोडण्यांची संपूर्ण क्षमता वापरतात, हे आम्ही पडताळले आहे.

बहुतेक Git सर्व्हरमध्ये वाढत्या रिपॉझिटरीची कामगिरी राखण्यासाठी पुनर्पॅकिंग आणि अनावश्यक डेटा साफ करणे गरजेचे असते. या दोन्ही टप्प्यांत जागा मोकळी होते, पण त्यांना मोठ्या प्रमाणात संगणन आणि वाचन-लेखन लागते.

OpenAI च्या एकत्रित रिपॉझिटरीसारख्या झपाट्याने बदलणाऱ्या रिपॉझिटरीत, मागील फेचनंतरच्या प्रत्येक पुशसाठी वेगळा पॅकफाइल URI पाठवणे व्यवहार्य नाही. मुख्य शाखा अद्ययावत करण्यासाठी क्लायंटला दररोज दहा हजारो पॅकफाइल डाउनलोड कराव्या लागतील.

त्याऐवजी, हा अतिरिक्त भार कमी करण्यासाठी Pando पार्श्वभूमीत पॅक एकत्र करते. याची रचना नोंदाधारित विलीनीकरण-वृक्षांतील कॉम्पॅक्शनसारखी आहे. प्रत्येक पुशमधून Pando ज्याला “L0” म्हणते अशी पॅकफाइल तयार होते. Pando पाठवू शकणारे हे डेटाचे सर्वांत लहान एकक आहे. कालांतराने पार्श्वभूमीतील कार्यप्रक्रिया या पॅकफाइल संदर्भ-आवृत्त्यांचा क्रम व्यापणाऱ्या आवरणांत एकत्र करतात. ही आवरणे L0 पासून भूमितीय प्रमाणात वाढतात. सध्या आमची एकत्रित रिपॉझिटरी L4 पर्यंतची पॅकफाइल आवरणे वापरते.

ही आवरणे दोन उद्देश साधतात. आवरण पुरेसे भरल्यावर, कॉम्पॅक्शन कार्यप्रक्रिया त्याची जबाबदारी घेऊन एकच पॅकफाइल तयार करते. पॅकफाइलमधील ऑब्जेक्टची पुनर्रचना केल्याने संकुचनाचे प्रमाण सुधारते. तसेच संदर्भ-आवृत्त्यांवर उड्या मारता येणाऱ्या यादीसारखे काम करून ते फेचच्या जुळवणीची कामगिरीही सुधारते. प्रत्येक पातळीवरील अनुक्रमणिका एकाच वेळी तपासून, Pando क्लायंटला पाठवायचा पॅकचा संच लॉगरिदमिक वेळेत निवडू शकते. पुनर्पॅकिंग झाले असो वा नसो, ही पॅकफाइल आवरणे फेच नियोजन अधिक कार्यक्षम करतात आणि Pando वरील थ्रुपुट व विलंबविषयक गरजा कमी करतात.

अनेक Git सर्व्हरच्या विपरीत, येथे प्रत्येक पातळीवर पॅकफाइल ठेवल्या जातात; त्या टाकून दिल्या जात नाहीत किंवा अनावश्यक डेटा म्हणून साफ केल्या जात नाहीत. क्लायंट फेचमध्ये देतात त्या have आणि want च्या आधारे, प्रत्येक पातळीवरील पॅक सातत्याने सेवा देण्यासाठी वापरले जातात. Pando चा API म्हणून वापर करणाऱ्या क्लायंटना पॅकफाइलमधील कोणताही ऑब्जेक्ट वाचताना, L4 पेक्षा L0 मधून साधारणतः कमी डेटा वाचावा लागतो. कारण तो संकुचित असण्याची शक्यता कमी असते.

Pando मधील कॉम्पॅक्शन क्लायंटना पाठवला जाणारा एकूण डेटा लक्षणीयरीत्या कमी करते. तसेच क्लायंट जितका मागे आहे, त्या प्रमाणापेक्षा कमी दराने पॅक नियोजनाचा खर्च वाढू देते. मोठ्या आणि वेगाने बदलणाऱ्या रिपॉझिटरींसाठी हे विशेष महत्त्वाचे आहे. सॉफ्टवेअर विकासात अशा रिपॉझिटरी आता सर्वसामान्य होतील, अशी आमची अपेक्षा आहे.

आम्ही Codex च्या मदतीने Pando तयार केले आणि सुरुवातीपासून प्रत्यक्ष वापरापर्यंतचा टप्पा केवळ 10 आठवड्यांत गाठला. Pando च्या गाभ्याची रचना एका अभियंत्याने केली, एजंटच्या संघांनी ती अंमलात आणली आणि मोजक्या अभियंत्यांनी ती तैनात केली. या वर्षी एप्रिलमध्ये Pando ने प्रत्यक्ष वापरातील विनंत्या हाताळण्यास सुरुवात केली. OpenAI मध्ये वापरल्या जाणाऱ्या स्रोत नियंत्रण व्यवस्थापन साधनांच्या मोठ्या व्यवस्थेचा तो एक भाग आहे.

Pando च्या रचनेची पडताळणी करताना आम्ही अनेक विविध पद्धती वापरल्या. आम्ही अधिक सुरक्षित सॉफ्टवेअरचा पाया उभारण्याची⁠ आमची तत्त्वे लागू केली. हा पूर्णपणे नवा प्रकल्प असल्याने, आम्ही Pando हे Rust मध्ये आणि जुन्या प्रणालींच्या अवलंबित्वांशिवाय तयार करण्याचे ठरवले. एजंटना त्यांचे बदल Git च्या प्रमाणित वर्तनाशी पडताळता यावेत म्हणून आम्ही अनुरूपता चाचण्यांचा संच लिहिला. प्रणालीची अपरिवर्तनीय तत्त्वे आणि गुणधर्म तपासण्यासाठी आम्ही निर्धारक अनुकरण चाचणी हार्नेसही विकसित केले. त्यामुळे जुळवणी व पॅक नियोजनातील सूक्ष्म समवर्ती स्पर्धादोष आणि पूर्वीच्या कार्यक्षमतेतील बिघाड शोधून कमी करता आले.

अनेक मॉडेलनी या प्रणालीत योगदान दिले. नवीन मॉडेल उपलब्ध होत गेली तशी आम्ही Pando ची कामगिरी आणि विश्वसनीयता सुधारण्यासाठी ती वापरली. GPT‑6 Astra वापरून एजंटनी Lean आणि TLA+ मध्ये “Pando चा सिद्धांत” औपचारिकरीत्या मांडला. त्याच्या आधारे आम्ही अंमलबजावणीतील दोष शोधून दुरुस्त केले आणि प्रणालीचे गुणधर्म सिद्ध केले. Pando मधील अपवादात्मक परिस्थिती शोधून दुरुस्त करण्यासाठी अनेक अखंड सत्रे शेकडो तास चालली. Daybreak-सक्षम मॉडेल वापरून Git आणि Pando ची आक्रमकांच्या भूमिकेतून सुरक्षा तपासण्यासाठी आम्ही चोवीस तास एजंटही चालवतो.

सुरुवातीला आम्ही Pando आमच्या विद्यमान स्रोत नियंत्रण प्रणालीकडे वाचन आणि लेखन पुढे पाठवणारी मध्यस्थ प्रणाली म्हणून तैनात केले. यामुळे Pando आणि जुनी प्रणाली समक्रमित ठेवता आल्या. त्यामुळे सेवा बंद न ठेवता विनंत्या सुरक्षितपणे Pando कडे वळवता आल्या.

कॅशे रचनेचा भाग म्हणून, Pando विनंत्या पुढे पाठवण्याआधी त्यांतील पुनरावृत्ती काढून त्या एकत्रही करू शकते. यामुळे एकेक प्रणाली Pando वर हलवताना आमची विद्यमान साधने सुरळीत चालू ठेवता आली. अधिक कार्यभार Pando वर हलवले तसतसे, त्यांच्या पुशमुळे Pando ची कॅशे भरत गेली आणि आमच्या आधीच्या अंतर्गत प्रणालीची विश्वसनीयता सुधारली.

Pando वापरताना कामगिरी सर्वोत्तम ठेवण्यासाठी, आम्ही Git ची आमची सार्वजनिक वितरण आवृत्ती विकसकांच्या संगणकांवर आणि ChatGPT डेस्कटॉप ॲपमध्ये देऊ लागलो. क्लायंटना टप्प्याटप्प्याने Pando वर स्थलांतरित करण्यासाठी, आम्ही Git च्या आदेशपंक्ती अंतरफलकाभोवती अंतर्गत आवरण वापरले. बदलांच्या विनंत्या, कोड पुनरावलोकन आणि स्वयंचलनासाठी API हाताळणारी इतर अनेक साधने आम्ही तयार केली. Git वाहतुकीसोबतच, जुने API, वेबहुक आणि रिपॉझिटरी डाउनलोडवर अवलंबून असलेल्या शेकडो जोडण्या आम्ही स्थलांतरित केल्या.

हे स्थलांतर करण्यासाठी Codex नेच विकसकांना आणि संघांना मदत केली. विद्यमान कार्यप्रती तयार करण्यासाठी आणि एजंटना नवी प्रणाली वापरण्याचे मार्गदर्शन देण्यासाठी आम्ही कौशल्ये तयार केली. त्यामुळे विकसक आपली विकास वातावरणे आणि सेवा स्थलांतरित करण्यास थेट Codex ला सांगू शकत होते.

Pando वर गेल्याने विलीनीकरणाची विश्वसनीयता सुधारली आणि पुशचा मध्यक विलंब जवळपास 80% कमी झाला.

Pando केवळ मोजक्या प्रोसेसर कोअरच्या मदतीने दररोज एक पेटाबाइट Git डेटा पुरवू शकते. Pando ने एका तासात 57 टेराबाइटपेक्षा जास्त Git पॅक पुरवले आहेत. त्यातील 99% पेक्षा जास्त बाइट स्थानिक डिस्क कॅशेमधून आले.

पॅकचा पुनर्वापर केल्याने सेवा देणाऱ्या नोडवर अत्यल्प संगणन करून अनेक क्लायंटना रिपॉझिटरीचा समान इतिहास डाउनलोड करता येतो. या उदाहरणात एकच रिपॉझिटरी आहे, पण Pando ची रचना आणखी अनेक रिपॉझिटरींना आधार देण्यासाठी केली आहे. मागणी वाढल्यावर आम्ही डेटा पुरवठा आणि Git जुळवणी यांची क्षमता स्वतंत्रपणे वाढवू शकतो.

Git प्रोटोकॉल आणि क्लायंटवर Pando उभारल्याने आम्हाला Git मधील दोष आणि त्याची कामगिरी सुधारण्याच्या संधी ओळखता आल्या.

उदाहरणार्थ, Pando पुनर्वापरयोग्य पॅक थेट क्लायंटना देते. त्यामुळे ते पॅक डाउनलोड करणे आणि अनुक्रमित करणे हा प्रणाली वेगवान व विश्वसनीय करण्याचा मुख्य भाग ठरला. या कामातून समवर्ती डाउनलोड, मध्येच थांबलेल्या हस्तांतरणानंतरची साफसफाई आणि आधीच पूर्ण झालेले डाउनलोड पुन्हा सुरू करणे यांतील अपवादात्मक परिस्थिती समोर आल्या. आम्ही त्या कार्यप्रवाहांतील दोष दुरुस्त केले, फेचसाठी विद्यमान पॅक स्वीकारताना वैधता तपासण्या जोडल्या आणि हे काम मूळ प्रकल्पात योगदान म्हणून दिले.

वेळ आणि बँडविड्थ कुठे खर्च होत आहेत हेही पाहायचे होते. म्हणून आम्ही packfile-uri डाउनलोडचा मागोवा आणि पॅक निर्मितीतील बाइट मोजणी जोडली. त्यामुळे मंद फेचमध्ये वेळ पॅक बनवण्यात जातो की हस्तांतरणात, हे समजणे सोपे झाले.

OpenAI च्या Git आवृत्तीत⁠(नवीन विंडोमध्ये उघडेल) क्लायंट स्वतंत्र पॅक समांतरपणे डाउनलोड आणि अनुक्रमित करू शकतो. आम्ही “स्पष्टपणे नमूद उपलब्ध कमिट” ही संकल्पना जोडली. त्यामुळे पुश करणारा क्लायंट पॅकमधून वगळू शकतो त्या इतिहासापासून वेगळा, शाखेचा सध्याचा अग्रबिंदू सर्व्हर जाहीर करू शकतो. Pando वर यामुळे क्लायंटना --force-with-lease वापरून वैशिष्ट्य-शाखा बदललेली नाही हे तपासता येते आणि केवळ मुख्य शाखेच्या आधारे पॅक तयार करता येतो. मग मुख्य शाखेचा तो इतिहास असलेला कोणीही तोच पॅक वापरून शाखा मिळवू शकतो.

यांपैकी अनेक सुधारणा आधीच मूळ Git मध्ये आहेत आणि इतर अनेक आमच्या सार्वजनिक रिपॉझिटरीत आहेत. या सुधारणा Pando बाहेरही उपयुक्त ठराव्यात यासाठी आम्ही Git समुदायासोबत काम करत आहोत. या कामाचा मागोवा तुम्ही आमच्या सार्वजनिक पॅच मागोवा साधनात⁠(नवीन विंडोमध्ये उघडेल) घेऊ शकता.

Git रिपॉझिटरींचा विस्तार कसा करावा याविषयीच्या प्रचलित धारणांचा पुनर्विचार करून, Pando आम्हाला आमची एकत्रित रिपॉझिटरी वाढवू देते. त्यासाठी आमचे अभियंते आणि एजंट वापरत असलेल्या Git कार्यपद्धती बदलाव्या लागत नाहीत. आमच्या एकत्रित रिपॉझिटरीत Pando मुळे अधिक काम समांतरपणे करता येते, विलीनीकरणाची विश्वसनीयता सुधारली आहे आणि कोडमधील बदल प्रकाशित करण्याचा वेळ कमी झाला आहे. एकत्रित रिपॉझिटरीपलीकडे, OpenAI मध्ये Pando चे इतर उपयोगही आम्ही शोधत आहोत. यात मोठ्या संख्येने एजंटना सामायिक Git रिपॉझिटरीवर सहयोग करावा लागतो अशा कार्यभारांचाही समावेश आहे.

अभियंते आणि एजंट अधिक सॉफ्टवेअर तयार करू लागल्यावर, स्रोत नियंत्रणात आम्हाला आलेल्या मर्यादा OpenAI बाहेरील अधिक संघांनाही जाणवतील. आम्ही सध्या अशा मार्गांचा शोध घेत आहोत ज्याद्वारे Pando ज्या तंत्रज्ञानावर आधारित आहे, ते आमच्या वापरकर्त्यांसोबत शेअर करता येईल.

Git रिपॉझिटरींचे वापरकर्ते आणि चालक यांच्या दोन दशकांच्या अनुभवावर Pando उभे आहे. आम्ही Pando विकसित करत राहू आणि Git वापरकर्त्यांना व्यापकपणे उपयुक्त ठरणाऱ्या सुधारणा सामायिक करण्यासाठी मुक्त-स्रोत Git समुदायासोबत काम करू.