فیس بک (روسی فیڈریشن میں ممنوع) نے سیپلنگ سورس کنٹرول سسٹم شائع کیا، جو کمپنی کے اندرونی منصوبوں کی ترقی میں استعمال ہوتا ہے۔ سسٹم کا مقصد ایک مانوس ورژن کنٹرول انٹرفیس فراہم کرنا ہے جو دسیوں لاکھوں فائلوں، کمٹ اور شاخوں پر پھیلے ہوئے بہت بڑے ذخیروں کے لیے پیمانہ بنا سکتا ہے۔ کلائنٹ کوڈ Python اور Rust میں لکھا گیا ہے، اور GPLv2 لائسنس کے تحت کھلا ہے۔
ریپوزٹریز کے ساتھ موثر ریموٹ کام کے لیے ایک سرور کا حصہ الگ سے تیار کیا گیا ہے اور ایک مکمل ریپوزٹری کے طور پر ریپوزٹری کے ایک حصے کے مقامی ٹکڑے کے ساتھ کام کرنے کے لیے ایک ورچوئل فائل سسٹم تیار کیا گیا ہے (ڈیولپر پوری ریپوزٹری کو دیکھتا ہے، لیکن صرف مطلوبہ ڈیٹا تک رسائی حاصل کی جاتی ہے۔ مقامی نظام میں نقل کیا جاتا ہے)۔ فیس بک کے انفراسٹرکچر میں استعمال ہونے والے ان اجزاء کا کوڈ ابھی کھلا نہیں ہے لیکن کمپنی نے وعدہ کیا ہے کہ وہ اسے مستقبل میں شائع کرے گی۔ تاہم، فی الحال Sapling repository میں آپ Mononoke سرور (Rust میں) اور VFS EdenFS (C++ میں) کے پروٹو ٹائپس پہلے ہی تلاش کر سکتے ہیں۔ یہ اجزاء اختیاری ہیں اور Sapling کلائنٹ کام کرنے کے لیے کافی ہے، جو Git repositories کی کلوننگ، Git LFS پر مبنی سرورز کے ساتھ بات چیت کرنے اور GitHub جیسی گٹ ہوسٹنگ سائٹس کے ساتھ کام کرنے میں معاون ہے۔
سسٹم کا بنیادی خیال یہ ہے کہ جب کسی خاص سرور کے حصے کے ساتھ بات چیت کرتے ہوئے جو ذخیرہ کو ذخیرہ کرنے کی سہولت فراہم کرتا ہے، تمام کارروائیوں کو اس کوڈ میں اصل میں استعمال ہونے والی فائلوں کی تعداد پر منحصر کیا جاتا ہے جس پر ڈویلپر کام کر رہا ہے، اور اس پر انحصار نہیں کرتے ہیں۔ پورے ذخیرہ کا کل سائز۔ مثال کے طور پر، ایک ڈویلپر ایک بہت بڑے ریپوزٹری سے کوڈ کا صرف ایک چھوٹا سا حصہ استعمال کر سکتا ہے اور صرف وہی چھوٹا حصہ اس کے سسٹم میں منتقل ہو جائے گا، پوری ریپوزٹری میں نہیں۔ ورکنگ ڈائرکٹری متحرک طور پر بھری جاتی ہے کیونکہ ریپوزٹری سے فائلوں تک رسائی حاصل کی جاتی ہے، جو ایک طرف آپ کو کوڈ کے اپنے حصے کے ساتھ کام کو نمایاں طور پر تیز کرنے کی اجازت دیتی ہے، لیکن دوسری طرف نئی فائلوں تک رسائی میں سست روی کا باعث بنتی ہے۔ پہلی بار اور نیٹ ورک تک مسلسل رسائی کی ضرورت ہوتی ہے (الگ سے فراہم کردہ اور کمٹ کی تیاری کے لیے آف لائن وضع)۔
انکولی ڈیٹا لوڈنگ کے علاوہ، سیپلنگ ایسی اصلاح کو بھی لاگو کرتا ہے جس کا مقصد تبدیلیوں کی تاریخ کے ساتھ معلومات کی لوڈنگ کو کم کرنا ہے (مثال کے طور پر، لینکس کرنل کے ساتھ ذخیرہ میں موجود ڈیٹا کا 3/4 تبدیلیوں کی تاریخ ہے)۔ تبدیلیوں کی تاریخ کے ساتھ مؤثر طریقے سے کام کرنے کے لیے، اس سے وابستہ ڈیٹا کو ایک منقسم نمائندگی میں محفوظ کیا جاتا ہے جو آپ کو سرور سے کمٹ گراف کے انفرادی حصوں کو ڈاؤن لوڈ کرنے کی اجازت دیتا ہے۔ کلائنٹ سرور سے متعدد کمٹ کے درمیان تعلق کے بارے میں معلومات کی درخواست کرسکتا ہے اور گراف کا صرف ضروری حصہ ڈاؤن لوڈ کرسکتا ہے۔
یہ پروجیکٹ پچھلے 10 سالوں میں ترقی کر رہا ہے اور ایک ماسٹر برانچ کے ساتھ بہت بڑے یک سنگی ذخیروں تک رسائی کو منظم کرتے وقت مسائل کو حل کرنے کے لیے بنایا گیا تھا، جس میں "ضم" کے بجائے "ریبیس" آپریشن کا استعمال کیا گیا تھا۔ اس وقت، اس طرح کے ذخیروں کے ساتھ کام کرنے کے لیے کوئی کھلا حل نہیں تھا، اور فیس بک کے انجینئرز نے پروجیکٹوں کو چھوٹے ذخیروں میں تقسیم کرنے کے بجائے، ایک نیا ورژن کنٹرول سسٹم بنانے کا فیصلہ کیا جو کمپنی کی ضروریات کو پورا کرے گا، جس سے پیچیدگیاں پیدا ہوں گی۔ انحصار کا انتظام (ایک وقت میں، اسی طرح کے مسئلے کو حل کرنے کے لیے، مائیکروسافٹ نے GVFS پرت بنائی)۔ ابتدائی طور پر، فیس بک نے مرکیوریل سسٹم کا استعمال کیا اور پہلے مرحلے میں سیپلنگ پروجیکٹ کو مرکیوریل کے اضافے کے طور پر تیار کیا گیا۔ وقت گزرنے کے ساتھ، یہ نظام اپنے پروٹوکول، سٹوریج کی شکل اور الگورتھم کے ساتھ ایک آزاد پراجیکٹ میں تبدیل ہو گیا، جس میں گٹ ریپوزٹریز کے ساتھ بات چیت کرنے کی صلاحیت کے ساتھ بھی توسیع کی گئی۔
کام کے لیے، ایک کمانڈ لائن یوٹیلیٹی "sl" پیش کی جاتی ہے، جو عام تصورات، ورک فلوز اور گٹ اور مرکیوریل سے واقف ڈویلپرز کے لیے ایک انٹرفیس کو نافذ کرتی ہے۔ سیپلنگ میں اصطلاحات اور احکام گٹ سے قدرے مختلف ہیں اور مرکریئل کے قریب ہیں۔ مثال کے طور پر، شاخوں کے بجائے، "بک مارکس" استعمال کیے جاتے ہیں (نام کی شاخیں تعاون یافتہ نہیں ہیں)، بطور ڈیفالٹ، کلون/پل پر عمل کرتے وقت، پورا ذخیرہ لوڈ نہیں ہوتا، بلکہ صرف مرکزی شاخ، کمٹ کی کوئی ابتدائی نشانی نہیں ہوتی ہے ( اسٹیجنگ ایریا)، "git fetch" کے بجائے "sl" کمانڈ پل کا استعمال کیا جاتا ہے، "git pull" - "sl pull-rebase" کے بجائے، "git checkout COMMIT" - "sl goto COMMIT" کے بجائے "git reflog" - "sl journal"، "git checkout - FILE" کی بجائے تبدیلی کو منسوخ کرنے کے لیے "sl revert FILE" کی وضاحت کی گئی ہے، اور "." کو "HEAD" برانچ کی شناخت کے لیے استعمال کیا جاتا ہے۔ لیکن عام طور پر، شاخوں اور کلون/پل/پش/کمیٹ/ریبیس آپریشنز کے عمومی تصورات محفوظ ہیں۔
سیپلنگ ٹول کٹ کی اضافی خصوصیات میں سے، "سمارٹ لاگ" کے لیے تعاون نمایاں ہے، جو آپ کو اپنے ذخیرے کی حالت کا بصری طور پر جائزہ لینے، انتہائی اہم معلومات کو نمایاں کرنے اور غیر اہم تفصیلات کو فلٹر کرنے کی اجازت دیتا ہے۔ مثال کے طور پر، جب آپ sl یوٹیلیٹی کو بغیر دلیلوں کے چلاتے ہیں، تو اسکرین پر صرف آپ کی اپنی مقامی تبدیلیاں ظاہر ہوتی ہیں (دوسروں کو کم سے کم کیا جاتا ہے)، بیرونی شاخوں کی حالت، تبدیل شدہ فائلیں اور کمٹ کے نئے ورژن دکھائے جاتے ہیں۔ مزید برآں، ایک انٹرایکٹو ویب انٹرفیس پیش کیا جاتا ہے، جو سمارٹ لاگ کے ذریعے تیزی سے تشریف لے جانا، درخت کو تبدیل کرنا اور کمٹ کو ممکن بناتا ہے۔
سیپلنگ میں ایک اور قابل ذکر بہتری یہ ہے کہ یہ غلطیوں کو ٹھیک کرنا اور حل کرنا اور سابقہ حالت میں واپس جانا آسان بناتا ہے۔ مثال کے طور پر، کمانڈز "sl undo"، "sl redo"، "sl uncommit" اور "sl unamend" بہت سے آپریشنز کو رول بیک کرنے کے لیے پیش کیے جاتے ہیں؛ کمانڈز "sl hide" اور "sl unhide" کو عارضی طور پر کمٹ کو چھپانے کے لیے استعمال کیا جاتا ہے۔ اور پرانی حالتوں کے ذریعے انٹرایکٹو نیویگیشن کے لیے اور "sl undo -i کمانڈ" کمانڈ کے ساتھ مخصوص پوائنٹ پر واپس جائیں۔ پودا ایک کمٹ اسٹیک کے تصور کی بھی حمایت کرتا ہے، جو آپ کو پیچیدہ فعالیت کو چھوٹی، زیادہ قابل فہم اضافی تبدیلیوں (بنیادی فریم ورک سے لے کر مکمل فنکشن تک) کے سیٹ میں توڑ کر مرحلہ وار جائزوں کو ترتیب دینے کی اجازت دیتا ہے۔
سیپلنگ کے لیے کئی اضافے تیار کیے گئے ہیں، بشمول تبدیلیوں کا جائزہ لینے کے لیے ReviewStack انٹرفیس (GPLv2 کے تحت کوڈ)، جو آپ کو GitHub پر پل کی درخواستوں پر کارروائی کرنے اور تبدیلیوں کا اسٹیک ویو استعمال کرنے کی اجازت دیتا ہے۔ اس کے علاوہ، VSCode اور TextMate ایڈیٹرز کے ساتھ انضمام کے ساتھ ساتھ ISL (Interactive SmartLog) انٹرفیس اور سرور کے نفاذ کے لیے اضافے شائع کیے گئے ہیں۔
ماخذ: opennet.ru