OpenAI တွင် Git ကို ချဲ့ထွင်ခြင်း

လွန်ခဲ့သောနှစ်အတွင်း ကျွန်ုပ်တို့၏ monorepo အရွယ်အစားနှင့် ၎င်းအပေါ် လုပ်ငန်းလိုအပ်ချက်များ အံ့မခန်းအရှိန်ဖြင့် တိုးလာခဲ့သည်။ Codex ကြောင့် ဖြစ်နိုင်လာသည့် တစ်ပြိုင်နက်လုပ်ငန်းပမာဏကို ကိုင်တွယ်နိုင်ရန် ကျွန်ုပ်တို့၏ source control စနစ်ကို ပြန်လည်ပြင်ဆင်ရမည်မှာ ထင်ရှားလာသည်။

အင်ဂျင်နီယာလုပ်ငန်းများကို မနှောင့်ယှက်ဘဲ၊ အဖွဲ့၏ Git အသုံးပြုပုံကိုလည်း မပြောင်းဘဲ Git သိမ်းဆည်းရန်နေရာများအတွက် နောက်ကွယ်စနစ်အသစ် Pando ကို တည်ဆောက်ခဲ့သည်။ ယခု Pando သည် OpenAI ၏ monorepo ထဲရှိ ဖွံ့ဖြိုးရေးလုပ်ငန်းအားလုံးကို ပံ့ပိုးပေးနေသည်။ Pando ကို ရည်မှန်းချက်ကြီးနှစ်ခုအတွက် ဒီဇိုင်းဆွဲထားသည်။ ပထမမှာ branch များစွာသို့ တစ်ပြိုင်နက် push လုပ်မှုအတွက် အကောင်းဆုံးပြင်ဆင်ထားပြီး စက်အရေအတွက်တိုး၍ ချဲ့ထွင်နိုင်သော ရေးသွင်းမှုဖြစ်သည်။ ဒုတိယမှာ ဖတ်ရှုမှု၏ ဆောင်ကြဉ်းပေးမှု ပမာဏကို အမြင့်ဆုံးမြှင့်တင်ပြီး client များက မိမိတို့ရရှိနိုင်သော ကွန်ရက် bandwidth ကို အပြည့်သုံးနိုင်သည့်နှုန်းဖြင့် ဒေတာဒေါင်းလုဒ်လုပ်နိုင်စေရန်ဖြစ်သည်။

Git ပရိုတိုကော၊ client တို့နှင့် တွဲဖက်အသုံးပြုနိုင်မှုကို ထိန်းထားရင်း ဤရည်မှန်းချက်များ အောင်မြင်ခဲ့သည်။ ထို့ကြောင့် အင်ဂျင်နီယာများနှင့် အေးဂျင့်များသည် မူလလုပ်ငန်းစဉ်များထဲသို့ Pando ကို အဆင်ပြေစွာ ထည့်သုံးနိုင်ခဲ့သည်။ လက်တွေ့အသုံးပြုရာတွင် Pando က push စောင့်ဆိုင်းချိန်၏ အလယ်ကိန်းကို မူလ၏ ငါးပုံတစ်ပုံခန့်အထိ လျှော့ချပေးခဲ့သည်။ ယခု တစ်နေ့လျှင် Git ဒေတာ တစ် petabyte နီးပါး ပေးပို့နေသည်။

ဤနေရာတွင် source control စနစ်အသစ် တည်ဆောက်ရသည့် အကြောင်းရင်းများနှင့် Git နှင့် တွဲဖက်အသုံးပြုနိုင်မှုကို ထိန်းထားရန် ရွေးချယ်ခဲ့သည့် အကြောင်းရင်းတို့ကို ရှင်းပြမည်။ ကျွန်ုပ်တို့၏စနစ်ကို Git ချဲ့ထွင်ရာတွင် အသုံးများသော နည်းလမ်းများနှင့် နှိုင်းယှဉ်ပြီး OpenAI ၏ ချဲ့ထွင်နိုင်မှုလိုအပ်ချက်များကို Pando က အဘယ်ကြောင့် ထူးခြားစွာ ဖြည့်ဆည်းနိုင်ကြောင်း ရှင်းပြမည်။ ရှေ့ဆက်လုပ်မည့်အရာများနှင့် အေးဂျင့်များ၏ လုပ်ငန်းပမာဏကို ပံ့ပိုးရန် Git သို့ မည်သို့ ဆက်လက်ပါဝင်ကူညီမည်ကိုလည်း ဆွေးနွေးမည်။

Codex သည် အင်ဂျင်နီယာများကို အလုပ်များစွာ တစ်ပြိုင်နက်လုပ်နိုင်စေပြီး OpenAI ၏ ဖွံ့ဖြိုးရေးလုပ်ငန်းပမာဏနှင့် အရှိန်ကို ပြောင်းလဲပေးခဲ့သည်။ ထို့ကြောင့် branch၊ push၊ merge များ ပိုများလာသလို ဖွံ့ဖြိုးရေးပတ်ဝန်းကျင်များ၊ သုတေသနအလုပ်များနှင့် CI မှ fetch၊ clone လုပ်မှုများလည်း ပိုများလာသည်။

ဤလိုအပ်ချက်များသည် အချင်းချင်းဆင့်ပွား၍ ပိုများလာသည်။ ယခု အင်ဂျင်နီယာတစ်ဦးတွင် CI အတွက် အဆင်သင့်ဖြစ်သော အပြောင်းအလဲများစွာ တစ်ပြိုင်နက်ရှိနိုင်ပြီး push တစ်ခုစီကြောင့် အလုပ်များစွာက commit တစ်ခုတည်းကို fetch လုပ်နိုင်သည်။

ပြီးခဲ့သည့်နှစ်ကုန်ခန့်မှစ၍ ကျွန်ုပ်တို့၏ monorepo ကို ပံ့ပိုးသောစနစ်များသည် လိုအပ်ချက်ကို အမီလိုက်ရန် ရုန်းကန်နေရသည်။ fetch၊ push နှေးကွေးမှုများနှင့် merge မအောင်မြင်မှုများ ကြုံရပြီး တစ်ခါတစ်ရံ ယုံကြည်စိတ်ချရမှုသည် 90% အောက်အထိ ကျဆင်းခဲ့သည်။ Git ကိုယ်တိုင်၏ အကန့်အသတ်သို့ ရောက်ခဲ့ခြင်းလား၊ သို့မဟုတ် ကျွန်ုပ်တို့ monorepo ကို ဝန်ဆောင်မှုပေးသည့်နည်းလမ်း၏ အကန့်အသတ်လား။ Git သည် kernel ပြင်ဆင်ချက်များကို အီးမေးလ်ဖြင့် ဖလှယ်သော အသိုင်းအဝိုင်းတစ်ခုမှ ပေါ်ပေါက်လာခဲ့သည်။ ဆော့ဖ်ဝဲတည်ဆောက်ပုံ ပြောင်းလဲလာသည်နှင့်အမျှ ဖွံ့ဖြိုးရေးသမားများသည် မိမိတို့၏ ကိရိယာများကို Git နှင့် ကိုက်ညီအောင် ပြုပြင်လာခဲ့သည်မှာ ဆယ်စုနှစ်နှစ်ခုကျော်ပြီဖြစ်သည်။ ကျွန်ုပ်တို့၏ monorepo တွင် အခက်အခဲစတင်တွေ့ချိန်၌ ထိုအလုပ်များအပေါ် ဆက်လက်အခြေခံတည်ဆောက်နိုင်ရန် အရေးကြီးခဲ့သည်။

ရင်းနှီးပြီးသား လုပ်ငန်းစဉ်ကို ထိန်းထားရင်း မတူသော branch များသို့ push လုပ်မှုကို တစ်ပြိုင်နက်ကိုင်တွယ်ရန်၊ မှတ်တမ်းတစ်ခုတည်းကို ဖတ်ရှုသူများစွာထံ တစ်ပြိုင်နက်ပေးရန် နောက်ကွယ်စနစ် ပြန်တည်ဆောက်နိုင်မည့် နည်းလမ်းကို တွေ့ခဲ့သည်။ source control လုပ်ငန်းစဉ်၏ အခြေခံအဖြစ် Git ကို သုံးခြင်းကြောင့် client ပိုင်းတိုးတက်မှုများသည် OpenAI ပြင်ပ၌ပါ အသုံးဝင်နိုင်သည်။ ကျွန်ုပ်တို့၏ Git မိတ္တူ⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) မှ ထိုတိုးတက်မှုများကို မူရင်းပရောဂျက်သို့ ပြန်လည်ပံ့ပိုးပြီး ကျယ်ပြန့်သော အသိုင်းအဝိုင်းနှင့် မျှဝေလိုခဲ့သည်။

source control စနစ် ချဲ့ထွင်ရာတွင် အဓိကအပိုင်းနှစ်ခုရှိသည်။ ရေးသွင်းသူများစွာက မတူသော branch များသို့ push လုပ်ခြင်းနှင့် ဖတ်ရှုသူများစွာက မှတ်တမ်းတစ်ခုတည်းကို fetch လုပ်ခြင်းတို့ဖြစ်သည်။ Pando သည် နှစ်မျိုးလုံးအတွက် အကောင်းဆုံးလုပ်ဆောင်နိုင်ရန် ပြင်ဆင်ထားသည်။

ပထမ၊ Pando သည် branch တစ်ခုချင်း၏ အပ်ဒိတ်များကို သီးခြားညှိနှိုင်းသည်။ မသက်ဆိုင်သော branch များ၏ အပ်ဒိတ်များ တစ်ပြိုင်နက် ဆက်လုပ်နိုင်ပြီး branch တစ်ခုကို fetch လုပ်သည့် ဖတ်ရှုသူသည် ထိုပြင်ဆင်ဗားရှင်းအတွက် လိုအပ်သော မှတ်တမ်းကို ရရှိသည်။ အလဲအလှယ်အနေဖြင့် branch များစွာကို ကြည့်နေသော ဖတ်ရှုသူသည် ၎င်းတို့ကို မတူညီသော အချိန်အခြေအနေများတွင် မြင်ရနိုင်သည်။

ဒုတိယ၊ Pando သည် client တစ်ခုစီအတွက် သီးခြား packfile မဖန်တီးဘဲ fetch များအကြား packfile များကို ပြန်သုံးသည်။ packfile သည် အော့ဘ်ဂျက်များစွာကို အတူဖိသိပ်သိမ်းသော Git ဖိုင်ပုံစံဖြစ်သည်။ client သည် ရှိပြီးသား အော့ဘ်ဂျက်အချို့ကို ဒေါင်းလုဒ်ပြန်လုပ်ရနိုင်သော်လည်း ဆာဗာသည် တွက်ချက်မှုအနည်းငယ်ဖြင့် တူညီသော ဘိုက်များကို client များစွာထံ ပေးနိုင်သည်။

ဤရွေးချယ်မှုများကြောင့် branch များအနှံ့ ရေးသွင်းမှုကို ချဲ့ထွင်နိုင်ပြီး ဖတ်ရှုမှုများကို ယာယီသိမ်းဆည်းမှုများမှ ပေးနိုင်သည်။ ယင်းတို့ မည်သို့ဆက်စပ်အလုပ်လုပ်သည်ကို နားလည်ရန် Git က မှတ်တမ်းကို သိမ်းဆည်း၊ လွှဲပြောင်းပုံမှ စကြည့်ကြပါစို့။

Git သည် သိမ်းဆည်းရန်နေရာ၏ အပိုင်းနှစ်ခုဖြစ်သော အော့ဘ်ဂျက်များ နှင့် ရည်ညွှန်းချက်များ ကို အမြဲကိုက်ညီနေစေရမည်။

Git သိမ်းဆည်းရန်နေရာသည် ဖိုင်များ၏ တစ်ချိန်ချင်းအခြေအနေနှင့် ၎င်းတို့ကို ဆက်သွယ်ပေးသော မှတ်တမ်းကို အော့ဘ်ဂျက်ဆက်နွှယ်ပုံအဖြစ် မှတ်တမ်းတင်သည်။ အော့ဘ်ဂျက်တစ်ခုသည် blob၊ tree၊ commit သို့မဟုတ် tag ဖြစ်နိုင်သည်။ blob များက ဖိုင်တစ်ခုချင်း၏ အကြောင်းအရာကို သိမ်းထားပြီး tree များက အမည်များကို blob သို့မဟုတ် အခြား tree များနှင့် တွဲဖက်ကာ directory ဖွဲ့စည်းပုံ ဖန်တီးသည်။ commit များက မူလ tree နှင့် မိဘ commit သုည သို့မဟုတ် တစ်ခုထက်ပိုကို ညွှန်ပြီး သင့်သိမ်းဆည်းရန်နေရာ၏ မှတ်တမ်းကို ဖွဲ့စည်းသည်။

အော့ဘ်ဂျက်များကို ၎င်းတို့၏ အမျိုးအစားနှင့် အကြောင်းအရာမှ တွက်ထားသော hash ဖြင့် ခွဲခြားသတ်မှတ်သည်။ အော့ဘ်ဂျက်များကို ပြောင်းလဲ၍မရပါ။ ပြင်ထားသောဖိုင်ကို မှတ်တမ်းတင်လျှင် blob အသစ် ဖန်တီးပြီး မပြောင်းလဲသော ဖိုင်နှင့် directory များက ရှိပြီးသား အော့ဘ်ဂျက်များကို ပြန်သုံးနိုင်သည်။

branch နှင့် tag များသည် commit များကို ညွှန်သော ရည်ညွှန်းချက်များ၊ အတိုကောက် “refs” ဖြစ်သည်။ branch တစ်ခုတွင် commit လုပ်လျှင် commit အသစ်ဖန်တီးပြီး branch ၏ ref ကို ထို commit သို့ ညွှန်စေရန် အပ်ဒိတ်လုပ်သည်။

Git သည် အော့ဘ်ဂျက်များကို “သီးခြား” သို့မဟုတ် “ထုပ်ပိုးထားသော” အခြေအနေဖြင့် သိမ်းသည်။ သီးခြားအော့ဘ်ဂျက်များကို ၎င်းတို့၏ အော့ဘ်ဂျက် ID ဖြင့် သတ်မှတ်ထားသော ဖိုင်တစ်ခုစီတွင် သိမ်းသည်။ ထုပ်ပိုးထားသော အော့ဘ်ဂျက်များကို packfile တစ်ခုထဲ အတူသိမ်းသဖြင့် ဆင်တူသော အော့ဘ်ဂျက်များကို တစ်ခုနှင့်တစ်ခု ကွာခြားချက်အဖြစ် သိမ်းနိုင်သည်။

Git တွင် commit တစ်ခုမှ ၎င်း၏ မိဘ commit၊ tree၊ blob များတစ်လျှောက် လင့်ခ်များအတိုင်း လိုက်၍ အော့ဘ်ဂျက်တစ်ခုကို ရှာတွေ့နိုင်လျှင် ထို commit မှ ၎င်းအော့ဘ်ဂျက်သို့ ရောက်နိုင်သည် ဟု ဆိုသည်။ fetch လုပ်စဉ် client သည် မည်သည့် commit များ လိုချင်ပြီး မည်သည့် commit များ ရှိပြီးသားဖြစ်ကြောင်း ဆာဗာကို ပြောသည်။ ဆာဗာသည် လိုချင်သော commit များမှ ရောက်နိုင်သော အော့ဘ်ဂျက်များကို ရှာ၊ client တွင် ရှိပြီးသားဟု သိထားသည်များကို ချန်ပြီး ကျန်သည်များကို Git က disk ပေါ်တွင် သုံးသောပုံစံအတိုင်း packfile အဖြစ် ပို့သည်။ အပြည့်အစုံ clone လုပ်ခြင်းသည် အော့ဘ်ဂျက်လုံးဝမရှိဘဲ စတင်သဖြင့် clone လုပ်နေသော မှတ်တမ်းမှ ရောက်နိုင်သည့် အော့ဘ်ဂျက်အားလုံး လိုသည်။

push သည် ဆာဗာကို ref တစ်ခု သို့မဟုတ် အများအပြား အပ်ဒိတ်လုပ်ရန် တောင်းဆိုပြီး အော့ဘ်ဂျက်များကို ဆန့်ကျင်ဘက်ဦးတည်ရာသို့ လွှဲပြောင်းသည်။ client သည် ဆာဗာတွင် ရှိပြီးသား အော့ဘ်ဂျက်များ မပို့မိစေရန် ဆာဗာကြေညာထားသော ref အစုကို သုံးသည်။ ထို့ကြောင့် ပို့သော pack သည် ရှိပြီးသား အော့ဘ်ဂျက်များကို မှီခိုနိုင်ပြီး မှတ်တမ်းအသစ် ပြန်တည်ဆောက်ရန် pack တစ်ခုတည်း လက်ခံရရှိရုံဖြင့် မလုံလောက်ပါ။

Git သိမ်းဆည်းရန်နေရာကို ပုံတူပွားခြင်းဆိုသည်မှာ ဆာဗာများစွာတွင် အော့ဘ်ဂျက်နှင့် ရည်ညွှန်းချက်နှစ်မျိုးလုံး ရရှိနိုင်အောင် ထိန်းထားခြင်းဖြစ်သည်။ ပုံတူတစ်ခုက ရည်ညွှန်းချက်၏ တန်ဖိုးအသစ်ကို မပေးမီ ထိုတန်ဖိုးမှ ရောက်နိုင်သော အော့ဘ်ဂျက်များကို ပေးနိုင်ရမည်။ ဝန်ဆောင်မှုသည် ပြိုင်ဆိုင်နေသော ရည်ညွှန်းချက်အပ်ဒိတ်များ ကိုလည်း ညှိနှိုင်းရသည်။ ဆိုလိုသည်မှာ branch တစ်ခုတည်းကို ထိပ်ဆုံး commit အဟောင်းတစ်ခုတည်းမှ မတူသော commit အသစ်များသို့ ရွှေ့ရန် ကြိုးပမ်းသော push များဖြစ်သည်။ သိမ်းဆည်းရန်နေရာတစ်ခု၏ ရေးသွင်းမှုအားလုံးကို အစဉ်တစ်ခုတည်းဖြင့် သတ်မှတ်သောစနစ်များက မသက်ဆိုင်သော branch များသို့ push လုပ်မှုများကို အချင်းချင်း စောင့်ရစေနိုင်သည်။

Pando ဒီဇိုင်းဆွဲစဉ် Git ဖြင့် source control ချဲ့ထွင်သည့် သမားရိုးကျနည်းများကို အကဲဖြတ်ခဲ့သည်။ တစ်မျိုးမှာ node များအကြား commit ညှိနှိုင်းသော အဆင့်သုံးဆင့် commit (3PC) ဖြင့် သိမ်းဆည်းရန်နေရာပုံတူများ၏ ref အပ်ဒိတ်ကို ညှိနှိုင်းခြင်းဖြစ်သည်။ နောက်တစ်မျိုးမှာ အပြောင်းအလဲမလုပ်မီ မှတ်တမ်းတင်သော ဘုံကြိုတင်ရေးသွင်းမှတ်တမ်း (WAL) ကို blob သိုလှောင်စနစ်တွင် ထား၍ အပ်ဒိတ်အစဉ်စီခြင်းဖြစ်သည်။

ကျွန်ုပ်တို့ ပုံစံတူပြုလုပ်ခဲ့သော အဆင့်သုံးဆင့် commit ဒီဇိုင်းတွင် Git ဝန်ဆောင်မှုသည် သိမ်းဆည်းရန်နေရာ၏ မိတ္တူအပြည့်ကို ပုံတူဆာဗာအချို့ပေါ်၌ ထားသည်။ ဆာဗာတစ်ခုခုက push လက်ခံရလျှင် ဝင်လာသော packfile ကို ကူးပြီး ပုံတူအားလုံးထံ တစ်ပြိုင်နက် ပို့သည်။ push ကို ထုတ်ပြန်ရန် ပုံတူအများစုက ref အပ်ဒိတ်ကို လက်ခံရမည်။ ဤအလုပ်ကို စီမံသောဆာဗာသည် ညှိနှိုင်းပေးသူဖြစ်ပြီး ၎င်းနှင့် အခြားပုံတူတစ်ခုစီကြား အကြိမ်များစွာ ဆက်သွယ်ရသည်။

ရည်ညွှန်းချက်အပ်ဒိတ်ကို လက်ခံရန် ပုံတူတစ်ခုစီသည် မိမိ၏ ref မိတ္တူကို လော့ခ်ချပြီး client မျှော်လင့်သော commit ကို ညွှန်နေဆဲဟုတ်မဟုတ် စစ်သည်။ ထို့နောက် ညှိနှိုင်းပေးသူက လက်ခံသော ပုံတူများထံ commit မတိုင်မီ အကြောင်းကြားချက် ပို့သည်။ အများစုက ထိုအကြောင်းကြားချက်ကို လက်ခံကြောင်း ပြန်ကြားလျှင် ညှိနှိုင်းပေးသူက အပ်ဒိတ်လုပ်ရန် ပြောသည်။ ထို့နောက် နောက်ဆုံးအခြေအနေနှင့် ကိုက်ညီသော ပုံတူတစ်ခုခုသည် မိမိ၏ စက်တွင်းသိမ်းဆည်းရန်နေရာမိတ္တူမှ branch ထိပ်ဆုံး commit အသစ်ကို ကြေညာနိုင်သည်။

ပုံတူအပြည့်ထားခြင်းက စက်တွင်းမှ ဖတ်ရှုမှုကို ဝန်ဆောင်မှုပေးနိုင်စေပြီး client က မည်သည့်ပုံတူကို ရွေးစေကာမူ ရည်ညွှန်းချက်အားလုံး၏ ကိုက်ညီသော အခြေအနေကို ရမည်ဟု အာမခံသည်။ ထို့ကြောင့် ရည်ညွှန်းချက်များကို တစ်ကြိမ်လျှင် တစ်ခုသာ အပ်ဒိတ်လုပ်ပြီး push တစ်ခုစီအတွက် ပုံတူများကြား ref အပ်ဒိတ်ညှိနှိုင်းရန် အကြိမ်များစွာ အသွားအပြန်ဆက်သွယ်ရသည်။

လိုအပ်သော အများစု၏ သဘောတူညီမှုကို စောင့်ရသဖြင့် push လုပ်ငန်းစဉ်သည် ပုံတူ disk စွမ်းဆောင်ရည်နှင့် ဆက်သွယ်ရေးစောင့်ဆိုင်းချိန်အပေါ် မူတည်လာသည်။ ရေးသွင်းပမာဏ တိုးလာသည်နှင့် ပုံတူများသည် ဝင်လာသော pack များသာမက ဖတ်ရှုတောင်းဆိုမှုများကိုပါ အမီကိုင်တွယ်ရသည်။

ကျွန်ုပ်တို့ ပုံစံတူပြုလုပ်ခဲ့သော WAL အခြေပြုဒီဇိုင်းတွင် Git ဝန်ဆောင်မှုသည် သိမ်းဆည်းရန်နေရာတစ်ခုလုံး၏ အပ်ဒိတ်အစဉ်ကို စီရန် blob သိုလှောင်စနစ်ရှိ ဘုံပရိုဂရမ်အချက်အလက်ဖိုင်ကို သုံးသည်။ ဆာဗာက push လက်ခံသောအခါ ဝင်လာသော packfile ကို blob သိုလှောင်စနစ်သို့ တင်ပြီး မိမိ၏ စက်တွင်းသိမ်းဆည်းရန်နေရာမိတ္တူ၌ ref အပ်ဒိတ်ကို ပြင်ဆင်သည်။ push ကို ထုတ်ပြန်ရန် blob သိုလှောင်စနစ်ရှိ ဘုံပရိုဂရမ်အချက်အလက်ဖိုင်ထဲသို့ ref အပ်ဒိတ်ကို မှတ်တမ်းတင်ပြီး packfile ကို ညွှန်သော စာရင်းဝင်တစ်ခု ထည့်သည်။ ထို့နောက် Git ဆာဗာသည် နှိုင်းယှဉ်ပြီးလဲလှယ်သည့် လုပ်ဆောင်ချက်ဖြင့် ပရိုဂရမ်အချက်အလက်ဖိုင်ကို အပ်ဒိတ်လုပ်သည်။ ယင်းသည် ပရိုဂရမ်အချက်အလက်ဖိုင်တစ်ခုလုံးကို တစ်ပြိုင်နက် အစားထိုးသည်၊ မဟုတ်လျှင် အပြောင်းအလဲကို ငြင်းပယ်သည်။ ကြားကာလတွင် အခြားရေးသွင်းသူက အပ်ဒိတ်လုပ်ထားလျှင် ဆာဗာသည် ကြားဝင်စာရင်းများကို ဖတ်၊ မိမိ ref အပ်ဒိတ် အကျုံးဝင်နေဆဲဟုတ်မဟုတ် စစ်ပြီး တင်ထားပြီးသား packfile ဖြင့် ပြန်ကြိုးစားသည်။

ရေးသွင်းသူများသည် packfile များကို တစ်ပြိုင်နက် တင်နိုင်သော်လည်း မသက်ဆိုင်သော branch များသို့ push လုပ်ခြင်းပင် ပရိုဂရမ်အချက်အလက်ဖိုင်တစ်ခုတည်းကို အပ်ဒိတ်လုပ်ရသည်။ နှိုင်းယှဉ်ပြီးလဲလှယ်မှု အောင်မြင်ရန် ကြာသော အသွားအပြန်အချိန်က သိမ်းဆည်းရန်နေရာတွင် ပရိုဂရမ်အချက်အလက်ဖိုင်အသစ် ထုတ်ပြန်နိုင်သည့် အကြိမ်နှုန်းကို ကန့်သတ်သည်။ စောင့်ဆိုင်းချိန်နည်းသော blob သိုလှောင်စနစ်က ဤအဆင့်ကို မြန်စေသည်။ အစုလိုက်လုပ်ခြင်းက ပရိုဂရမ်အချက်အလက်ဖိုင်တစ်ခုဖြင့် ref များစွာကို တစ်ပြိုင်နက် အပ်ဒိတ်လုပ်နိုင်စေသော်လည်း အပ်ဒိတ်များ တန်းစီစောင့်ရပြီး စောင့်ဆိုင်းချိန် တိုးစေသည်။

blob သိုလှောင်စနစ်သည် packfile များကို တစ်ပြိုင်နက် လက်ခံနိုင်သော်လည်း ဘုံပရိုဂရမ်အချက်အလက်ဖိုင်၏ အပ်ဒိတ်များမှာ အချင်းချင်း ပြိုင်ဆိုင်နေရဆဲဖြစ်သည်။ blob သိုလှောင်စနစ်၏ စွမ်းရည်ကိုသာ တိုးခြင်းက ထိုအတားအဆီးကို မဖြေရှင်းနိုင်ပါ။ ပုံတူတစ်ခုစီသည် စက်တွင်းမှ ဝန်ဆောင်မှုမပေးနိုင်မီ blob သိုလှောင်စနစ်မှ pack များကို ဖတ်ပြီး အညွှန်းဖန်တီးရဆဲဖြစ်သည်။ ဝင်လာသော ရေးသွင်းမှုနှုန်းက ထိုအလုပ်ထက် မြန်လျှင် ပုံတူများ နောက်ကျကျန်ခဲ့ပြီး အသစ် push လုပ်ထားသော commit များကို fetch လုပ်ရန် client များ ပိုကြာကြာ စောင့်ရသည်။

ဤအချက်များကြောင့် Pando သို့ ရောက်လာခဲ့သည်။ Pando သည် client များစွာ တစ်ပြိုင်နက် push လုပ်နိုင်သည့်အထိ ချဲ့ထွင်ရန် ရည်ရွယ်သော Git သိမ်းဆည်းရန်နေရာ ဝန်ဆောင်မှုဖွဲ့စည်းပုံအသစ်ဖြစ်သည်။ ၎င်း၏ အလုပ်လုပ်ပုံမှာ အောက်ပါအတိုင်းဖြစ်သည်။

Pando ကို မတည်ဆောက်မီကပင် Git နှင့် ပတ်သက်၍ အလျှော့မပေးဘဲ ကျွန်ုပ်တို့၏ လိုအပ်ချက်များကို ဖြည့်ဆည်းနိုင်မည်ဟု ယူဆခဲ့သည်။ သို့သော် Git စနစ်အများစုက မရှိမဖြစ်လိုအပ်သည်ဟု ယူဆထားသည့် အချက်အချို့ကိုတော့ လျှော့ပေါ့ပေးရန် လိုအပ်ခဲ့သည်။

• သိမ်းဆည်းရန်နေရာတစ်ခုလုံး၏ ဒေတာကိုက်ညီမှု၊ ref အားလုံး၏ တစ်ချိန်တည်းအခြေအနေကို ကိုက်ညီစွာ ပြသရန် သိမ်းဆည်းရန်နေရာတစ်ခုလုံးတွင် ညှိနှိုင်းရသည်။ ref အပ်ဒိတ်အားလုံးကို အစဉ်တစ်ခုတည်းဖြင့် စီသည့်စနစ်တွင် မသက်ဆိုင်သော branch များသို့ push လုပ်မှုများက ညှိနှိုင်းရာနေရာတစ်ခုတည်းကို အပြိုင်အသုံးပြုရသည်။

• client တစ်ခုစီအတွက် သီးခြား packfile များ၊ စက်တွင်းမှတ်တမ်း မတူသော client နှစ်ခုက branch တစ်ခုတည်းကို fetch လုပ်လျှင် ၎င်းတို့တွင် ရှိပြီးသား အော့ဘ်ဂျက်များကို မပို့မိစေရန် ဆာဗာက တစ်ခုစီအတွက် မတူသော pack ဖန်တီးပေးရနိုင်သည်။ ဤတုံ့ပြန်ချက်များ ဖန်တီးရာတွင် CPU နှင့် disk I/O သုံးရသဖြင့် ဖတ်ရှုသူအများအပြားကို ဝန်ဆောင်မှုပေးနိုင်ရန် ချဲ့ထွင်ရခက်သည်။

ထိုအစား Pando သည် ရေးသွင်းမှုများကို ချဲ့ထွင်နိုင်ရန် ဒေတာကိုက်ညီမှုစည်းကမ်း လျှော့ပေါ့ထားသော ပုံစံ (အကြောင်းအကျိုးအစဉ်အလိုက် ကိုက်ညီမှု) ကို သုံးပြီး ဖတ်ရှုမှုများကို ချဲ့ထွင်ရန် packfile များကို ပြန်သုံးသည်။

client တစ်ခုက branch သို့ push လုပ်သောအခါ Pando သည် ဝင်လာသော packfile ကို ပြောင်းလဲ၍မရသော blob အဖြစ် blob သိုလှောင်စနစ်တွင် သိမ်းသည်။ branch ရွေ့သွားတိုင်း Pando သည် ထိပ်ဆုံး commit အသစ်၊ ၎င်းကို ပေးပို့ခဲ့သော pack နှင့် ထို pack က မှီခိုသော အစောပိုင်း ref ဗားရှင်းများပါဝင်သည့် ref ဗားရှင်း ကို မက်တာဒေတာသိုလှောင်စနစ်တွင် မှတ်တမ်းတင်သည်။ blob နှင့် မက်တာဒေတာသိုလှောင်စနစ်နှစ်ခုလုံးကို စက်အရေအတွက်တိုး၍ ချဲ့ထွင်နိုင်သည်။

Pando မှ commit သို့မဟုတ် reference တစ်ခုကို fetch လုပ်ရန် ref ဗားရှင်းများ (packfile များ) ကို client ထံ အစဉ်လိုက် ပြန်ပို့ရသည်။ ဤနည်းဖြင့် ယခုရယူနေသော ref ဗားရှင်းကို ဖန်တီးခဲ့သည့် client ၏ အခြေအနေကို ပြန်တည်ဆောက်သည်။ ဤနည်းသည် သိမ်းဆည်းရန်နေရာတစ်ခုလုံးအတွက် ပိုလျော့ရဲသော ဒေတာကိုက်ညီမှုကို ပေးပြီး ref တစ်ခုချင်း၏ အပ်ဒိတ်များကိုမူ တစ်ခုပြီးတစ်ခု ဆောင်ရွက်သကဲ့သို့ အာမခံပေးသည်။ client များသည် ref တစ်ခုတည်းသို့ တစ်ပြိုင်နက် push လုပ်မှသာ ပဋိပက္ခဖြစ်သည်။ branch များစွာကို ဖတ်ရှုနေသော client သည် ထိုဒေတာများက သိမ်းဆည်းရန်နေရာတစ်ခုလုံး၏ တစ်ချိန်တည်းအခြေအနေကို ဖော်ပြသည်ဟု မယူဆနိုင်ပါ။

ဤသည်မှာ အကြောင်းအကျိုးအစဉ်အလိုက် ကိုက်ညီမှု ပုံစံတစ်မျိုးဖြစ်သည်။ reference တစ်ခုကို fetch လုပ်ရန် ဖတ်ရှုသူသည် ၎င်းကို ဖန်တီးခဲ့သော ရေးသွင်းသူ၏ မှတ်တမ်းကို မြင်ရသည်။ push လုပ်စဉ် Pando သည် client နှင့် ဆာဗာတို့ သဘောတူသတ်မှတ်မည့် ဘုံမှတ်တမ်းကို ထိန်းချုပ်ပြီး client များက မျှဝေသုံးစွဲရ ပိုလွယ်သော packfile များ ထုတ်ပေးစေသည်။

ထို့ကြောင့် Pando သည် Git လုပ်ဆောင်ချက်များအတွင်း reference အားလုံး၏ တစ်ချိန်တည်းအခြေအနေကိုလည်းကောင်း၊ clone သို့မဟုတ် fetch တစ်ခုအတွင်း ref အပ်ဒိတ်များ၏ အစဉ်ကိုလည်းကောင်း မပေးပါ။ ဥပမာ၊ အပြည့်အစုံ clone လုပ်ရန် ညှိနှိုင်းနေစဉ် foo နှင့် bar branch နှစ်ခုလုံးကို အပ်ဒိတ်လုပ်သည်ဟု ယူဆပါစို့။ ညှိနှိုင်းစဉ် client တစ်ခုက foo ဗားရှင်း 1 နှင့် bar ဗားရှင်း 2 ကို မြင်ရချိန်တွင် အခြား client က foo ဗားရှင်း 2 နှင့် bar ဗားရှင်း 1 ကို မြင်ရနိုင်သည်။ လက်တွေ့တွင် အသုံးပြုသူများနှင့် အေးဂျင့်များသည် ref အပ်ဒိတ်အားလုံး၏ အစဉ်ကို အားမကိုးဘဲ reference တစ်ခုချင်း၏ အပ်ဒိတ်အစဉ်ကိုသာ အားကိုးကြသည်။

ဒေတာကိုက်ညီမှု ပုံစံသုံးမျိုးကို သရုပ်တူစမ်းသပ်ရာတွင် client 1,000 ကို တစ်ခုစီက သီးခြား branch တစ်ခု ရွေးပြီး မတူညီသော commit များ ထပ်ခါတလဲလဲ push လုပ်စေသည်။ စုစုပေါင်း အမှန်တကယ်ကြာချိန်နှင့် push မှ fetch အထိ စောင့်ဆိုင်းချိန်ကို တိုင်းတာသည်။ နောက်ဆုံးတိုင်းတာချက်သည် လုပ်ငန်းဝန်များအတွက် အရေးကြီးသည်။ အသုံးပြုသူများနှင့် အေးဂျင့်များ ပူးပေါင်းလုပ်ဆောင်ရန် သို့မဟုတ် ဗားရှင်းထိန်းချုပ်မှုကို အားကိုးသော အခြားစနစ်များ သုံးရန် လိုအပ်သည့် အသွားအပြန်အချိန်ကို တိုင်းတာပေးသောကြောင့်ဖြစ်သည်။ ဤသရုပ်တူစမ်းသပ်မှုတွင် သာမန်မှ အဆင့်မြင့်အထိ virtual machine များနှင့် blob သိုလှောင်စနစ်များ၏ ဟာ့ဒ်ဝဲကို ပုံစံတူပြုလုပ်ထားသည်။ ဤစမ်းသပ်မှုတွင် အဆင့်သုံးဆင့် commit စနစ်အတွက် သိမ်းဆည်းရန်နေရာတစ်ခုလုံး၏ ဒေတာကိုက်ညီမှုကို လျှော့ပေါ့ထားသည်။

ပုံစံတူလုပ်ထားသော အဆင့်သုံးဆင့် commit စနစ်တွင် လုပ်ငန်းဝန်များလာ၍ disk များ အပြည့်အဝအလုပ်လုပ်ရချိန်၌ ရေးသွင်းစောင့်ဆိုင်းချိန် သိသိသာသာ ပိုများလာသည်။ ကြိုတင်ရေးသွင်းမှတ်တမ်းစနစ်များတွင်လည်း အလားတူအကြောင်းကြောင့် ဆာဗာများက မှတ်တမ်းဖတ်နှုန်းကို မမီတော့ဘဲ ဖတ်ရှုစောင့်ဆိုင်းချိန် သိသိသာသာ ပိုများလာသည်။ ကျွန်ုပ်တို့၏ monorepo တွင် လက်တွေ့စမ်းသပ်ရာ၌လည်းကောင်း၊ ဤသရုပ်တူစမ်းသပ်မှုတွင်လည်းကောင်း Pando သည် လုပ်ငန်းဝန်များချိန်၌ စွမ်းဆောင်ရည်မကျဘဲ client ထောင်ပေါင်းများစွာ တစ်ပြိုင်နက် push လုပ်နိုင်စေသည်။

push ကို ကိုင်တွယ်ရာတွင် Pando သည် ဝင်လာသော packfile ကို စက်တွင်းသိမ်းဆည်းရန်နေရာ၌ ဖြည်ချခြင်းမပြုဘဲ blob သိုလှောင်စနစ်သို့ တိုက်ရိုက်ပို့ရင်း မှန်ကန်မှုစစ်ဆေးသည်။ client က fetch စတင်သည့်အခါ Pando သည် ဖတ်ရှုသူလိုအပ်သော သိမ်းထားပြီးသား pack များကို ရွေးပေးပြီး ဖတ်ရှုသူက ၎င်းတို့ကို ဒေါင်းလုဒ်လုပ်သည်။ မည်သည့်ဆာဗာမျှ packfile များကို စက်တွင်းသိမ်းဆည်းရန်နေရာ၌ ထည့်သွင်းရန် သို့မဟုတ် အရင်းအမြစ်များစွာသုံးရသော ဖြည်ချခြင်း၊ ထုပ်ပိုးခြင်းတို့ လုပ်ရန် မလိုပါ။ ဤဆာဗာများသည် အဓိကအားဖြင့် ညှိနှိုင်းခြင်းနှင့် packfile ရွေးချယ်ခြင်းကိုသာ လုပ်သဖြင့် Pando ဆာဗာများကို သာမန်ဟာ့ဒ်ဝဲပေါ်တွင် လည်ပတ်နိုင်သည်။

ထို့ကြောင့် Pando ကို client များ၊ client နှင့် Pando ကြား ကွန်ရက်၊ blob သိုလှောင်ဝန်ဆောင်မှုတို့၏ စွမ်းရည်အကန့်အသတ်အထိ ချဲ့ထွင်နိုင်သည်။ စွမ်းရည်လုံလောက်လျှင် သီးခြား branch များပေါ်တွင် အလုပ်လုပ်သော client တစ်ခုစီသည် မိမိချိတ်ဆက်မှု၏ အမြန်ဆုံးနှုန်းဖြင့် pack များ လွှဲပြောင်းနိုင်သည်။ ထိုနှုန်းအတိုင်း client ပိုများများကို ဝန်ဆောင်မှုပေးရန် Pando ဆာဗာများ ထပ်ထည့်ပြီး မက်တာဒေတာနှင့် blob သိုလှောင်စနစ်များကိုပါ လိုက်လံချဲ့ထွင်နိုင်သည်။

အေးဂျင့်တစ်ခုသည် စက်တွင်း၌ ဖိုင်များပြင်၊ commit ဖန်တီးပြီး git push ကို လုပ်ဆောင်သည်။ ယင်းက branch အပ်ဒိတ်လုပ်ရန် ထိုအပြောင်းအလဲများပါသော packfile ဖန်တီးသည်။ Pando သည် pack ကို လက်ခံပြီး blob သိုလှောင်စနစ်သို့ တိုက်ရိုက်ပို့သည်။ ဝင်လာသော push ကို တစ်ကြိမ်တည်း decode လုပ်၍ မှန်ကန်မှုစစ်ဆေးပြီးနောက် Pando သည် ကီးများစွာပါသော transaction ဖြင့် မက်တာဒေတာသိုလှောင်စနစ်၌ ref ဗားရှင်းတစ်ခု မှတ်တမ်းတင်ကာ ref ညွှန်တံကို ခွဲမရသော လုပ်ဆောင်ချက်တစ်ခုအဖြစ် အပ်ဒိတ်လုပ်သည်။ ထို့ကြောင့် Pando သည် “မိမိရေးသွင်းထားသည်ကို မိမိပြန်ဖတ်နိုင်ခြင်း” ဆိုင်ရာ ဒေတာကိုက်ညီမှုကို ပေးနိုင်သည်။ ဤရေးသွင်းမှုတစ်ခုလုံးအတွက် မက်တာဒေတာ ဖတ်ရှု၊ ရေးသွင်းမှု $O(1)$ သာ လိုအပ်သည်။

အခြား client က ထို branch ကို fetch လုပ်သောအခါ Pando သည် client တွင် ရှိပြီးသားမှတ်တမ်းကို သုံး၍ သိမ်းထားသော pack အစုကို ရွေးသည်။ ဤလုပ်ဆောင်ချက်တွင် မက်တာဒေတာ ဖတ်ရှုမှု $O(\log \Delta)$ လိုအပ်သည်။ $\Delta$ သည် client တွင် ရှိသည့်အရာနှင့် လိုချင်သည့်အရာကြား ref ဗားရှင်းအရ အတိုဆုံးအကွာအဝေးဖြစ်သည်။ ဆာဗာက packfile URI များ ပြန်ပေးပြီး client သည် packfile များကို ဒေသအလိုက် ယာယီသိမ်းထားသော Express ဝန်ဆောင်မှုမှတစ်ဆင့် ဒေါင်းလုဒ်လုပ်သည်။

ဤဒီဇိုင်းသည် Pando ဖွဲ့စည်းပုံ၏ အဓိကဝန်ဆောင်မှုသုံးခုဖြစ်သည့် push၊ fetch နှင့် အကျဉ်းချုံ့ခြင်းတို့အပေါ် မှီခိုသည်။

client က push လုပ်သောအခါ သမားရိုးကျ Git ဆာဗာသည် မိမိဖဲအားလုံးကို ပြသော ပိုကာသမားကဲ့သို့ပင် ၎င်းတွင်ရှိသည့် branch အားလုံးကို client ထံ ဖော်ပြသည်။ ထို့နောက် client သည် commit၊ tree၊ blob များကို စုစည်းပြီး ဆာဗာတွင် ရှိပြီးသားဟု သိထားသော အော့ဘ်ဂျက်များ မပါဝင်သည့် packfile ကို ဖန်တီးသည်။

ref ပိုများများ ကြေညာလျှင် push အရွယ်အစား ပိုသေးနိုင်သည်။ သို့သော် ရေးသွင်းသူချန်ထားခဲ့သော အော့ဘ်ဂျက်များ အခြား client တွင် မရှိနိုင်သဖြင့် pack ကို ပြန်သုံးရ ပိုခက်နိုင်သည်။

Pando သည် မတူသောနည်းလမ်းကို သုံးသည်။ မိမိဖဲအားလုံးကို ပြမည့်အစား ရွေးထားသော branch အချို့ကိုသာ client ထံ ကြေညာသည်။ ဤသို့လုပ်ရသည့် အကြောင်းရင်းနှစ်ခုရှိသည်။

1. ref အားလုံး၏ ကိုက်ညီသော အခြေအနေကို ပြသရန် အရင်းအမြစ်များစွာ လိုသည်။ branch သန်းပေါင်းများစွာရှိလျှင် ref ကြေညာချက်တစ်ခုတည်းကပင် 100 MiB ကျော်နိုင်သည်။ ယင်းကို ပေးရန် ဆာဗာတစ်ခုစီသည် ညှိနှိုင်းမှုဝန်များစွာဖြင့် လက်ရှိတွဲဖက်စာရင်းကို ထိန်းသိမ်းရမည်၊ သို့မဟုတ် ref အရေအတွက်နှင့်အမျှ အလုပ်ပိုများလာသော ဒေတာဘေ့စ်ရှာဖွေမှု လုပ်ရမည်။

2. ref အချို့ကိုသာ client ထံ ပေးခြင်းဖြင့် client ဖန်တီးသော pack သည် ဆာဗာက ချန်လှပ်ခွင့် အတိအလင်းပေးထားသည့် အရာများကိုသာ မှီခိုမည်ဖြစ်သည်။ မှီခိုမှုများကို ခြေရာခံထားခြင်းကြောင့် Pando သည် push တစ်ခုတွင် client ဖန်တီးခဲ့သော packfile ကို နောက်လာမည့် fetch ၏ တုံ့ပြန်ချက်အဖြစ် ပြန်သုံးနိုင်သည်။

Git ဆာဗာက ref ပိုများများ ကြေညာလေ၊ push လုပ်သော client များတွင် အော့ဘ်ဂျက်ချန်လှပ်နိုင်မည့် ရင်းမြစ်များ ပိုများလေဖြစ်ပြီး ပိုသေးသော pack များ ထုတ်နိုင်သည်။ သို့သော် ထို packfile များကို ပြန်သုံးရန် fetch လုပ်သော client များ၌ မှီခိုရာအားလုံး ရှိကြောင်း ဆာဗာက အတည်ပြုနိုင်ရမည်။ မဟုတ်လျှင် packfile တွင် client လိုအပ်သော အော့ဘ်ဂျက်များ ကျန်ခဲ့နိုင်သည်။

တစ်ဖက်တွင် Git ဆာဗာက ref လုံးဝမကြေညာလျှင် client သည် သိမ်းဆည်းရန်နေရာ၏ မှတ်တမ်းအပြည့်ပါသော packfile ကို ဖန်တီးမည်။ ထို packfile ကို အခြား client မည်သည့်တစ်ခုမဆို သုံးနိုင်သော်လည်း မည်သည့် branch ကို fetch လုပ်သည်ဖြစ်စေ လက်တွေ့အားဖြင့် အပြည့်အစုံ clone လုပ်ရသကဲ့သို့ ကုန်ကျစရိတ်များလာမည်။

ပုံမှန်အားဖြင့် client က feature branch အသစ်ကို push လုပ်သောအခါ Pando သည် သတ်မှတ်ထားသော trunk branch တစ်ခုကိုသာ အခြေခံအဖြစ် ကြေညာသည်။ ထို့ကြောင့် သိမ်းဆည်းရန်နေရာတွင် branch တိုးလာသော်လည်း ကြေညာချက်အရွယ်အစား တူနေသည်။ သို့သော် အလဲအလှယ်လုပ်ရသည့် အချက်များရှိသည်။ အင်ဂျင်နီယာက branch တစ်ခုတည်းသို့ အကြိမ်များစွာ push လုပ်လျှင်ဖြစ်စေ၊ feature branch တစ်ခုအပေါ် နောက်တစ်ခု ဆင့်တည်ဆောက်လျှင်ဖြစ်စေ client သည် trunk ပြင်ပရှိ အရာအားလုံးကို ပြန်ပို့ရသည်။

ထို့ကြောင့် ဆက်တိုက် branch push များသည် မလိုအပ်ဘဲ ထပ်နေသော အော့ဘ်ဂျက်များ ပါနိုင်ကာ ပိုကြီးလာပြီး client bandwidth ပိုသုံးရသည်။ ကျွန်ုပ်တို့၏ monorepo တွင် ဤနည်းဖြင့် ထုတ်သော packfile အရွယ်အစား အလယ်ကိန်းသည် 20 KiB အောက်၊ 99 ရာခိုင်နှုန်းမြောက်တန်ဖိုးသည် 3 MiB အောက်ရှိသည်။ ကြေညာထားသော trunk မှတ်တမ်း ရှိပြီးသားဖတ်ရှုသူက ထို packfile တစ်ခုတည်းဖြင့် branch ကို fetch လုပ်နိုင်သဖြင့် ကျွန်ုပ်တို့အတွက် ယင်းသည် သင့်လျော်သော အလဲအလှယ်ဖြစ်ခဲ့သည်။

client ထံ ကြေညာမည့် ref အစုကို ရွေးပြီးနောက် Pando သည် push ကို လက်ခံပြီး မက်တာဒေတာသိုလှောင်စနစ်ကို အပ်ဒိတ်လုပ်သည်။ Pando သည် မက်တာဒေတာအပ်ဒိတ်ကို ပြီးစီးသည်အထိ စောင့်ရသောအပိုင်းနှင့် နောက်ကွယ်တွင် ဆက်လုပ်မည့်အပိုင်းဟူ၍ ခွဲသည်။ ပြီးစီးသည်အထိ စောင့်ရသော မက်တာဒေတာအပ်ဒိတ်က client များကို အသစ်အပ်ဒိတ်လုပ်ထားသော commit ကို ချက်ချင်း fetch လုပ်နိုင်စေသည်။ ယင်းက ref ဗားရှင်းအသစ် ရေးပြီး ref ညွှန်တံကို ထိုဗားရှင်းသို့ အပ်ဒိတ်လုပ်သည်။ ထိပ်ဆုံး commit အသစ်၊ packfile ညှိနှိုင်းရာတွင် သုံးခဲ့သော မှီခိုရာများနှင့် push လုပ်ခဲ့သော packfile လင့်ခ်တို့ကို သိမ်းသည်။

တစ်ချိန်တည်းတွင် အကျဉ်းချုံ့ခြင်းကို အချိန်သတ်မှတ်ခြင်းကဲ့သို့ နောက်ကွယ်၌ ဆက်လုပ်မည့်အလုပ်ကိုလည်း transaction တစ်ခုတည်းတွင် မှတ်တမ်းတင်သည်။ အလွန်ကြီးသော push များအတွက် commit အချို့ကိုသာ ချက်ချင်းပြီးစီးအောင် ရေးသွင်းသည်။ ထို့ကြောင့် push အရွယ်အစား မည်မျှဖြစ်စေ မက်တာဒေတာသိုလှောင်စနစ်ကို ဖတ်ရှု၊ ရေးသွင်းရသည့် အကြိမ်အရေအတွက်မှာ ကိန်းသေတစ်ခုသာ လိုအပ်သည်။

အရေးကြီးသည်မှာ Pando ဆာဗာများသည် မသက်ဆိုင်သော ref များသို့ push လုပ်မှုများကို သီးခြားလက်ခံနိုင်ခြင်းဖြစ်သည်။ အပြိုင်သုံးရသော တစ်ခုတည်းသောကီးမှာ ref ညွှန်တံဖြစ်ပြီး ၎င်းကို ခွဲမရသော နှိုင်းယှဉ်ပြီးလဲလှယ်သည့် လုပ်ဆောင်ချက်မျိုးဖြင့် ကာကွယ်ထားသည်။ Pando ဆာဗာများ၊ မက်တာဒေတာသိုလှောင်စနစ် ချဲ့ထွင်ယူနစ်များ သို့မဟုတ် blob သိုလှောင်စနစ်များ ထပ်ထည့်၍ ရေးသွင်းမှု၏ ဆောင်ကြဉ်းပေးမှု ပမာဏကို တိုးနိုင်သည်။

client က fetch လုပ်သောအခါ ပရိုတိုကောတွင် have နှင့် want ဟု ခေါ်သည့် commit ID အစုနှစ်စုကို ဆာဗာထံ ပေးသည်။ သမားရိုးကျ Git ဆာဗာသည် ရှိပြီးသား commit များမှ ရောက်နိုင်သော အော့ဘ်ဂျက်များနှင့် လိုချင်သော commit များမှ ရောက်နိုင်သော အော့ဘ်ဂျက်များကြား အစုကွာခြားချက်ကို တွက်ပြီး ဖိသိပ်ကာ client ထံ ပို့သည်။ အများသုံးရင်းမြစ်ဖွင့် Git ဆာဗာတွင် ဤလုပ်ဆောင်ချက် မြန်စေရန် စက်တွင်းအညွှန်းမျိုးစုံ ရှိသော်လည်း ထို packfile များတွက်ချက်ရန် အရင်းအမြစ်များစွာလိုနိုင်ပြီး ယေဘုယျအားဖြင့် ယာယီသိမ်း၍ ပြန်သုံးရန် ခက်သည်။

ထိုအစား Pando သည် push လုပ်စဉ် မှတ်တမ်းတင်ထားသော commit တွဲဖက်စာရင်းဖြင့် client ၏ have နှင့် want များကို ရှာကာ ထို commit များပါဝင်သော ref ဗားရှင်းအစုအဖြစ် သတ်မှတ်သည်။ ထို ref ဗားရှင်းတစ်ခုစီသည် Pando ယခင်က လက်ခံထားသော packfile တစ်ခုနှင့် ချိတ်ထားသည်။ ဆာဗာသည် ယင်းကို သုံး၍ client လိုအပ်သော အော့ဘ်ဂျက်အစုကို လွှမ်းခြုံသည့် packfile များ ရွေးပေးသည်။

Git ပရိုတိုကောသည် clone သို့မဟုတ် fetch ၏ HTTP တုံ့ပြန်ချက်တွင် packfile တစ်ခုတည်းသာ ပို့ခွင့်ပေးသည်။ သို့သော် လူသိနည်းသော Git ပရိုတိုကောလုပ်ဆောင်ချက် packfile-uri က အပို pack များကို သီးခြားဒေါင်းလုဒ်လုပ်ရန် လင့်ခ်များ ပြန်ပေးနိုင်စေသည်။ Pando သည် ဤနည်းကိုသာ သုံးပြီး တုံ့ပြန်ချက်ထဲတွင် packfile အလွတ်တစ်ခုကို ပို့သည်။ ဤလုပ်ဆောင်ချက်ကို ပံ့ပိုးရန် OpenAI သည် packfile-uri ဆိုင်ရာ ပြုပြင်တိုးတက်မှုများစွာကို မူရင်းပရောဂျက်သို့ ပံ့ပိုးခဲ့သည်။

OpenAI စနစ်များသည် ပထဝီဒေသများစွာ၌ လည်ပတ်သဖြင့် ဒေသတစ်ခုစီတွင် ဒေသတွင်းယာယီသိမ်းဆည်းမှုပါသော Pando ဆာဗာအစုများ ထားရှိသည်။ pack ပေးပို့ရေးဝန်ဆောင်မှု Express က blob သိုလှောင်စနစ်ဒေတာကို ယာယီသိမ်းပြီး သီးခြားဝန်ဆောင်မှုတစ်ခုက မက်တာဒေတာကို ယာယီသိမ်းသည်။ ဤယာယီသိမ်းဆည်းမှုများကြောင့် Pando သည် commit ID တောင်းဆိုမှု သို့မဟုတ် ref ကို အထူးဖတ်ရှုမှုတစ်ခုအား ထိုဆာဗာအစု၌ ယာယီသိမ်းထားသော အခြေအနေမှသာ အပြည့်အဝ ဖြည့်ဆည်းနိုင်သည်။ packfile တောင်းဆိုမှုများကို Express ဆာဗာများထံ လမ်းညွှန်ရန် တည်ငြိမ်သော hash ခွဲဝေနည်းကို သုံးပြီး ယာယီသိမ်းဆည်းမှုမှ ရရှိနှုန်းသည် 99% ကျော်သည်။

ဤယာယီသိမ်းဆည်းစနစ်သည် အလွန်မြင့်သော ဆောင်ကြဉ်းပေးမှု ပမာဏကို ပေးပြီး client နှင့် Pando ကြား ကွန်ရက်စွမ်းရည်ကို အပြည့်သုံးနိုင်သည်။ ဤ packfile URI များနှင့် ဒေသတွင်းယာယီသိမ်းဆည်းမှုများကို သုံးလျှင် cloud ပံ့ပိုးသူ၏ သာမန် virtual machine များဖြင့်ပင် clone၊ fetch လုပ်မှုများက 10 Gbps ကွန်ရက်ချိတ်ဆက်မှုကို အပြည့်သုံးနိုင်ကြောင်း အတည်ပြုထားသည်။

Git ဆာဗာအများစုတွင် ကြီးထွားလာသော သိမ်းဆည်းရန်နေရာ၏ စွမ်းဆောင်ရည်ကို ထိန်းရန် ပြန်ထုပ်ပိုးခြင်းနှင့် မလိုတော့သောဒေတာ ရှင်းလင်းခြင်းတို့ လိုအပ်သည်။ အဆင့်နှစ်ခုလုံးက နေရာလွတ်ပြန်ရစေသော်လည်း တွက်ချက်မှုနှင့် I/O ကို များစွာသုံးရသည်။

OpenAI ၏ monorepo ကဲ့သို့ လျင်မြန်စွာပြောင်းလဲနေသော သိမ်းဆည်းရန်နေရာတွင် နောက်ဆုံး fetch မှစ၍ လုပ်ခဲ့သော push တိုင်းအတွက် packfile URI တစ်ခုစီ ပို့ရန် လက်တွေ့မဖြစ်နိုင်ပါ။ client တစ်ခုသည် မိမိ trunk ကို နောက်ဆုံးအခြေအနေသို့ ရောက်စေရန် တစ်နေ့လျှင် packfile သောင်းချီ ဒေါင်းလုဒ်လုပ်ရမည်။

ထိုအစား Pando သည် အပိုဝန်လျှော့ရန် နောက်ကွယ်တွင် pack များ ပေါင်းစည်းသည်။ မှတ်တမ်းအခြေပြု merge-tree များ၏ အကျဉ်းချုံ့ခြင်းနှင့် ဆင်တူသော ဒီဇိုင်းကို အသုံးပြုသည်။ push တစ်ခုစီက Pando တွင် “L0” ဟု ခေါ်သော packfile ကို ထုတ်ပြီး ယင်းသည် Pando ပေးပို့နိုင်သော အသေးဆုံးဒေတာယူနစ်ဖြစ်သည်။ အချိန်ကြာလာသည်နှင့် နောက်ကွယ်လုပ်ငန်းများက ထို packfile များကို ref ဗားရှင်းအစဉ်တစ်ခုအား လွှမ်းခြုံသော အစုများအဖြစ် စုစည်းသည်။ အစုအရွယ်အစားသည် L0 မှစ၍ ဆတိုးနှုန်းဖြင့် ကြီးလာသည်။ ယနေ့ ကျွန်ုပ်တို့၏ monorepo သည် L4 အထိ packfile လွှမ်းခြုံအစုများကို သုံးသည်။

ဤလွှမ်းခြုံအစုများတွင် ရည်ရွယ်ချက်နှစ်မျိုးရှိသည်။ လွှမ်းခြုံအစုတစ်ခု လုံလောက်စွာပြည့်လျှင် အကျဉ်းချုံ့ခြင်း လုပ်ဆောင်သည့်လုပ်ငန်းက ၎င်းကို တာဝန်ယူပြီး packfile တစ်ခုတည်း ထုတ်ပေးသည်။ ယင်းက packfile အတွင်း အော့ဘ်ဂျက်များ ပြန်စီသဖြင့် ဖိသိပ်မှုအချိုး ပိုကောင်းလာသည်။ ထို့ပြင် ref ဗားရှင်းများအပေါ် ခုန်ကျော်ရှာဖွေနိုင်သောစာရင်းအဖြစ် လုပ်ဆောင်သဖြင့် fetch ညှိနှိုင်းမှုစွမ်းဆောင်ရည်လည်း တိုးတက်သည်။ အဆင့်တစ်ခုစီရှိ အညွှန်းများကို တစ်ပြိုင်နက် စစ်ရှာခြင်းဖြင့် Pando သည် client ထံ ပို့မည့် pack အစုကို လော့ဂရစ်သမ်အချိန်အတွင်း ရွေးနိုင်သည်။ ပြန်ထုပ်ပိုးထားသည်ဖြစ်စေ၊ မထုပ်ပိုးရသေးသည်ဖြစ်စေ ဤ packfile လွှမ်းခြုံအစုများက fetch စီမံမှုကို ပိုထိရောက်စေပြီး Pando အတွက် ဆောင်ကြဉ်းပေးမှု ပမာဏနှင့် စောင့်ဆိုင်းချိန်ဆိုင်ရာ လိုအပ်ချက်နှစ်မျိုးလုံးကို လျှော့ပေးသည်။

Git ဆာဗာအများအပြားနှင့် မတူဘဲ အဆင့်တိုင်းရှိ packfile များကို မပယ်ဖျက်၊ မရှင်းလင်းဘဲ ထိန်းထားသည်။ client များက fetch တွင် တောင်းဆိုသော have နှင့် want များအရ အဆင့်တိုင်းရှိ pack များကို ဝန်ဆောင်မှုပေးရန် ဆက်တိုက်အသုံးပြုသည်။ Pando ကို API အဖြစ် သုံးသော client များအတွက် packfile မှ အော့ဘ်ဂျက်တစ်ခုခု ဖတ်ရာတွင် L0 မှ ဖတ်ရှုရသည့် ဒေတာပမာဏသည် L4 မှ ဖတ်ရှုရသည့် ပမာဏထက် ပိုနည်းလေ့ရှိသည်။ အကြောင်းမှာ ဖိသိပ်ထားနိုင်ခြေ ပိုနည်းသောကြောင့်ဖြစ်သည်။

Pando ၏ အကျဉ်းချုံ့ခြင်းက client များထံ ပို့ရသော စုစုပေါင်းဒေတာကို သိသိသာသာ လျှော့ချပေးသည်။ ထို့ပြင် client နောက်ကျနေသည့် အကွာအဝေးတိုးလာလျှင် pack စီမံမှုကုန်ကျစရိတ်သည် ထိုအကွာအဝေးနှင့် တိုက်ရိုက်အချိုးကျနှုန်းထက် နှေးစွာသာ တိုးစေသည်။ ဤသည်မှာ ကြီးမားပြီး လျင်မြန်စွာပြောင်းလဲသော သိမ်းဆည်းရန်နေရာများအတွက် အထူးအရေးကြီးသည်။ ထိုနေရာများသည် ဆော့ဖ်ဝဲဖွံ့ဖြိုးရေး၏ ပုံမှန်အခြေအနေသစ် ဖြစ်လာမည်ဟု ကျွန်ုပ်တို့ မျှော်လင့်ထားသည်။

Pando ကို Codex ဖြင့် တည်ဆောက်ခဲ့ရာ စတင်ချိန်မှ လက်တွေ့အသုံးပြုချိန်အထိ 10 ပတ်သာ ကြာခဲ့သည်။ Pando ၏ အဓိကအစိတ်အပိုင်းကို အင်ဂျင်နီယာတစ်ဦးတည်းက ဒီဇိုင်းဆွဲ၊ အေးဂျင့်အဖွဲ့များက အကောင်အထည်ဖော်ပြီး အင်ဂျင်နီယာအနည်းငယ်က ဖြန့်ချိတပ်ဆင်ခဲ့သည်။ Pando သည် ယခုနှစ် ဧပြီလတွင် လက်တွေ့အသုံးပြုမှု တောင်းဆိုချက်များကို စတင်ကိုင်တွယ်ခဲ့ပြီး OpenAI တွင် သုံးသော ပိုကြီးမားသည့် source control စီမံကိရိယာစနစ်၏ အစိတ်အပိုင်းတစ်ခုဖြစ်သည်။

Pando ၏ ဒီဇိုင်းမှန်ကန်မှု စစ်ဆေးရာတွင် နည်းလမ်းမျိုးစုံ သုံးခဲ့သည်။ ကျွန်ုပ်တို့၏ ပိုလုံခြုံသော ဆော့ဖ်ဝဲအခြေခံများ တည်ဆောက်ရေး⁠ မူများကို အသုံးချခဲ့သည်။ အစမှ အသစ်တည်ဆောက်သော ပရောဂျက်ဖြစ်သဖြင့် Pando ကို Rust ဖြင့် ရေးသားပြီး စနစ်ဟောင်းများအပေါ် မမှီခိုရန် ရွေးချယ်ခဲ့သည်။ အေးဂျင့်များက မိမိတို့၏ အပြောင်းအလဲများကို စံ Git အလုပ်လုပ်ပုံနှင့် တိုက်စစ်နိုင်ရန် ကိုက်ညီမှုစမ်းသပ်ချက်အစုကို ရေးသားခဲ့သည်။ စနစ်၏ မပြောင်းရမည့်စည်းကမ်းများနှင့် ဂုဏ်သတ္တိများကို စစ်နိုင်ရန် ရလဒ်တသမတ်တည်းရသော သရုပ်တူ အကဲဖြတ်စမ်းသပ်မှု စနစ်များလည်း တည်ဆောက်ခဲ့သည်။ ယင်းဖြင့် ညှိနှိုင်းမှုနှင့် pack စီမံမှုတွင် သိမ်မွေ့သော အပြိုင်လုပ်ဆောင်မှုအမှားများ၊ ရီဂရက်ရှင်အမှားများကို ရှာဖွေ လျော့ပါးစေနိုင်ခဲ့သည်။

မော်ဒယ်များစွာက ဤစနစ်တွင် ပါဝင်ကူညီခဲ့သည်။ မော်ဒယ်အသစ်များ ရလာသည်နှင့် Pando ၏ စွမ်းဆောင်ရည်နှင့် ယုံကြည်စိတ်ချရမှု တိုးတက်ရန် ၎င်းတို့ကို သုံးခဲ့သည်။ GPT‑6 Astra ကို သုံး၍ အေးဂျင့်များက “Pando သီအိုရီ” ကို တိကျသော သင်္ချာပုံစံဖြင့် သတ်မှတ်ရန် Lean နှင့် TLA+ ရေးသားခဲ့သည်။ ယင်းဖြင့် အကောင်အထည်ဖော်မှုအမှားများကို ရှာပြင်ပြီး စနစ်၏ ဂုဏ်သတ္တိများကို သက်သေပြခဲ့သည်။ အဆက်မပြတ်လုပ်ဆောင်သည့် ဆက်ရှင်များစွာသည် နာရီရာချီကြာ လည်ပတ်ကာ Pando ၏ ရှားပါးအခြေအနေပြဿနာများကို ရှာဖွေပြင်ဆင်ခဲ့သည်။ Daybreak စွမ်းရည်ရှိသော မော်ဒယ်များကို သုံး၍ Git နှင့် Pando တို့၏ အားနည်းချက်များကို တိုက်ခိုက်သူအမြင်ဖြင့် စမ်းသပ်ရန် အေးဂျင့်များကိုလည်း နာရီမလပ် လည်ပတ်စေသည်။

Pando ကို စတင်အသုံးပြုချိန်တွင် မူလ source control စနစ်သို့ ဖတ်ရှုမှု၊ ရေးသွင်းမှုများ တစ်ဆင့်ပို့ပေးသော ကြားခံအဖြစ် သုံးခဲ့သည်။ ထို့ကြောင့် Pando နှင့် စနစ်ဟောင်းကို ကိုက်ညီနေစေပြီး ဝန်ဆောင်မှုရပ်တန့်မှုမရှိဘဲ တောင်းဆိုမှုများကို Pando သို့ လုံခြုံစွာ ရွှေ့နိုင်ခဲ့သည်။

ယာယီသိမ်းဆည်းရေးဒီဇိုင်း၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် Pando သည် တစ်ဆင့်မပို့မီ တောင်းဆိုမှုများ၏ ထပ်နေမှုကို ဖယ်ရှားပြီး ပေါင်းစည်းနိုင်သည်။ ထို့ကြောင့် စနစ်များကို Pando သို့ တစ်ခုပြီးတစ်ခု ရွှေ့စဉ် မူလကိရိယာများကို ကောင်းစွာလည်ပတ်နေစေနိုင်ခဲ့သည်။ လုပ်ငန်းဝန်များကို Pando သို့ ပိုရွှေ့လာသည်နှင့် ၎င်းတို့၏ push များက Pando ၏ ယာယီသိမ်းဆည်းမှုကို ဖြည့်ပေးပြီး မူလနောက်ခံဆာဗာစနစ်၏ ယုံကြည်စိတ်ချရမှုလည်း တိုးတက်လာသည်။

Pando သုံးစဉ် စွမ်းဆောင်ရည်ကောင်းစေရန် ကျွန်ုပ်တို့ အများပြည်သူထံ ဖြန့်ချိထားသော Git ကို ဖွံ့ဖြိုးရေးသမားများ၏ စက်များနှင့် ChatGPT ဒက်စ်တော့အက်ပ်အတွင်း စတင်ထည့်သွင်းပေးခဲ့သည်။ client များကို Pando သို့ ရွှေ့ရန် Git CLI ကို လွှမ်းခြုံထားသော အတွင်းသုံးကိရိယာဖြင့် အဆင့်လိုက် ပြောင်းရွှေ့ခဲ့သည်။ အပြောင်းအလဲတောင်းဆိုမှု၊ ကုဒ်သုံးသပ်မှုနှင့် အလိုအလျောက်လုပ်ဆောင်ရေး API များအတွက် အခြားကိရိယာများစွာလည်း ဖန်တီးခဲ့သည်။ Git အသုံးပြုမှုနှင့်အတူ API အဟောင်းများ၊ webhook များနှင့် သိမ်းဆည်းရန်နေရာ ဒေါင်းလုဒ်များကို မှီခိုသော ချိတ်ဆက်ပေါင်းစည်းမှု ရာချီကိုလည်း ရွှေ့ခဲ့သည်။

Codex ကိုယ်တိုင်က ဖွံ့ဖြိုးရေးသမားများနှင့် အဖွဲ့များ ပြောင်းရွှေ့ရာတွင် ကူညီခဲ့သည်။ ရှိပြီးသား checkout များကို ပြင်ဆင်ရန်နှင့် အေးဂျင့်များကို စနစ်အသစ် အသုံးပြုရန် လမ်းညွှန်ပေးမည့် စွမ်းရည်များကို ဖန်တီးခဲ့သည်။ ထို့ကြောင့် ဖွံ့ဖြိုးရေးသမားများသည် မိမိတို့၏ ဖွံ့ဖြိုးရေးပတ်ဝန်းကျင်နှင့် ဝန်ဆောင်မှုများကို ရွှေ့ပေးရန် Codex ကို ပြောရုံသာ လိုခဲ့သည်။

Pando သို့ ပြောင်းခြင်းက merge ယုံကြည်စိတ်ချရမှုကို တိုးစေပြီး push စောင့်ဆိုင်းချိန်၏ အလယ်ကိန်းကို 80% နီးပါး လျှော့ချပေးခဲ့သည်။

Pando သည် CPU core အနည်းငယ်ဖြင့် တစ်နေ့လျှင် Git ဒေတာ 1 ပက်တာဘိုက် ပေးပို့နိုင်သည်။ Pando သည် တစ်နာရီတည်းတွင် Git pack 57 တာရာဘိုက် ကျော် ပေးပို့ခဲ့ဖူးပြီး ထိုဘိုက်များ၏ 99% ကျော်ကို စက်တွင်း disk ယာယီသိမ်းဆည်းမှုမှ ပေးခဲ့သည်။

pack များ ပြန်သုံးခြင်းက ပေးပို့သော node များ၌ တွက်ချက်မှုအနည်းငယ်သာ လုပ်ရပြီး client များစွာက သိမ်းဆည်းရန်နေရာ၏ မှတ်တမ်းတစ်ခုတည်းကို ဒေါင်းလုဒ်လုပ်နိုင်စေသည်။ ဤဥပမာတွင် သိမ်းဆည်းရန်နေရာတစ်ခုတည်းကို ပြထားသော်လည်း Pando ကို နောက်ထပ်များစွာ ပံ့ပိုးနိုင်ရန် ဒီဇိုင်းဆွဲထားသည်။ လိုအပ်ချက်တိုးလာလျှင် ဒေတာပေးပို့မှုနှင့် Git ညှိနှိုင်းမှုကို သီးခြားစီ ချဲ့ထွင်နိုင်သည်။

Git ပရိုတိုကောနှင့် client အပေါ် Pando ကို တည်ဆောက်ခြင်းက Git ကိုယ်တိုင်၏ အမှားများနှင့် စွမ်းဆောင်ရည်တိုးတက်နိုင်မည့် အခွင့်အလမ်းများကို ဖော်ထုတ်နိုင်စေခဲ့သည်။

ဥပမာ၊ Pando သည် ပြန်သုံးနိုင်သော pack များကို client ထံ တိုက်ရိုက်ပေးသဖြင့် ထို pack များ ဒေါင်းလုဒ်လုပ်ခြင်းနှင့် အညွှန်းဖန်တီးခြင်းသည် စနစ်မြန်ဆန်၊ ယုံကြည်စိတ်ချရစေရန် အဓိကအပိုင်းဖြစ်လာသည်။ ထိုအလုပ်က တစ်ပြိုင်နက်ဒေါင်းလုဒ်များ၊ လွှဲပြောင်းမှုရပ်သွားပြီးနောက် ရှင်းလင်းမှု၊ ပြီးစီးပြီးသား ဒေါင်းလုဒ်များ ပြန်စမှုတို့တွင် ရှားပါးအခြေအနေပြဿနာများကို ဖော်ထုတ်ခဲ့သည်။ ထိုလုပ်ဆောင်ပုံများကို ပြင်ဆင်ပြီး fetch အတွက် ရှိပြီးသား pack လက်ခံရာတွင် မှန်ကန်မှုစစ်ဆေးချက်များ ထည့်ကာ ထိုအလုပ်ကို မူရင်းပရောဂျက်သို့ ပြန်ပံ့ပိုးခဲ့သည်။

အချိန်နှင့် bandwidth မည်သည့်နေရာတွင် သုံးနေသည်ကိုလည်း သိရန်လိုသဖြင့် packfile-uri ဒေါင်းလုဒ် ခြေရာခံမှုနှင့် pack ဖန်တီးမှု၏ ဘိုက်အရေအတွက်ကို ထည့်ခဲ့သည်။ ထို့ကြောင့် fetch နှေးခြင်းမှာ pack ဖန်တီးနေ၍လား၊ လွှဲပြောင်းနေ၍လား ခွဲခြားရလွယ်လာသည်။

OpenAI ၏ Git ဖြန့်ချိမှု⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တွင် client သည် သီးခြား pack များကို တစ်ပြိုင်နက် ဒေါင်းလုဒ်လုပ်၊ အညွှန်းဖန်တီးနိုင်သည်။ ဆာဗာက branch ၏ လက်ရှိထိပ်ဆုံး commit ကို push လုပ်မည့် client က pack မှ ချန်လှပ်နိုင်သော မှတ်တမ်းနှင့် သီးခြားကြေညာနိုင်ရန် “အတိအလင်းသတ်မှတ်ထားသော ရှိပြီးသား commit များ” ဟူသည့် သဘောတရားကို ထည့်ခဲ့သည်။ Pando တွင် ယင်းကြောင့် client များသည် --force-with-lease ဖြင့် feature branch မရွေ့သေးကြောင်း စစ်ပြီး trunk တစ်ခုတည်းကို အခြေခံ၍ pack တည်ဆောက်နိုင်သည်။ ထို့နောက် ထို trunk မှတ်တမ်းရှိသူ မည်သူမဆို pack တစ်ခုတည်းကို သုံး၍ branch ကို fetch လုပ်နိုင်သည်။

ဤတိုးတက်မှုအချို့သည် မူရင်း Git တွင် ပါဝင်နေပြီဖြစ်ပြီး အခြားများစွာမှာ ကျွန်ုပ်တို့၏ အများပြည်သူသုံး သိမ်းဆည်းရန်နေရာ၌ ရှိသည်။ ဤတိုးတက်မှုများကို Pando ပြင်ပ၌ပါ အသုံးဝင်စေရန် Git အသိုင်းအဝိုင်းနှင့် ဆက်လက်ပူးပေါင်းနေသည်။ ထိုအလုပ်ကို ကျွန်ုပ်တို့၏ အများပြည်သူသုံး ပြင်ဆင်ချက်ခြေရာခံစနစ်⁠(ဝင်းဒိုးအသစ်တွင် ဖွင့်မည်) တွင် လိုက်ကြည့်နိုင်သည်။

Git သိမ်းဆည်းရန်နေရာများ ချဲ့ထွင်ပုံနှင့်ပတ်သက်သော အစဉ်အလာအယူအဆများကို ပြန်စဉ်းစားခြင်းဖြင့် Pando သည် အင်ဂျင်နီယာများနှင့် အေးဂျင့်များ အသုံးပြုနေကျ Git လုပ်ငန်းစဉ်များကို မပြောင်းဘဲ ကျွန်ုပ်တို့၏ monorepo ကို ချဲ့ထွင်နိုင်စေသည်။ ကျွန်ုပ်တို့၏ monorepo တွင် Pando ကြောင့် တစ်ပြိုင်နက်လုပ်ဆောင်နိုင်မှု ပိုများလာပြီး merge ယုံကြည်စိတ်ချရမှု တိုးတက်ကာ ကုဒ်အပြောင်းအလဲများ ထုတ်ပြန်ရန် ကြာချိန် လျော့နည်းလာသည်။ monorepo အပြင် OpenAI အတွင်း Pando ကို အခြားနေရာများ၌ သုံးနိုင်ရန်လည်း စူးစမ်းနေသည်။ ယင်းတွင် အေးဂျင့်အများအပြားက မျှဝေထားသော Git သိမ်းဆည်းရန်နေရာတစ်ခု၌ ပူးပေါင်းလုပ်ရသည့် လုပ်ငန်းဝန်များလည်း ပါဝင်သည်။

အင်ဂျင်နီယာများနှင့် အေးဂျင့်များက ဆော့ဖ်ဝဲပိုမိုထုတ်လုပ်လာသည်နှင့်အမျှ OpenAI ပြင်ပမှ အဖွဲ့များလည်း source control တွင် ကျွန်ုပ်တို့ကြုံခဲ့သော အကန့်အသတ်များကို ပိုမိုကြုံလာရမည်။ လက်ရှိတွင် Pando ကို ဖြစ်မြောက်စေသော နည်းပညာကို အသုံးပြုသူများထံ မျှဝေနိုင်မည့် နည်းလမ်းများ စူးစမ်းနေသည်။

Pando သည် Git သိမ်းဆည်းရန်နေရာများ၏ အသုံးပြုသူများနှင့် စီမံလည်ပတ်သူများ၏ ဆယ်စုနှစ်နှစ်ခုစာ အတွေ့အကြုံပေါ် အခြေခံတည်ဆောက်ထားသည်။ Git အသုံးပြုသူများကို ကျယ်ကျယ်ပြန့်ပြန့် အကျိုးပြုမည့် တိုးတက်မှုများ မျှဝေရန် အများသုံးရင်းမြစ်ဖွင့် Git အသိုင်းအဝိုင်းနှင့် ပူးပေါင်းရင်း Pando ကို ဆက်လက်ဖွံ့ဖြိုးတိုးတက်စေမည်။