منصوبے کے بارے میں

9vcs ایک ورژن کنٹرول سسٹم ہے جو Go 9p لائبریری کے ذریعے Plan 9 پروٹوکول، 9P پر بنایا گیا ہے۔ اس کا مقصد ایک چھوٹی بھروسہ مند ٹیم ہے جو کسی ہوسٹنگ پلیٹ فارم کے بغیر حقیقی ورژن کنٹرول چاہتی ہے۔ تاریخ کو اسنیپ شاٹس کے بجائے مواد کے ذریعے ایڈریس شدہ پیچز (content-addressed patches) کے ایک سیٹ کے طور پر رکھا جاتا ہے؛ README ڈیزائن کی منطق کے لیے PLAN.md کی طرف اشارہ کرتا ہے اور خود کو عملی استعمال تک محدود رکھتا ہے۔ اس کی اصطلاحات جان بوجھ کر GitHub جیسی نہیں رکھی گئیں: اس میں clone، push، pull، fork یا pull request نہیں ہے، اور ایک چیٹ شیٹ عام اصطلاحات کو 9vcs کے متبادل سے جوڑتی ہے۔ ضروریات اور انسٹالیشن واحد ضرورت Go 1.26.5 یا اس سے بعد کا ورژن ہے۔ 9vcs اور وہ 9p لائبریری جس پر یہ بنایا گیا ہے، دونوں خالص Go ہیں اور صرف اسٹینڈرڈ لائبریری کا استعمال کرتے ہیں، جس میں کوئی ڈیمن، ڈیٹا بیس یا بیرونی خدمات شامل نہیں ہیں۔ پہلے سے بنے ہوئے بائنریز Releases پیج پر linux/amd64، linux/arm64، darwin/arm64 اور darwin/amd64 کے لیے tar.gz آرکائیوز کے طور پر شائع کی گئی ہیں، جن میں سے ہر ایک کی تصدیق کے لیے .sha256 چیک سم موجود ہے؛ آرکائیو میں بائنری، LICENSE اور README شامل ہیں۔ سورس سے بنانا cmd/9vcs کے خلاف ایک واحد go build کمانڈ ہے۔ متبادل طور پر، کچھ انسٹالرز دستیاب ہیں۔ سولو ورک فلو ایک ڈائریکٹری میں init چلانے کے بعد، status تبدیل شدہ راستے کے لیے ایک لائن پرنٹ کرتا ہے جس میں نئے کے لیے A، ترمیم شدہ کے لیے M، حذف شدہ کے لیے D اور غیر حل شدہ تنازع کے لیے U استعمال ہوتا ہے؛ یہ صرف وہی رپورٹ کرتا ہے جو 'ڈرٹی' ہے، نہ کہ diff۔ نقل مکانی (moves) کو رینیمز کے طور پر ٹریک نہیں کیا جاتا — ایک منتقل شدہ فائل حذف اور اضافے کے طور پر ظاہر ہوتی ہے، جو اس بات سے میل کھاتی ہے کہ بنیادی پیچ اسے کیسے اسٹور کرتا ہے۔ diff ورکنگ ٹری میں لائن لیول کی تبدیلیاں دکھاتا ہے، کسی دوسرے پوائنٹ کے خلاف diff کر سکتا ہے، یا ورکنگ ٹری کو شامل کیے بغیر دو پوائنٹس کا براہ راست موازنہ کر سکتا ہے۔ log ریکارڈ شدہ پیچز کو نئے سے پرانے کی ترتیب میں مصنف، فنگر پرنٹ یا دستخط کی حیثیت، اور متاثرہ راستوں کے ساتھ فہرست کرتا ہے۔ record ایک پیچ بناتا ہے۔ کوئی اسٹیجنگ ایریا یا انڈیکس مرحلہ نہیں ہے: ورکنگ ٹری خود اسٹیجنگ ایریا ہے، اور record اسے موجودہ head کے خلاف diff کرتا ہے۔ برانچز اور مرجنگ branch فہرست دکھاتا ہے، HEAD یا کسی دوسری برانچ یا ہیش سے بناتا ہے، اور checkout سوئچ کرتا ہے یا -b فلیگ کے ساتھ بناتا اور سوئچ کرتا ہے۔ مرجنگ حقیقی پیچ-گراف تنازعات پیدا کرتی ہے — لائن لیول فورکس، موازنہ سائیڈ کار فائل کے ساتھ بائنری تنازعات، اور موڈیفائی/ڈیلیٹ ریسز — بجائے اس کے کہ ایک سادہ تھری وے ٹیکسٹ diff ہو۔ ایک کلین مرج record کے ساتھ مکمل ہوتا ہے۔ ایک تنازعی مرج متاثرہ ٹیکسٹ فائلوں میں ان لائن تنازع کے نشانات چھوڑتا ہے، جبکہ بائنری تنازعات کو راستے اور موازنے کے لیے ایک مختصر ہیش کے نام سے سائیڈ کار فائل ملتی ہے؛ صارف اسے ایڈٹ کرتا ہے اور پھر ریکارڈ کرتا ہے۔ ایک مرج کو منسوخ (abort) کیا جا سکتا ہے، جس سے ورکنگ ٹری بالکل اپنی مرج سے پہلے کی حالت میں بحال ہو جاتی ہے اور مرج اسٹیٹ ختم ہو جاتی ہے، چاہے مرج merge کمانڈ سے آیا ہو یا apply سے۔ اگنور پیٹرنز ریپو رُوٹ کی .9vcsignore فائل .gitignore کی طرح کام کرتی ہے اور اسے ریکارڈ اور شیئر کرنے کے لیے بنایا گیا ہے۔ ایک لائن میں ایک پیٹرن؛ خالی لائنوں اور ہیش کمنٹس کو چھوڑ دیا جاتا ہے۔ بغیر سلیش والے پیٹرنز کسی بھی گہرائی پر میچ کرتے ہیں، سلیش والے پیٹرنز ریپو رُوٹ سے منسلک ہوتے ہیں، اور ٹریلنگ سلیش میچ کو حقیقی ڈائریکٹری تک محدود کرتا ہے۔ ندائی علامت (!) کے ساتھ نفی اور ڈبل اسٹار پیٹرنز واضح طور پر سپورٹڈ نہیں ہیں۔ اگنور پیٹرنز صرف نئی فائلوں کو record اور diff سے باہر رکھتے ہیں، اور بعد میں پیٹرن شامل کرنے سے پہلے سے ریکارڈ شدہ فائل حذف شدہ ظاہر نہیں ہوتی۔ ٹیم کا استعمال ہر انسٹالیشن پہلے استعمال پر ایک طویل مدتی Ed25519 کی پیئر (keypair) تیار کرتی ہے، اور identity show وہ فنگر پرنٹ پرنٹ کرتا ہے جسے ٹیم کے ساتھی ایک دوسرے کو مجاز بنانے کے لیے آؤٹ آف بینڈ تبدیل کرتے ہیں۔ جو بھی مشترکہ تاریخ ہوسٹ کرتا ہے وہ ایک پورٹ پر serve چلاتا ہے؛ سرور موجودہ ریپو میں .9vcs/authorized-peers کو پڑھتا ہے، جہاں ہر ساتھی کے لیے ایک فنگر پرنٹ اور اجازت کی لائن ہوتی ہے، جہاں اجازتیں read (صرف تاریخ کھینچنا)، propose (پڑھنا اور پیشکش کے علاقے میں دستخط شدہ بنڈل پوسٹ کرنا)، اور write (سب کچھ، بشمول برانچ ریف کو منتقل کرنا) ہیں۔ کوئی add-collaborator کمانڈ نہیں ہے — یہ صرف اس فائل کی ایڈیٹنگ ہے — اور فائل اسٹارٹ اپ پر ایک بار پڑھی جاتی ہے، اس لیے تبدیلیوں کے لیے ری اسٹارٹ کی ضرورت ہوتی ہے، جو کسی ممکنہ طور پر سمجھوتہ شدہ کی (compromised key) کو منسوخ کرتے وقت اہم ہوتا ہے۔ serve بغیر کسی بیک گراؤنڈ ڈیمن کے فور گراؤنڈ میں چلتا ہے۔ ایک نیٹ ورک پش اس برانچ کو منتقل کرنے سے انکار کرتا ہے جو سرونگ مشین پر اس وقت چیک آؤٹ ہے، اس لیے ہوسٹ کو ایک مختلف برانچ چیک آؤٹ رکھنی چاہیے یا سرونگ کے لیے مخصوص ڈائریکٹری استعمال کرنی چاہیے۔ ایک نیا ساتھی init اور import سے شروع کرتا ہے، جس میں ایک پیئر فنگر پرنٹ اور ایک ہوسٹ اور پورٹ پلس برانچ کا نام دیا جاتا ہے؛ import صرف فاسٹ فارورڈ ہے اور برانچ اور ہر پیچ اور بلاب (blob) کو کھینچتا ہے جس پر یہ ٹرانزیٹیو طور پر منحصر ہے۔ reconcile مسلسل سنک کرنے کی کمانڈ ہے: یہ کھینچتا ہے اگر پیئر آگے ہے، پش کرتا ہے اگر مقامی سائیڈ آگے ہے، اور حقیقی فرق کی صورت میں وہ حاصل کرتا ہے جو غائب ہے اور صارف سے کہتا ہے کہ وہ مقامی طور پر چیک آؤٹ اور مرج کرے بجائے اس کے کہ وائر کے ذریعے حل کرے۔ دونوں کمانڈز واضح طور پر ایک پیئر فنگر پرنٹ کو پن کر سکتی ہیں، ورنہ وہ مقامی trust-on-first-use اسٹور کا استعمال کرتی ہیں جو نئے ایڈریس کے لیے ایک بار پرامپٹ کرتا ہے، معلوم ایڈریسز کو خاموشی سے چیک کرتا ہے، اور اس فنگر پرنٹ سے سختی سے انکار کرتا ہے جو اچانک بدل جائے۔ آف لائن تبادلہ اور تجاویز بنڈلز کسی بھی چلتے ہوئے سرور کے بغیر تبدیلیاں منتقل کرتے ہیں: export ای میل، چیٹ یا ریمو ایبل میڈیا کے لیے ایک فائل میں دستخط شدہ بنڈل لکھتا ہے، اور وصول کنندہ bundle show (سائنر، پیغام، پیچز) کے ساتھ اس کا معائنہ کرتا ہے، دستخط کی تصدیق کرنے اور کسی بھی ریف کو چھوئے بغیر اسے مقامی طور پر اسٹور کرنے کے لیے اسے import کرتا ہے، diff کے ساتھ جائزہ لیتا ہے، اور پھر اسے apply کرتا ہے اور record کرتا ہے۔ Import کبھی بھی خود سے ریف کو منتقل نہیں کرتا۔ وہ ساتھی جن کے پاس صرف propose کی اجازت ہے وہ offer کا استعمال کرتے ہوئے براہ راست جمع کر سکتے ہیں، جو مینٹینر کے سرور پر ایک دستخط شدہ بنڈل پوسٹ کرتا ہے؛ مینٹینر زیر التواء پیشکشوں کی فہرست دیکھتا ہے، اسے حاصل کرنے، تصدیق کرنے اور مقامی طور پر اسٹور کرنے کے لیے ایک کو apply کرتا ہے، اسے apply کے ساتھ مربوط کرتا ہے، اور اسے قطار سے ہٹا دیتا ہے۔ کیونکہ پیشکشیں صرف لائیو سرور نیم اسپیس کے اندر موجود ہوتی ہیں، مینٹینر اپنے ہی serve انسٹنس سے جڑتا ہے اور اس لیے اسے authorized-peers فائل میں اپنے فنگر پرنٹ کی بھی ضرورت ہوتی ہے۔ 9sh اور نیم اسپیس ہینڈلنگ عام طور پر ریپو کو موجودہ ڈائریکٹری سے اوپر کی طرف جا کر حل کیا جاتا ہے، جیسے git میں۔ 9sh (ایک Plan 9 اسٹائل شیل) کے اندر، کمانڈ کے نام سے پہلے رکھا گیا -C فلیگ ایک دوسرا راستہ پیش کرتا ہے: یہ پہلے 9sh نیم اسپیس کے خلاف راستے کو آزماتا ہے — local کے تحت ایک رشتہ دار راستہ، یا ایک مطلق راستہ جو کسی بھی چیز پر حل ہو سکتا ہے جسے 9sh نے باندھا ہو — اس سے پہلے کہ وہ ایک لفظی OS راستے پر واپس جائے۔ 9sh سیشن کے باہر یہ فلیگ git -C کی طرح کام کرتا ہے۔ ریکوری دستاویزی ریکوری راستوں میں مرج یا apply کو منسوخ کرنا، ان کمٹ نہ کی گئی تبدیلیوں کو ریکارڈ کرنا یا دستی طور پر چھوڑنا جو چیک آؤٹ، مرج یا apply کو بلاک کرتی ہیں، restore کے ساتھ انفرادی راستوں کو head پر ان کی ریکارڈ شدہ حالت میں بحال کرنا (ایسا راستہ جس کی کوئی ریکارڈ شدہ حالت نہیں ہے اسے ہٹا دیا جاتا ہے، اس لیے رینیم کو واپس کرنے کا مطلب دونوں راستوں کا نام لینا ہے)، اور ایک پیئر فنگر پرنٹ کو دوبارہ پن کرنا ہے جو جائز طور پر تبدیل ہو گیا ہو۔ پروجیکٹ کی حیثیت README ٹیم کے ساتھ 9vcs استعمال کرنے اور خود ٹول کو ڈویلپ کرنے کے درمیان فرق کرتا ہے، جو مختصر مدت کی برانچز کے ساتھ trunk-based development پر عمل کرتا ہے، ایک محفوظ master جہاں کوئی براہ راست پش نہیں کرتا، CI جو مرج کرنے سے پہلے بلڈ، vet، gofmt اور ریس-انیبلڈ ٹیسٹز کا احاطہ کرتا ہے، صرف squash-only مرجز اور خودکار برانچ ڈیلیشن۔ ورژننگ ریلیز کے لیے semver پر عمل کرتی ہے، جو فی الحال v0.x رینج میں ہے۔ v1.0.0 سے نیچے، آن-ڈسک پیچ اور بنڈل فارمیٹ کے لیے کوئی مطابقت کا وعدہ نہیں ہے، جو مائیگریشن راستے کے بغیر تبدیل ہو سکتا ہے؛ v1.0.0 سے آگے، ریلیز شدہ فارمیٹ کے تحت ریکارڈ شدہ کوئی بھی پیچ یا بنڈل ڈی کوڈ کے قابل رہے گا، مستقبل کی غیر مطابقت پذیر تبدیلیوں کو حقیقی ورژن ڈسپیکچ اور فراہم کردہ مائیگریشن ٹولنگ کے ذریعے سنبھالا جائے گا۔ ایک چینج لاگ ریکارڈ کرتا ہے کہ ہر ریلیز کیا فراہم کرتی ہے۔