OpenAI میں Git کی گنجائش بڑھانا

گزشتہ سال کے دوران ہماری مونو ریپو کا حجم اور اس سے وابستہ تقاضے حیرت انگیز رفتار سے بڑھے ہیں. واضح تھا کہ Codex جتنے کام بیک وقت ممکن بناتا ہے، انہیں سنبھالنے کے لیے ہمیں اپنے سورس کنٹرول نظام کو ازسرنو بنانا ہوگا.

ہم نے انجینئرنگ کا کوئی کام روکے یا ٹیم کا Git استعمال کرنے کا طریقہ بدلے بغیر، Git ریپوزٹریوں کے لیے Pando نامی نیا پسِ منظر نظام بنایا. اب OpenAI کی مونو ریپو میں سافٹ ویئر سازی کا تمام کام Pando پر چلتا ہے. Pando دو بلند اہداف کے لیے بنایا گیا ہے: پہلا، مزید مشینیں شامل کرکے لکھنے کی گنجائش بڑھانا، خصوصاً بہت سی شاخوں پر بیک وقت پُش کے لیے. دوسرا، پڑھنے کا تھروپٹ زیادہ سے زیادہ کرنا، تاکہ کلائنٹس اتنی تیزی سے ڈیٹا ڈاؤن لوڈ کر سکیں کہ دستیاب نیٹ ورک بینڈوڈتھ پوری استعمال ہو.

ہم نے Git پروٹوکول اور کلائنٹ سے مطابقت برقرار رکھتے ہوئے یہ اہداف حاصل کیے، تاکہ ہمارے انجینئر اور ایجنٹس اپنے موجودہ طریقۂ کار میں آسانی سے Pando اپنا سکیں. عملی استعمال میں Pando نے پُش کی وسطانی تاخیر گھٹا کر تقریباً پانچواں حصہ کر دی. اب یہ روزانہ تقریباً ایک پیٹابائٹ Git ڈیٹا فراہم کرتا ہے.

یہاں ہم نیا سورس کنٹرول نظام بنانے کی وجوہ اور Git سے مطابقت برقرار رکھنے کے اپنے فیصلے پر بات کریں گے. ہم اپنے نظام کا Git کی گنجائش بڑھانے کے عام طریقوں سے موازنہ کریں گے، اور بتائیں گے کہ Pando کیوں OpenAI کی بڑھتی ضروریات پوری کرنے کی منفرد صلاحیت رکھتا ہے. ہم آئندہ اقدامات اور ایجنٹس کے پیمانے پر کام کو سہارا دینے کے لیے Git میں اپنی مسلسل شراکت پر بھی بات کریں گے.

Codex نے OpenAI میں سافٹ ویئر سازی کا پیمانہ اور رفتار بدل دی ہے، اور انجینئروں کو کہیں زیادہ کام متوازی طور پر کرنے کے قابل بنایا ہے. اس کا مطلب ہے زیادہ شاخیں اور پُش، زیادہ مرج، اور ترقیاتی ماحول، تحقیقی کاموں اور مسلسل انضمام کے نظام سے زیادہ فیچ اور کلون.

یہ تقاضے ایک دوسرے کے اثرات بڑھاتے ہیں. اب ایک انجینئر کی کئی تبدیلیاں بیک وقت مسلسل انضمام کے لیے تیار ہوتی ہیں، اور ہر پُش کئی کاموں کو ایک ہی کمٹ حاصل کرنے میں لگا سکتا ہے.

گزشتہ سال کے اواخر سے ہماری مونو ریپو کو چلانے والے نظام اس رفتار کا ساتھ دینے میں مشکل محسوس کرنے لگے. ہمیں سست فیچ اور پُش کے ساتھ ناکام مرج کا سامنا کرنا پڑا، اور کامیابی کی شرح کبھی کبھی 90% سے بھی نیچے گر گئی. کیا ہم خود Git کی حد تک پہنچ گئے تھے، یا اپنی مونو ریپو کو خدمات فراہم کرنے کے طریقے کی حد تک؟ Git ایک ایسی برادری سے ابھرا جو ای میل کے ذریعے کرنل کے پیچ کا تبادلہ کرتی تھی. دو دہائیوں سے زیادہ عرصے سے، سافٹ ویئر بنانے کے طریقے بدلنے کے ساتھ ڈویلپرز اپنے اوزار Git کے مطابق ڈھالتے رہے ہیں. جب ہمیں اپنی مونو ریپو میں رکاوٹیں محسوس ہونے لگیں، تو ہمارے لیے اہم تھا کہ ہم اسی کام کی بنیاد پر آگے بڑھ سکیں.

ہمیں ایسا راستہ نظر آیا جس میں مانوس طریقۂ کار برقرار رکھتے ہوئے پسِ منظر نظام کو ازسرنو بنایا جا سکتا تھا، تاکہ مختلف شاخوں کے پُش متوازی سنبھالے جائیں اور بہت سے کلائنٹس کو ایک ہی تاریخ بیک وقت فراہم کی جائے. Git کو اپنے سورس کنٹرول طریقۂ کار کی بنیاد رکھنے کا مطلب تھا کہ کلائنٹ کی بہتریاں OpenAI سے باہر بھی کارآمد ہو سکتی تھیں. ہم اپنے Git کے نسخے⁠(نئی ونڈو میں کھلتا ہے) کی یہ بہتریاں اصل منصوبے میں شامل کروانا چاہتے تھے، تاکہ وسیع تر برادری بھی ان سے فائدہ اٹھائے.

سورس کنٹرول نظام کی گنجائش بڑھانے کے دو بنیادی پہلو ہیں: بہت سے لکھنے والے کلائنٹس کا مختلف شاخوں پر پُش کرنا، اور بہت سے پڑھنے والے کلائنٹس کا ایک ہی تاریخ حاصل کرنا. Pando دونوں کے لیے بہتر بنایا گیا ہے.

اول، Pando ہر شاخ کی تازہ کاریوں کو الگ سے منظم کرتا ہے. غیر متعلق شاخوں کی تازہ کاریاں متوازی ہو سکتی ہیں، اور شاخ حاصل کرنے والے کلائنٹ کو اس ورژن کے لیے ضروری تاریخ مل جاتی ہے. اس کے بدلے یہ سمجھوتہ کرنا پڑتا ہے کہ کئی شاخیں دیکھنے والے کلائنٹ کو وہ مختلف اوقات کی حالت میں نظر آ سکتی ہیں.

دوم، Pando ہر کلائنٹ کے لیے الگ پیک فائل بنانے کے بجائے مختلف فیچ میں پیک فائلیں دوبارہ استعمال کرتا ہے. پیک فائل، کئی آبجیکٹس کو اکٹھا سکیڑنے کا Git فارمیٹ ہے. کلائنٹ کچھ ایسے آبجیکٹس بھی ڈاؤن لوڈ کر سکتا ہے جو اس کے پاس پہلے سے ہوں، مگر سرور بہت کم حسابی کام سے وہی بائٹس بہت سے کلائنٹس کو فراہم کر سکتا ہے.

ان فیصلوں کی بدولت ہم مختلف شاخوں پر لکھنے کی گنجائش بڑھا سکتے ہیں اور پڑھنے کی درخواستیں کیش سے پوری کر سکتے ہیں. یہ دونوں باتیں کیسے مل کر کام کرتی ہیں، اسے سمجھنے کے لیے پہلے دیکھتے ہیں کہ Git تاریخ کو کیسے محفوظ اور منتقل کرتا ہے.

Git کو ریپوزٹری کے دو حصے ہم آہنگ رکھنے ہوتے ہیں: آبجیکٹس اور حوالے.

Git ریپوزٹری فائلوں کی وقتی حالتیں اور انہیں جوڑنے والی تاریخ، آبجیکٹس کے گراف کی صورت میں درج کرتی ہے. آبجیکٹ ایک بلاب، ٹری، کمٹ یا ٹیگ ہو سکتا ہے. بلاب میں ایک فائل کا مواد ہوتا ہے، اور ٹری ناموں کو بلاب یا دوسرے ٹری سے جوڑ کر ڈائریکٹری کی ساخت بناتے ہیں. کمٹس ایک روٹ ٹری اور صفر یا زیادہ والد کمٹس کی طرف اشارہ کرتے ہیں، اور یوں آپ کی ریپوزٹری کی تاریخ بنتی ہے.

آبجیکٹس کی شناخت ان کی قسم اور مواد کے ہیش سے ہوتی ہے. آبجیکٹس ناقابلِ تبدیلی بھی ہوتے ہیں: تبدیل شدہ فائل درج کرنے پر نیا بلاب بنتا ہے، جبکہ غیر تبدیل شدہ فائلیں اور ڈائریکٹریاں موجودہ آبجیکٹس دوبارہ استعمال کر سکتی ہیں.

شاخیں اور ٹیگ ایسے حوالے، یا ”ریفس“، ہیں جو کمٹس کی طرف اشارہ کرتے ہیں. کسی شاخ پر کمٹ کرنے سے نیا کمٹ بنتا ہے اور شاخ کا حوالہ اس کی طرف اشارہ کرنے کے لیے تازہ ہوتا ہے.

Git آبجیکٹس کو ”الگ الگ“ یا ”پیک شدہ“ حالت میں محفوظ کرتا ہے. الگ آبجیکٹس انفرادی فائلوں میں محفوظ ہوتے ہیں جن کی شناخت ان کے آبجیکٹ آئی ڈی سے ہوتی ہے. پیک شدہ آبجیکٹس ایک پیک فائل میں اکٹھے محفوظ ہوتے ہیں، جس سے ملتے جلتے آبجیکٹس کو ایک دوسرے سے فرق کی صورت میں محفوظ کیا جا سکتا ہے.

Git میں کوئی آبجیکٹ کسی کمٹ سے قابلِ رسائی ہوتا ہے اگر Git اس کمٹ سے اس کے والد کمٹس, ٹری اور بلاب کے روابط پر چل کر اسے تلاش کر سکے. فیچ کے دوران کلائنٹ سرور کو بتاتا ہے کہ اسے کون سے کمٹس چاہئیں اور کون سے پہلے سے موجود ہیں. سرور مطلوبہ کمٹس سے قابلِ رسائی آبجیکٹس تلاش کرتا ہے, ان کو چھوڑتا ہے جن کے بارے میں اسے معلوم ہے کہ کلائنٹ کے پاس پہلے سے ہیں, اور باقی کو اسی فارمیٹ کی پیک فائل میں بھیجتا ہے جو Git ڈسک پر استعمال کرتا ہے. مکمل کلون کسی بھی آبجیکٹ کے بغیر شروع ہوتا ہے, اس لیے اسے کلون کی جانے والی ہسٹری سے قابلِ رسائی تمام آبجیکٹس چاہئیں.

پُش, سرور سے ایک یا زیادہ ریفرنسز کو اپ ڈیٹ اپ ڈیٹ کرنے کو کہہ کر آبجیکٹس مخالف سمت میں منتقل کرتا ہے. کلائنٹ سرور کے مشتہر کردہ حوالوں کی مدد سے ایسے آبجیکٹس بھیجنے سے گریز کرتا ہے جو سرور کے پاس پہلے سے ہیں. اس لیے بھیجا جانے والا پیک موجودہ آبجیکٹس پر منحصر ہو سکتا ہے: نئی ہسٹری دوبارہ بنانے کے لیے صرف پیک وصول کرنا کافی نہیں.

Git ریپوزٹری کی نقلیں رکھنے کا مطلب ہے کہ آبجیکٹس اور حوالے, دونوں کئی سروروں پر دستیاب رہیں. نقل رکھنے والا سرور کسی حوالے کی نئی قدر فراہم کرنے سے پہلے اس قدر سے قابلِ رسائی آبجیکٹس فراہم کرنے کے قابل ہونا چاہیے. سروس کو متصادم حوالے کی اپ ڈیٹس میں بھی ہم آہنگی پیدا کرنی ہوتی ہے, یعنی ایسے پُش جو ایک ہی برانچ کو اسی پرانے آخری کمٹ سے مختلف نئے کمٹس کی طرف بڑھانا چاہیں. ریپوزٹری میں لکھنے کی تمام کارروائیوں پر ایک ہی ترتیب نافذ کرنے والے سسٹم غیر متعلق برانچز کے پُش کو بھی ایک دوسرے کا انتظار کروا سکتے ہیں.

Pando کے ڈیزائن کے دوران ہم نے Git سے سورس کنٹرول کی گنجائش بڑھانے کے روایتی طریقے جانچے: ایک میں تین مرحلہ کمٹ (3PC, کئی نوڈز میں کمٹ کو ہم آہنگ کرنے کا پروٹوکول) سے ریپوزٹری کی نقلوں میں ریفرنسز اپ ڈیٹ ہوتے ہیں؛ دوسرے میں بلاب اسٹوریج کے شیئر کردہ پیشگی اندراج والے لاگ (WAL, تبدیلیاں لاگو کرنے سے پہلے لکھا جانے والا ریکارڈ) سے اپ ڈیٹس کی ترتیب طے ہوتی ہے.

تین مرحلہ کمٹ کے جس ڈیزائن کا ہم نے نمونہ بنایا, اس میں Git سروس کئی نقل رکھنے والے سروروں پر پوری ریپوزٹری رکھتی ہے. جب کسی سرور کو پُش ملتا ہے, تو آنے والی پیک فائل کی نقل بنا کر تمام نقل رکھنے والے سروروں کو متوازی طور پر بھیجی جاتی ہے. پُش شائع کرنے کے لیے زیادہ تر نقل رکھنے والے سروروں کو حوالے کی اپ ڈیٹ قبول کرنی ہوتی ہے. یہ عمل سنبھالنے والا سرور رابطہ کار ہوتا ہے, اور اسے ہر دوسرے نقل رکھنے والے سرور کے ساتھ کئی دور کا تبادلہ کرنا پڑتا ہے.

حوالے کی اپ ڈیٹ قبول کرنے کے لیے ہر نقل رکھنے والا سرور اپنے حوالے کو مقفل کرتا ہے اور جانچتا ہے کہ وہ اب بھی اسی کمٹ کی طرف اشارہ کرتا ہے جس کی کلائنٹ کو توقع ہے. پھر رابطہ کار قبول کرنے والے سروروں کو پیشگی کمٹ کا میسج بھیجتا ہے. جب اکثریت پیشگی کمٹ کے میسج کی تصدیق کر دیتی ہے, تو رابطہ کار انہیں اپ ڈیٹ انجام دینے کو کہتا ہے. اس کے بعد کوئی بھی تازہ ترین نقل رکھنے والا سرور ریپوزٹری کی اپنی مقامی نقل سے برانچ کا نیا آخری کمٹ مشتہر کر سکتا ہے.

مکمل نقلیں رکھنے سے پڑھنے کی درخواستیں مقامی طور پر پوری ہو سکتی ہیں, اور کلائنٹس کو تمام حوالوں کی یکساں حالت ملنے کی ضمانت ہوتی ہے, چاہے وہ کوئی بھی نقل منتخب کریں. نتیجتاً حوالے ایک ایک کرکے اپ ڈیٹ ہوتے ہیں, اور ہر پُش کے لیے نقلوں میں حوالے کی اپ ڈیٹ کو ہم آہنگ کرنے کے کئی تبادلے درکار ہوتے ہیں.

مطلوبہ اکثریت کا انتظار کرنے سے نقل رکھنے والے سروروں کی ڈسک کارکردگی اور رابطے کی تاخیر, پُش کے وقت پر اثر ڈالتی ہیں. لکھنے کا حجم بڑھنے پر نقل رکھنے والے سروروں کو آنے والے پیک اور پڑھنے کی ٹریفک, دونوں کا ساتھ دینا ہوتا ہے.

WAL پر مبنی جس ڈیزائن کا ہم نے نمونہ بنایا, اس میں Git سروس بلاب اسٹوریج میں شیئر کردہ مینفیسٹ سے پوری ریپوزٹری کی اپ ڈیٹس کی ترتیب طے کرتی ہے. سرور کو پُش ملنے پر وہ آنے والی پیک فائل بلاب اسٹور میں اپ لوڈ کرتا ہے اور ریپوزٹری کی مقامی نقل میں حوالے کی اپ ڈیٹ تیار کرتا ہے. پُش شائع کرنے کے لیے وہ بلاب اسٹور میں محفوظ شیئر کردہ مینفیسٹ میں ایک اندراج شامل کرتا ہے, جو حوالے کی اپ ڈیٹ درج کرتا اور پیک فائل کی طرف اشارہ کرتا ہے. پھر Git سرور تقابل کرکے بدلنے کی کارروائی سے مینفیسٹ اپ ڈیٹ کرتا ہے. یہ مینفیسٹ کو ایک ناقابلِ تقسیم کارروائی میں بدلتا ہے, یا تبدیلی مسترد کر دیتا ہے. اگر اسی دوران کسی اور نے اسے اپ ڈیٹ کر دیا ہو, تو سرور درمیان کے اندراجات پڑھتا ہے, جانچتا ہے کہ اس کی حوالے کی اپ ڈیٹ اب بھی درست ہے, اور پہلے اپ لوڈ کردہ پیک فائل سے دوبارہ کوشش کرتا ہے.

لکھنے والے کلائنٹس پیک فائلیں متوازی اپ لوڈ کر سکتے ہیں, مگر غیر متعلق برانچز کے پُش کے لیے بھی اسی مینفیسٹ کو اپ ڈیٹ کرنا ہوتا ہے. تقابل کرکے بدلنے کی کامیاب کارروائی کے درخواست و جواب کا وقت محدود کرتا ہے کہ ریپوزٹری کتنی کثرت سے نیا مینفیسٹ شائع کر سکتی ہے. کم تاخیر والا بلاب اسٹور یہ مرحلہ تیز بنا دیتا ہے. گروہ بندی سے ایک مینفیسٹ کئی حوالے بیک وقت اپ ڈیٹ کر سکتا ہے, مگر اس کے بدلے اپ ڈیٹس قطار میں لگتی ہیں اور تاخیر بڑھتی ہے.

بلاب اسٹور پیک فائلیں متوازی وصول کر سکتا ہے, مگر شیئر کردہ مینفیسٹ کی اپ ڈیٹس اب بھی ایک دوسرے کی راہ روکتی ہیں. صرف بلاب اسٹور کی گنجائش بڑھانے سے یہ رکاوٹ دور نہیں ہوتی. ہر نقل رکھنے والے سرور کو مقامی طور پر پیک فراہم کرنے سے پہلے اب بھی انہیں بلاب اسٹور سے پڑھنا اور ان کے اشاریے بنانے ہوتے ہیں. اگر آنے والے لکھنے کے کام اس رفتار سے بڑھ جائیں, تو نقلیں پیچھے رہ جاتی ہیں اور کلائنٹس کو نئے پُش شدہ کمٹس حاصل کرنے کے لیے زیادہ انتظار کرنا پڑتا ہے.

یہیں سے بات Pando تک پہنچتی ہے. Pando, Git ریپوزٹریوں کو سروسز فراہم کرنے کا نیا طرزِ تعمیر ہے, جس کا مقصد بیک وقت پُش کرنے والے بہت سے کلائنٹس کو سنبھالنے کی گنجائش پیدا کرنا ہے. یہ اس طرح کام کرتا ہے:

Pando بنانے سے پہلے ہمیں اندازہ تھا کہ ہم Git پر سمجھوتہ کیے بغیر اپنی ضروریات پوری کر سکتے ہیں, لیکن ہمیں کچھ ایسی باتوں پر سمجھوتہ کرنا پڑا جنہیں زیادہ تر Git سسٹمز لازمی تقاضے سمجھتے ہیں:

• پوری ریپوزٹری میں یکسانیت: تمام حوالوں کا کسی مخصوص وقت کا یکساں اسنیپ شاٹ فراہم کرنے کے لیے پوری ریپوزٹری میں ہم آہنگی درکار ہوتی ہے. جو سسٹم تمام حوالوں کی اپ ڈیٹس کو ایک مشترکہ ترتیب دیتا ہے, اس میں غیر متعلق برانچز کے پُش بھی ہم آہنگی کے ایک ہی مقام پر ایک دوسرے کی راہ روکتے ہیں.

• ہر کلائنٹ کے لیے الگ پیک فائلیں: اگر مختلف لوکل ہسٹریز رکھنے والے دو کلائنٹس ایک ہی برانچ کو فیچ کریں, تو سرور کو ہر ایک کے لیے الگ پیک بنانا پڑ سکتا ہے, تاکہ انہیں وہ آبجیکٹس نہ بھیجے جائیں جو ان کے پاس پہلے سے ہیں. یہ جوابات بنانے میں سی پی یو اور ڈسک I/O صرف ہوتی ہے, جس سے بڑی تعداد میں ریڈرز کو سروس فراہم کرنے کے لیے سسٹم کو اسکیل کرنا مشکل ہو جاتا ہے.

اس کے بجائے, Pando رائٹس کو اسکیل کرنے کے لیے نسبتاً نرم کنسسٹنسی ماڈل (کازَل کنسسٹنسی) فراہم کرتا ہے, جبکہ ریڈز کو اسکیل کرنے کے لیے پیک فائلز کو دوبارہ استعمال کرتا ہے.

جب کوئی کلائنٹ کسی برانچ پر پُش کرتا ہے, تو Pando آنے والی پیک فائل کو بلاب اسٹور میں ایک ناقابلِ تبدیلی بلاب کے طور پر محفوظ کرتا ہے. جب بھی برانچ آگے بڑھتی ہے, Pando میٹاڈیٹا اسٹور میں ایک ریفرنس ورژن درج کرتا ہے, جس میں نیا آخری کمٹ, اسے فراہم کرنے والا پیک, اور وہ سابقہ ریفرنس ورژنز شامل ہوتے ہیں جن پر پیک انحصار کرتا ہے. بلاب اسٹور اور میٹاڈیٹا اسٹور, دونوں کی گنجائش مزید مشینیں شامل کرکے بڑھائی جا سکتی ہے.

Pando سے کوئی کمٹ یا حوالہ حاصل کرنے کے لیے کلائنٹ کو حوالوں کے ورژنز (پیک فائلوں) کا ایک مجموعہ دوبارہ فراہم کرنا ہوتا ہے, جس سے اس کلائنٹ کی حالت بحال ہوتی ہے جس نے حاصل کیا جانے والا حوالہ ورژن بنایا تھا. اس سے پوری ریپوزٹری میں نسبتاً کم سخت یکسانیت ملتی ہے, جبکہ انفرادی حوالوں کی اپ ڈیٹس کے لیے ایسا نتیجہ یقینی ہوتا ہے جیسے وہ سلسلہ وار ہوئی ہوں. کلائنٹس میں ٹکراؤ صرف تب ہوتا ہے جب وہ بیک وقت ایک ہی حوالے پر پُش کریں. کئی برانچز پڑھنے والا کلائنٹ یہ فرض نہیں کر سکتا کہ ان سب سے ریپوزٹری کی کسی ایک وقت کی حالت ظاہر ہوتی ہے.

یہ کازَل کنسسٹنسی کی ایک شکل ہے. کسی حوالے کو حاصل کرنے کے لیے پڑھنے والا کلائنٹ اسے بنانے والے کلائنٹ کی ہسٹری دیکھتا ہے. پُش کے دوران Pando طے کرتا ہے کہ کلائنٹ اور سرور کس شیئر کردہ ہسٹری پر متفق ہوں, تاکہ کلائنٹس ایسی پیک فائلیں بنائیں جنہیں شیئر کرنا زیادہ آسان ہو.

نتیجتاً, Pando نہ تو Git کارروائیوں کے دوران تمام حوالوں کی کسی ایک وقت کی حالت فراہم کرتا ہے, نہ کلون یا فیچ کے اندر حوالوں کی اپ ڈیٹس کی ترتیب. مثلاً فرض کریں کہ مکمل کلون کے ابتدائی تبادلے کے دوران foo اور bar, دونوں برانچز اپ ڈیٹ کی جاتی ہیں. اس تبادلے کے دوران ایک کلائنٹ کو foo کا ورژن 1 اور bar کا ورژن 2 نظر آ سکتا ہے, جبکہ دوسرے کو foo کا ورژن 2 اور bar کا ورژن 1 نظر آئے. عملی طور پر صارفین اور ایجنٹس حوالوں کی اپ ڈیٹس کی مجموعی ترتیب پر انحصار نہیں کرتے, بلکہ کسی ایک حوالے کی اپ ڈیٹس کی ترتیب پر انحصار کرتے ہیں.

یکسانیت کے ان تین ماڈلز کی سیمولیشن میں ہم 1,000 کلائنٹس کو اس طرح ترتیب دیتے ہیں کہ ہر ایک الگ برانچ منتخب کرے اور پھر بار بار منفرد کمٹس پُش کرے. ہم کل گزرا ہوا وقت اور پُش سے فیچ تک کی تاخیر ناپتے ہیں. دوسرا پیمانہ کام کے بوجھ کے لیے اہم ہے, کیونکہ یہ صارفین اور ایجنٹس کے باہمی تعاون, یا ورژن کنٹرول پر منحصر دوسرے سسٹمز کے استعمال میں, درخواست اور جواب کے کل وقت کی پیمائش کرتا ہے. یہ سیمولیشن عام سے اعلیٰ درجے کی ورچوئل مشینوں اور بلاب ذخیرہ سسٹمز تک مختلف ہارڈویئر کی نمائندگی کرتی ہے. اس سیمولیشن میں ہم نے تین مرحلہ کمٹ کے لیے پوری ریپوزٹری میں یکسانیت کی شرط نرم کی ہے.

تین مرحلہ کمٹ کے نمونے میں بوجھ بڑھنے پر ڈسکیں اپنی حد تک پہنچ جاتی ہیں اور لکھنے میں نمایاں طور پر زیادہ تاخیر ہوتی ہے. اسی وجہ سے پیشگی اندراج والے لاگ کے سسٹمز میں پڑھنے کی تاخیر نمایاں بڑھتی ہے, کیونکہ سرور لاگ سے پڑھنے کی رفتار برقرار نہیں رکھ پاتے. ہماری مونو ریپو پر حقیقی دنیا میں کیے گئے ٹیسٹس اور اس سیمولیشن, دونوں میں Pando کئی ہزار کلائنٹس کو بیک وقت پُش کرنے کی سہولت دیتا ہے, اور اس دوران بوجھ کے تحت کارکردگی متاثر نہیں ہوتی.

پُش ہینڈل کرتے وقت Pando آنے والی پیک فائل کو بلاب اسٹوریج میں مسلسل منتقل کرتے ہوئے جانچتا ہے, اسے مقامی ریپوزٹری میں کھولے بغیر. جب کلائنٹ فیچ شروع کرتا ہے تو Pando اس کے مطلوبہ محفوظ پیک منتخب کرتا ہے, اور کلائنٹ انہیں ڈاؤن لوڈ کر لیتا ہے. کسی سرور کو پیک فائلیں مقامی ریپوزٹری پر لاگو کرنے یا انہیں کھولنے اور دوبارہ پیک کرنے کی مہنگی کارروائیوں کی ضرورت نہیں ہوتی. چونکہ یہ سرور بنیادی طور پر ابتدائی تبادلہ اور پیک فائلوں کا انتخاب کرتے ہیں, اس لیے Pando کے سرور عام دستیاب ہارڈویئر پر چل سکتے ہیں.

اس سے Pando کلائنٹس, کلائنٹس اور Pando کے درمیان نیٹ ورک, اور بلاب اسٹوریج سروس کی حدود تک اپنی گنجائش بڑھا سکتا ہے. مناسب گنجائش ہو تو آزاد برانچز پر کام کرنے والا ہر کلائنٹ اپنے کنکشن کی زیادہ سے زیادہ رفتار سے پیک منتقل کر سکتا ہے. اسی رفتار سے مزید کلائنٹس کو سروس فراہم کرنے کے لیے ہم Pando سرور بڑھا سکتے ہیں اور ان کے ساتھ میٹاڈیٹا اسٹور اور بلاب اسٹور کی گنجائش بھی بڑھا سکتے ہیں.

ایک ایجنٹ مقامی طور پر فائلوں میں ترمیم کرکے کمٹ بناتا ہے اور git push چلاتا ہے, جو برانچ کو اپ ڈیٹ کرنے کے لیے ان تبدیلیوں کی پیک فائل بناتا ہے. Pando پیک وصول کرکے اسے مسلسل بلاب اسٹوریج میں منتقل کرتا ہے. آنے والے پُش کو ایک ہی بار ڈی کوڈ کرکے جانچنے کے بعد, Pando متعدد کلیدوں والا لین دین استعمال کرتا ہے, تاکہ ہمارے میٹاڈیٹا اسٹور میں ریفرنس ورژن درج کرے اور حوالے کے پوائنٹر کو ایک ناقابلِ تقسیم کارروائی میں اپ ڈیٹ کرے. اس سے Pando ”اپنا لکھا ہوا خود پڑھ سکنے“ کی یکسانیت فراہم کر پاتا ہے. لکھنے کی اس پوری کارروائی میں میٹاڈیٹا کو پڑھنے اور لکھنے کی $O(1)$ کارروائیاں درکار ہوتی ہیں.

جب کوئی دوسرا کلائنٹ برانچ حاصل کرتا ہے, تو Pando اس کے پاس پہلے سے موجود ہسٹری کی بنیاد پر محفوظ پیک کا مجموعہ منتخب کرتا ہے. اس کارروائی میں میٹاڈیٹا کو $O(\log \Delta)$ بار پڑھنا ہوتا ہے, جہاں $\Delta$ کلائنٹ کی موجودہ اور مطلوبہ حالت کے درمیان حوالے کے ورژنز میں کم ترین فاصلہ ہے. سرور پیک فائلوں کے یو آر آئی واپس کرتا ہے, اور کلائنٹ انہیں Express نامی سروس سے ڈاؤن لوڈ کرتا ہے, جو پیک فائلیں علاقائی کیش میں محفوظ رکھتی ہے.

یہ ڈیزائن Pando کے فنِ تعمیر کی تین مرکزی خدمات پر منحصر ہے: پُش, فیچ اور کمپیکشن.

کلائنٹ کے پُش کرنے پر روایتی Git سرور پوکر کے اس کھلاڑی کی طرح ہوتا ہے جو اپنے سارے پتے دکھا دے: وہ کلائنٹ کو اپنی ہر برانچ بتا دیتا ہے. پھر کلائنٹ کمٹس, ٹری اور بلاب جمع کرکے ایسی پیک فائل بناتا ہے جو ان آبجیکٹس کو شامل نہیں کرتی جن کے بارے میں اسے معلوم ہو کہ وہ سرور کے پاس پہلے سے ہیں.

زیادہ حوالے مشتہر کرنے سے پُش کا حجم کم ہو سکتا ہے. اس سے پیک کا دوبارہ استعمال مشکل بھی ہو سکتا ہے, کیونکہ دوسرے کلائنٹ کے پاس وہ آبجیکٹس شاید نہ ہوں جنہیں لکھنے والے نے چھوڑ دیا تھا.

Pando مختلف طریقہ اپناتا ہے. تمام پتے دکھانے کے بجائے, یہ کلائنٹ کو صرف چند منتخب برانچز کی اطلاع دیتا ہے. اس کی دو وجوہ ہیں:

1. ہر حوالے کی یکساں حالت فراہم کرنا مہنگا پڑتا ہے. لاکھوں برانچز کی صورت میں صرف حوالوں کی اطلاع کا حجم 100 میبی بائٹ سے زیادہ ہو سکتا ہے. اس کے لیے ہر سرور کو یا تو تازہ نقشہ برقرار رکھنا پڑتا ہے, جس میں ہم آہنگی کا خاصا اضافی بوجھ ہوتا ہے, یا ڈیٹابیس سے ایسی دریافت کرنی پڑتی ہے جس کا کام حوالوں کی تعداد کے ساتھ بڑھتا ہے.

2. کلائنٹ کو صرف کچھ حوالے بتانے سے وہ ایسا پیک بناتا ہے جس کا انحصار صرف اسی مواد پر ہو جسے چھوڑنے کی سرور واضح اجازت دیتا ہے. انحصاری تعلقات کا ریکارڈ رکھنے سے Pando کسی پُش میں کلائنٹ کی بنائی پیک فائل کو بعد کے فیچ کے جواب میں فراہم کرکے دوبارہ استعمال کر سکتا ہے.

Git سرور جتنے زیادہ حوالے مشتہر کرتا ہے, پُش کرنے والے کلائنٹس کے پاس آبجیکٹس چھوڑنے کے اتنے زیادہ ماخذ ہوتے ہیں, جس سے وہ چھوٹے پیک بنا سکتے ہیں. البتہ ان پیک فائلوں کے دوبارہ استعمال کے لیے سرور کو تصدیق کرنا ہوتی ہے کہ فیچ کرنے والے کلائنٹس کے پاس انحصار کے لیے درکار ہر چیز موجود ہے. ورنہ پیک فائل میں ایسے آبجیکٹس غائب ہو سکتے ہیں جن کی کلائنٹ کو ضرورت ہے.

دوسری طرف, اگر Git سرور کوئی حوالہ مشتہر نہ کرے, تو کلائنٹ ریپوزٹری کی مکمل ہسٹری پر مشتمل پیک فائل بنائے گا. وہ پیک فائل کوئی بھی دوسرا کلائنٹ استعمال کر سکتا ہے, مگر اس کی بڑی قیمت یہ ہے کہ کسی بھی برانچ کو حاصل کرنا عملاً مکمل کلون بن جاتا ہے.

پہلے سے طے شدہ طریقے کے مطابق, جب کلائنٹ نئی فیچر برانچ پُش کرتا ہے, تو Pando بنیاد کے طور پر صرف ایک مقررہ ٹرنک مشتہر کرتا ہے. اس سے ریپوزٹری میں برانچز بڑھنے کے باوجود اطلاع کا حجم یکساں رہتا ہے, مگر کچھ سمجھوتے کرنے پڑتے ہیں. جب انجینئر ایک ہی برانچ پر بار بار پُش کرتا ہے, یا ایک فیچر برانچ کے اوپر دوسری بناتا ہے, تو کلائنٹ کو ٹرنک سے باہر کا تمام مواد دوبارہ بھیجنا پڑتا ہے.

اس سے برانچ کے یکے بعد دیگرے پُش کا حجم بڑھتا ہے, ان میں ممکنہ طور پر غیر ضروری دہرائے گئے آبجیکٹس آتے ہیں, اور کلائنٹ کی اضافی بینڈوڈتھ صرف ہوتی ہے. ہماری مونو ریپو میں اس طرح بنی پیک فائلوں کا وسطانی حجم 20 کیبی بائٹ سے کم تھا, اور 99 واں پرسنٹائل 3 MiB سے کم تھا. ہمارے لیے یہ مناسب سمجھوتہ تھا, کیونکہ مشتہر کردہ ٹرنک کی ہسٹری رکھنے والا کلائنٹ اسی ایک پیک فائل سے برانچ حاصل کر سکتا ہے.

کلائنٹ کو مشتہر کرنے کے لیے حوالے منتخب کرنے کے بعد, Pando پُش قبول کرتا ہے اور اپنا میٹاڈیٹا اسٹور اپ ڈیٹ کرتا ہے. Pando میٹاڈیٹا کی اپ ڈیٹ کو ہم وقتی اور غیر ہم وقتی حصوں میں تقسیم کرتا ہے. ہم وقتی اپ ڈیٹ یقینی بناتی ہے کہ کلائنٹس فوراً نیا اپ ڈیٹ شدہ کمٹ حاصل کر سکیں. اس میں حوالے کا نیا ورژن لکھا جاتا ہے اور پوائنٹر کا نقشہ اس کی طرف اپ ڈیٹ کیا جاتا ہے. اس ورژن میں نیا آخری کمٹ, پیک فائل طے کرنے میں استعمال شدہ انحصاری تعلقات, اور پُش کی گئی پیک فائل کا ربط محفوظ ہوتا ہے.

ساتھ ہی اسی لین دین میں غیر ہم وقتی کام بھی درج ہوتا ہے, مثلاً کمپیکشن کا وقت مقرر کرنا. بہت بڑے پُش میں صرف کچھ کمٹس ہم وقتی طور پر لکھے جاتے ہیں. اس سے پُش کا حجم کچھ بھی ہو, میٹاڈیٹا اسٹور کو پڑھنے اور لکھنے کی کارروائیوں کی تعداد مستقل رہتی ہے.

اہم بات یہ ہے کہ Pando سرور غیر متعلق حوالوں کے پُش آزادانہ قبول کر سکتے ہیں. صرف حوالے کے پوائنٹر کی کلید پر ٹکراؤ ہو سکتا ہے, جسے ہم تقابل کرکے بدلنے جیسی ناقابلِ تقسیم کارروائی سے محفوظ رکھتے ہیں. ہم Pando سرور, میٹاڈیٹا اسٹور کی اضافی اکائیاں یا بلاب اسٹور شامل کرکے لکھنے کا تھروپٹ بڑھا سکتے ہیں.

فیچ کرتے وقت کلائنٹ سرور کو کمٹ آئی ڈیز کے دو مجموعے دیتا ہے, جنہیں پروٹوکول میں haves اور wants کہا جاتا ہے. روایتی Git سرور موجود کمٹس سے قابلِ رسائی آبجیکٹس اور مطلوبہ کمٹس سے قابلِ رسائی آبجیکٹس کے مجموعوں کا فرق نکالتا ہے, انہیں سکیڑتا ہے, اور نتیجہ کلائنٹ کو بھیجتا ہے. اوپن سورس Git سرور کے پاس اس کارروائی کو تیز کرنے کے لیے کئی مقامی اشاریے ہوتے ہیں, لیکن ان پیک فائلوں کو بنانے میں خاصا حسابی کام لگ سکتا ہے اور عموماً انہیں کیش میں مؤثر طور پر رکھنا مشکل ہوتا ہے.

اس کے بجائے Pando پُش کے وقت درج کیے گئے کمٹ نقشوں سے کلائنٹ کے haves اور wants تلاش کرتا ہے, اور انہیں حوالوں کے ایسے ورژنز کے مجموعے سے جوڑتا ہے جن میں وہ کمٹس موجود ہوں. حوالے کا ہر ایسا ورژن ایک پیک فائل سے جڑا ہوتا ہے جو Pando پہلے وصول کر چکا ہے. سرور اسی بنیاد پر کلائنٹ کی ضروریات طے کرتا ہے اور ایسی پیک فائلیں منتخب کرتا ہے جو اس کے تمام مطلوبہ آبجیکٹس فراہم کریں.

Git پروٹوکول کلون یا فیچ کے HTTP جواب میں صرف ایک پیک فائل بھیجنے کی اجازت دیتا ہے. تاہم, Git پروٹوکول کی ایک کم توجہ پانے والی خصوصیت, packfile-uri, سرور کو اضافی پیک الگ سے ڈاؤن لوڈ کرنے کے روابط واپس کرنے دیتی ہے. Pando صرف اسی طریقے کو استعمال کرتا ہے, اور جواب کے اندر ایک خالی پیک فائل بھیجتا ہے. اس خصوصیت کی معاونت کے لیے OpenAI نے packfile-uri کی متعدد بہتریاں اصل منصوبے میں شامل کروائیں.

OpenAI کے سسٹم کئی جغرافیائی خطوں میں چلتے ہیں, اس لیے ہم ہر خطے میں مقامی کیش کے ساتھ Pando کلسٹر رکھتے ہیں. پیک پہنچانے والی سروس Express ہمارے بلاب اسٹور کا کیش رکھتی ہے, اور ایک الگ سروس میٹاڈیٹا اسٹور کا کیش رکھتی ہے. ان کیش کی بدولت Pando کسی کمٹ آئی ڈی کی درخواست یا حوالے کو خاص انداز میں پڑھنے کی درخواست مکمل طور پر اسی کلسٹر کی کیش شدہ حالت سے پوری کر سکتا ہے. ہم پیک فائل کی درخواستیں Express سرور تک بھیجنے کے لیے یکساں ہیشنگ استعمال کرتے ہیں, اور 99% سے زیادہ درخواستوں کا مطلوبہ ڈیٹا کیش میں مل جاتا ہے.

کیش کا یہ سسٹم انتہائی زیادہ تھروپٹ دیتا ہے, جو کلائنٹس اور Pando کے درمیان نیٹ ورک کی پوری گنجائش استعمال کر سکتا ہے. ان پیک فائل URIs اور مقامی کیش کے ساتھ ہم نے تصدیق کی ہے کہ صرف کلاؤڈ فراہم کنندہ کی معیاری ورچوئل مشینوں پر بھی کلون اور فیچ, 10 Gbps فی سیکنڈ والے نیٹ ورک رابطوں کی پوری رفتار استعمال کرتے ہیں.

زیادہ تر Git سروروں کے لیے بڑھتی ریپوزٹری کی کارکردگی برقرار رکھنے کو دوبارہ پیک کرنا اور غیر استعمال شدہ مواد صاف کرنا ضروری ہے. دونوں مراحل جگہ خالی کرتے ہیں, مگر ان میں بہت زیادہ حسابی کام اور ڈیٹا پڑھنا لکھنا پڑتا ہے.

OpenAI کی مونو ریپو جیسی تیزی سے بدلتی ریپوزٹری میں پچھلے فیچ کے بعد ہونے والے ہر پُش کے لیے الگ پیک فائل یو آر آئی بھیجنا قابلِ عمل نہیں. اپنی ٹرنک اپ ڈیٹ کرنے کے لیے کلائنٹ کو روزانہ دسیوں ہزار پیک فائلیں ڈاؤن لوڈ کرنی پڑتیں.

اس کے بجائے Pando پسِ منظر میں پیک یکجا کرکے یہ اضافی بوجھ گھٹاتا ہے. اس کا ڈیزائن لاگ کی ساخت والے مرج ٹری میں کمپیکشن سے ملتا جلتا ہے. ہر پُش سے وہ پیک فائل بنتی ہے جسے Pando ”L0“ کہتا ہے؛ یہ ڈیٹا کی سب سے چھوٹی اکائی ہے جسے Pando منتقل کر سکتا ہے. وقت کے ساتھ پسِ منظر کے کارکن ان پیک فائلوں کو ایسے احاطوں میں جمع کرتے ہیں جو حوالے کے ورژنز کے سلسلے پر محیط ہوتے ہیں, اور L0 سے ہندسی تناسب میں بڑھتے ہیں. آج ہماری مونو ریپو L4 تک کے پیک فائل احاطے استعمال کرتی ہے.

یہ کورز دو کام کرتے ہیں. احاطہ کافی بھر جانے پر کمپیکشن کارکن اسے اپنے ذمے لیتا ہے اور ایک واحد پیک فائل بناتا ہے. اس سے پیک فائل کے اندر آبجیکٹس کی ترتیب بدل کر سکڑاؤ کا تناسب بہتر ہوتا ہے. یہ حوالے کے ورژنز پر اسکپ لسٹ کی طرح کام کرکے فیچ کے ابتدائی تبادلے کی کارکردگی بھی بہتر بناتا ہے. ہر سطح کے اشاریوں کو بیک وقت جانچ کر Pando کلائنٹ کو بھیجنے کے لیے پیک کا مجموعہ لوگارتھمی وقت میں منتخب کر سکتا ہے. یہ پیک فائل احاطے, چاہے دوبارہ پیک کیے گئے ہوں یا نہیں, فیچ کی منصوبہ بندی زیادہ مؤثر بناتے ہیں اور Pando کے تھروپٹ اور تاخیر, دونوں سے متعلق تقاضے کم کرتے ہیں.

بہت سے Git سروروں کے برعکس, پیک فائلیں ہر سطح پر رکھی جاتی ہیں؛ انہیں حذف یا غیر استعمال شدہ سمجھ کر صاف نہیں کیا جاتا. کلائنٹس کی فیچ درخواستوں میں دیے گئے haves اور wants کی بنیاد پر, ہر سطح کے پیک مسلسل سروس فراہم کرنے کے لیے استعمال ہوتے ہیں. اور Pando کو اے پی آئی کے طور پر استعمال کرنے والے کلائنٹس کے لیے, پیک فائل سے کوئی بھی آبجیکٹ پڑھنے میں عموماً 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 CLI کے گرد ایک داخلی واسطہ استعمال کیا. ہم نے تبدیلی کی درخواستوں اور کوڈ کے جائزے کو سنبھالنے کے لیے بہت سے دوسرے ٹولز, اور خودکار کاموں کے لیے اے پی آئی بھی بنائے. Git ٹریفک کے ساتھ ہم نے سیکڑوں انضمام بھی منتقل کیے جو پرانے APIs, ویب ہُک اور ریپوزٹری ڈاؤن لوڈ پر منحصر تھے.

خود 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 میں شامل ہیں, اور بہت سی دوسری ہماری عوامی ریپوزٹری میں موجود ہیں. ہم Git برادری کے ساتھ کام جاری رکھے ہوئے ہیں تاکہ یہ بہتریاں Pando سے باہر بھی مفید ہوں. آپ اس کام کی پیش رفت ہمارے عوامی پیچ ٹریکر⁠(نئی ونڈو میں کھلتا ہے) میں دیکھ سکتے ہیں.

Git ریپوزٹریوں کی گنجائش بڑھانے کے روایتی تصورات پر ازسرنو غور کرکے, Pando ہمیں اپنی مونو ریپو کی گنجائش بڑھانے دیتا ہے, وہ بھی انجینئروں اور ایجنٹس کے موجودہ Git طریقۂ کار کو بدلے بغیر. ہماری مونو ریپو میں Pando نے زیادہ کام متوازی طور پر ممکن بنایا, مرج کی قابلِ اعتماد کارکردگی بہتر کی, اور کوڈ کی تبدیلیاں شائع کرنے کا وقت گھٹایا ہے. مونو ریپو کے علاوہ ہم OpenAI کے اندر Pando کے دیگر استعمال بھی تلاش کر رہے ہیں, جن میں ایسا کام بھی شامل ہے جہاں بڑی تعداد میں ایجنٹس کو ایک شیئر کردہ Git ریپوزٹری پر تعاون کرنا ہو.

جیسے جیسے انجینئر اور ایجنٹس زیادہ سافٹ ویئر بنائیں گے, OpenAI سے باہر بھی مزید ٹیموں کو سورس کنٹرول کی انہی حدود کا سامنا ہوگا جن تک ہم پہنچے تھے. ہم فی الحال Pando کو ممکن بنانے والی ٹیکنالوجی اپنے صارفین تک پہنچانے کے طریقے تلاش کر رہے ہیں.

Pando کی بنیاد Git ریپوزٹریوں کے صارفین اور منتظمین کے دو دہائیوں کے تجربے پر ہے. ہم Pando کو ترقی دیتے رہیں گے اور Git کی اوپن سورس برادری کے ساتھ مل کر ایسی بہتریاں شیئر کریں گے جن سے Git صارفین کو وسیع پیمانے پر فائدہ ہو.