वर्ज़न कंट्रोल का भविष्य

• Manyana Bram Cohen द्वारा विकसित एक CRDT-आधारित version control prototype है, जो merge conflicts को खत्म करने और history को संरचनात्मक रूप से सुरक्षित रखने का एक नया approach पेश करता है
• CRDT (Conflict-Free Replicated Data Type) का उपयोग करके merge हमेशा सफल होता है, और conflict को सिर्फ जानकारी दिखाने वाले संकेत के रूप में संभाला जाता है ताकि users बदलावों को स्पष्ट रूप से समझ सकें
• इसके मुख्य सिद्धांत हैं line order की स्थायित्व, non-blocking merge, और history का संरचना में अंतर्निहित होना; rebase के दौरान भी पुराने records नष्ट नहीं होते
• लगभग 470 lines के Python code में लिखा गया यह demo-level implementation है, और पूरा code व design document public domain में GitHub पर उपलब्ध है
• Git की सीमाओं से आगे बढ़ते हुए यह merge failure रहित next-generation version control model का एक प्रयोगात्मक उदाहरण प्रस्तुत करता है

---

Manyana: वर्ज़न कंट्रोल के भविष्य के लिए एक सुसंगत दृष्टि

• Manyana Bram Cohen द्वारा जारी किया गया एक CRDT-आधारित version control system prototype है, जो मौजूदा systems में merge conflict की समस्या को हल करने का प्रयास करता है
• CRDT यह सुनिश्चित करता है कि merge हमेशा सफल हो, और conflict को जानकारीपूर्ण संकेत के रूप में संभालता है ताकि user वास्तविक बदलावों को स्पष्ट रूप से देख सके
• इस approach की तीन मुख्य विशेषताएँ हैं: line order की स्थायित्व, non-blocking conflict handling, और structure के भीतर history का अंतर्निहित होना
• rebase प्रक्रिया के दौरान भी यह पुरानी history को बनाए रखता है, और single common ancestor के बिना जटिल merge संरचनाओं को भी स्थिर रूप से संभाल सकता है
• Manyana लगभग 470 lines के Python code में लिखा गया एक demo implementation है, और इसका design document व code public domain में GitHub पर उपलब्ध हैं

CRDT-आधारित approach के मुख्य बिंदु

• CRDT में merge हमेशा सफल होता है, और merge के क्रम से स्वतंत्र एक जैसा परिणाम सुनिश्चित करने वाली eventual consistency मिलती है
  • कई users द्वारा स्वतंत्र रूप से बनाए गए branches को किसी भी क्रम में merge किया जाए, परिणाम समान रहता है
• line order की स्थायित्व के कारण एक ही स्थान पर डाले गए code का क्रम एक बार तय होने के बाद आगे भी बना रहता है
  • इससे अलग-अलग branches में conflict क्षेत्र अलग ढंग से resolve होने की समस्या रोकी जा सकती है
• conflict को केवल जानकारी देने वाले संकेत के रूप में संभाला जाता है, इसलिए merge रुकता नहीं है
  • merge result हमेशा तैयार होता है, और conflict को “करीबी स्थान पर एक साथ किए गए बदलाव” के रूप में दिखाया जाता है
  • हर बदलाव के कर्ता और क्रिया को track करके उपयोगी conflict markers दिए जाते हैं
• history संरचना के भीतर ही अंतर्निहित होती है
  • state को सभी file lines को शामिल करने वाली ‘weave’ structure से दर्शाया जाता है, जिसमें हर line के लिए add/delete समय का metadata शामिल होता है
  • merge के समय common ancestor खोजने या DAG traversal की ज़रूरत नहीं होती; सिर्फ दो states देने पर हमेशा सही result बन जाता है

बेहतर conflict संकेत

• मौजूदा version control systems conflict होने पर आम तौर पर सिर्फ दो code blocks साथ-साथ दिखाते हैं, जिससे user को खुद अंतर समझना पड़ता है
• Manyana हर conflict क्षेत्र को “हटाया गया”, “जोड़ा गया” जैसी स्पष्ट सूचना के साथ दिखाता है, और किसने कौन-सा बदलाव किया यह भी बताता है
  • उदाहरण के लिए, अगर एक user किसी function को हटा दे और दूसरा user उसी function के भीतर एक line जोड़ दे, तो Manyana दोनों बदलावों की संरचना को स्पष्ट रूप से अलग-अलग दिखाता है
  • इससे user को दो blocks की तुलना करने के बजाय बदलाव के अर्थ और संदर्भ को तुरंत समझने में मदद मिलती है

rebase की नई परिभाषा

• CRDT-आधारित system में rebase history को नष्ट नहीं करता
  • पारंपरिक rebase commits को नए base पर फिर से रखता है और एक कृत्रिम history बना देता है
  • Manyana में वही प्रभाव हासिल किया जा सकता है, लेकिन सारी मूल history सुरक्षित रहती है
• इसके लिए DAG में सिर्फ “primary ancestor” annotation जोड़ना पर्याप्त है
• यह तरीका common ancestor के बिना merge संरचनाओं में भी स्थिर रूप से काम करता है, और पारंपरिक 3-way merge की विफलता से बच सकता है

प्रोजेक्ट की वर्तमान स्थिति

• Manyana पूर्ण version control system नहीं बल्कि एक demo implementation है, जो individual file स्तर पर काम करता है
  • यह लगभग 470 lines के Python code से बना है
  • Cherry-pick और local undo features अभी लागू नहीं हुए हैं, लेकिन README में आगे की दिशा दी गई है
• यह project साबित करता है कि CRDT-आधारित version control UX समस्याओं को हल कर सकता है, और मौजूदा tools से बेहतर परिणाम दे सकता है
• पूरा code public domain में वितरित किया गया है, और पूरा design document GitHub README में शामिल है

कम्युनिटी प्रतिक्रिया का सार

• एक user ने कहा कि Git 10 साल से अधिक समय से इस्तेमाल हो रहा है, लेकिन एक नए version control paradigm की ज़रूरत है, और Manyana के प्रयास का सकारात्मक उल्लेख किया
  • उसने कहा कि merge हमेशा सफल होने का विचार सहज नहीं लगता, और अधिक उदाहरण व व्याख्या माँगी
  • उसने rebase सुधार के विचार में रुचि दिखाई, और बताया कि अपने निजी projects में वह मध्यवर्ती branches के माध्यम से merge प्रबंधन का तरीका इस्तेमाल करता है
  • उसने Git की सीमाओं के रूप में binary files का handling, left-right branch distinction में भ्रम, और बड़े code changes के सारांश की कमी जैसी बातें उठाईं
  • उसने सुझाव दिया कि भविष्य के version control में token-aware features या language/file-format specific plugins का समर्थन होना चाहिए
• एक अन्य user ने पूछा कि क्या Manyana की बुनियाद Pijul या Darcs जैसी है, और Darcs की performance समस्याओं तथा Pijul की मौजूदा स्थिति की तुलना माँगी

निष्कर्ष

• Manyana version control में CRDT लागू करने वाला एक व्यावहारिक demo है, जो conflict handling और rebase की समस्याओं को मूल रूप से फिर से डिज़ाइन करता है
• merge failure रहित संरचना, conflicts का सूचनात्मक रूपांतरण, और history का संरचनात्मक अंतर्निहित होना मौजूदा Git मॉडल की सीमाओं से आगे की design दिशा दिखाते हैं
• यह अभी पूर्ण system नहीं है, लेकिन next-generation version control system के design blueprint के रूप में एक महत्वपूर्ण शुरुआती बिंदु है

[GN⁺]

Hacker News की राय

• मेरा मानना है कि merge को दिखाने का तरीका history representation से अलग मुद्दा है
  मैं भी Git का default merge UI पसंद नहीं करता, इसलिए p4merge इस्तेमाल करता हूँ। यह चार panels (बायाँ, दायाँ, common base, result) दिखाने वाला टूल है, इसलिए conflict की वजह और उसका समाधान एक नज़र में दिख जाता है
  मुझे नहीं लगता कि इसके लिए VCS को ही बदलने की ज़रूरत है

  • p4merge न भी इस्तेमाल करें, तो Git की merge.conflictStyle setting को "diff3" या "zdiff3" में बदलने पर base version भी दिखता है
    इससे सिर्फ conflict markers देखकर भी अंदाज़ा लगाया जा सकता है कि नया code किस तरफ़ जोड़ा गया था
  • ज़्यादातर लोग इस समस्या के बारे में गहराई से नहीं सोचते
    पहले एक podcast में नए VCS बनाने वाले एक guest को Git के diff storage model को ग़लत समझते सुना था, तो हैरानी हुई। कई साल project चलाने के बाद भी basic concept तक न देखना यह दिखाता है कि NIH(पुनराविष्कार) की भावना अब भी ज़िंदा है
  • मैं भी p4merge recommend करता हूँ। अगर Git का merge तकलीफ़देह लगता है, तो वह conceptual problem से ज़्यादा UX design की समस्या है
  • JetBrains IDEs (जैसे IntelliJ) भी शानदार merge UI देती हैं
    लेकिन SCM level पर handle करने का फ़ायदा यह है कि यह user के merge history को याद रख सकता है। Git में इस मामले में कुछ edge cases हैं
  • क्या यह सामान्य directories को भी merge कर सकता है, यह जानने की जिज्ञासा है

• मुझे नहीं पता कि merge का कभी fail न होना सच में अच्छी बात है या नहीं
  कई बार merge failure सिर्फ positional conflict नहीं, बल्कि semantic conflict का संकेत होता है। ऐसे मामलों को manually handle करना पड़ता है

  • कहा गया है कि proposed system भी overlapping changes होने पर user को दिखाता है। Git से फ़र्क़ शायद बस defaults का मामला लगता है
  • व्यवहार में merge सफल हो जाने पर भी ऐसा code बन सकता है जो compile नहीं होता। मैंने AI tools से merge conflicts हल कराने की कोशिश की है, लेकिन ख़ासकर rebase में वे ठीक काम नहीं करते
  • यह system fail न होने वाला नहीं है, बल्कि conflict को दिखाते हुए भी merge जारी रखने का concept है। jj भी कुछ ऐसा ही approach लेता है
  • सिर्फ़ text merge पर निर्भर रहकर semantic problems पकड़ने की कोशिश की अपनी सीमाएँ हैं। इसकी जगह post-merge checks या agent-based intent validation बेहतर लगती है

• मुझे नहीं लगता कि CRDT version control के लिए उपयुक्त है
  conflict version control का मूल स्वभाव है। अगर दो developers code को अलग-अलग दिशाओं में बदलते हैं, तो आख़िरकार semantic choice करनी ही पड़ती है। CRDT ऐसे हालात में अजीब code बना सकता है
  Git के ऊपर बेहतर merge UX देने वाले tools पहले से बहुत हैं, और cherry-pick या revert का आसान होना भी Git की ताकत है

  • बेशक automatic merge सिर्फ़ syntactic conflicts सुलझाता है, semantic conflicts फिर भी बचे रहते हैं
    उदाहरण के लिए, एक branch में constant हटा दिया जाए और दूसरी branch में वही constant इस्तेमाल हो रहा हो, तो code टूट जाएगा
    Git के conflicts ज़्यादातर syntactic issues होते हैं, इसलिए ज़्यादा समझदार semantic merge या CRDT approach मददगार हो सकती है
  • CRDT को सिर्फ़ merge computation के लिए इस्तेमाल करना संभव है
    उदाहरण के लिए file names, attributes, hashes आदि track करने में OR-set(https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type) का उपयोग किया जा सकता है।
    लेकिन conflict resolution फिर भी external interface में ही संभालना होगा

• समझ नहीं आता कि CRDT पर इतना फ़ोकस क्यों है
  conflicts का semantic पक्ष तो फिर भी रहेगा। उल्टा changes interleave होकर दिख सकते हैं, जिससे और ज़्यादा उलझन हो सकती है
  मैं rebase-केंद्रित सोच रखता हूँ। merge commits से बचना चाहिए, और हर commit एक स्वतंत्र unit होना चाहिए। मुझे Gitflow anti-pattern लगता है
  Jujutsu या Gerrit, Git की असली समस्या यानी “review feedback के आधार पर commit chains manage करना” को बेहतर ढंग से हल करते हैं

  • “unit of work” क्या है, यही अहम सवाल है
    Git snapshots को फिर से apply करता है, इसलिए एक ही काम जैसे दो बार मौजूद होता है। जबकि Pijul patch units पर काम करता है और क्रम की परवाह किए बिना वही result देता है। मुझे यही सच में स्वतंत्र unit of work लगता है
  • CRDT merge और rebase को एक ही concept के रूप में संभाल सकता है
    conflict की स्थिति में भी किसी खास commit को undo किया जा सकता है। यह Git से ज़्यादा flexible structure दे सकता है
  • अगर हमेशा rebase ही करेंगे, तो हर commit पर conflict सुलझाना पड़ेगा, जो inefficient है
    व्यवहार में अक्सर सिर्फ़ final result मायने रखता है। squash merge को सही जगह मिलाकर इस्तेमाल करना ज़्यादा practical है
  • CRDT को हर समस्या का हल समझ लेना आसान है
    लेकिन कुछ समस्याओं में conflict का होना स्वाभाविक और ज़रूरी है। जैसे collaborative editor में characters के गड्डमड्ड हो जाने जैसी स्थिति, जो उल्टा और खराब नतीजा दे सकती है

• यह project शायद Bram के पुराने Codeville ideas का विस्तार लगता है
  Codeville 2000s की शुरुआत में DVCS boom के समय आया था, और इसमें weave-based storage and merge इस्तेमाल होता था। यह CRDT से 10 साल पहले का विचार है, लेकिन स्वाभाविक रूप से उसी दिशा में बढ़ता दिखता है
  Bram अब भी इस समस्या पर काम कर रहे हैं और नए प्रयोग कर रहे हैं, यह देखकर अच्छा लगता है

  • CRDT की असली ताकत आसानी से समझ में आने वाला behavior model है। इसे खुद implement करें तो इसकी structure साफ़ दिखती है
  • 2007 में Bram ने मेरे Causal Tree algorithm को weave का एक variant कहा था। उसके बाद weave family के algorithms काफ़ी आगे बढ़े, और इस पर papers भी हैं
    arxiv:2002.09511
  • CRDT कोई एक अकेली तकनीक नहीं, बल्कि एक conceptual framework है। आख़िरकार Git भी eventual consistency implement करता है, इसलिए व्यापक अर्थ में उसे भी CRDT कहा जा सकता है

• मैं इस बात से सहमत नहीं हूँ कि “CRDT-based VCS अभी मौजूद नहीं है”
  Pijul पहले से मौजूद है, और यह experts के हज़ारों घंटों की मेहनत वाला project है

  • इसका मतलब यह नहीं कि Bram ने VCS पर ज़्यादा काम नहीं किया। Codeville ही कम से कम 20 साल पुराना है
  • मुझे हर साल Pijul manual के theory page को देखने की आदत है। अब भी TeX formatting errors ठीक नहीं हुए हैं
    यह 6 साल से experimental है, और 4 साल पहले मैंने खुद issue भी डाली थी, लेकिन अब तक लागू नहीं हुआ
  • शुरू में मुझे पुराना GitHub repository मिला था, लेकिन असली official repository Nest पर है।
    Pijul एक VCS है जो खुद अपने ऊपर विकसित होता है, इसलिए GitHub इस्तेमाल नहीं करता
  • कभी-कभी pijul pull -a करने पर conflicts आ जाते हैं, तो मैं बस दोबारा clone कर लेता हूँ। क्या tracking updates के लिए कोई अलग pull मौजूद है, यह जानना चाहता हूँ

• manana.py 473 lines का dependency-free Python code है
  असली implementation सिर्फ़ लगभग 240 lines की है, बाकी test code है। साधारण है, लेकिन प्रभावशाली है

  • नाम खुद में एक joke है। “Mañana” स्पैनिश में कल होता है, लेकिन इसका मतलब “कभी बाद में करेंगे” भी हो सकता है। यानी यह procrastination की तरफ़ इशारा करता है
  • कुछ सौ lines के साफ़-सुथरे Python में ऐसा बनाना काफ़ी चौंकाने वाला है
    JS ecosystem की left-pad घटना याद करें, तो लगता है Python में भी ऐसे छोटे लेकिन ज़िम्मेदार packages ज़्यादा होने चाहिए

• ऐसे systems को design करते समय team size के हिसाब से merge conflicts के patterns का analysis होना चाहिए
  1, 10, 100, 1000 लोगों की teams किन समस्याओं से जूझती हैं, और agent-based development उससे क्या बदलता है, यह भी देखना चाहिए
  मेरे अनुभव में 1 से 100 लोगों के scale पर teams code subtrees बाँट लेती हैं, इसलिए conflicts लगभग नहीं होते।
  agents बढ़ें तो 100 लोग 1000 जैसे हो सकते हैं, लेकिन अभी तो लगता है कि solution पहले आया है, real problem बाद में

  • agents किसी भी version control system को संभाल सकते हैं
    आजकल तो बस Codex से merge conflicts हल करा दो, इसलिए नया VCS अपनाने की वजह और कम हो जाती है
    Git बड़े teams के लिए बनाया गया था, और agent के दौर में process automation से काफ़ी चीज़ें संभाली जा सकती हैं
  • team size बढ़ने पर भी स्वाभाविक रूप से code areas के हिसाब से specialization हो जाता है, इसलिए conflict की दर लगभग वैसी ही रहती है।
    असली समस्या अक्सर shared libraries के bottlenecks या access restriction policies में होती है
  • team-size analysis के आधार पर approach लेना उल्टा inefficient हो सकता है। बस conceptually consistent design ज़्यादा महत्वपूर्ण है

• conflicts से भी बड़ी समस्या Git की scalability है
  repository size और change velocity अपनी limits तक पहुँच रहे हैं। server, client और protocol सभी का redesign ज़रूरी है

  • किस तरह की scalability problems आईं, यह जानना चाहता हूँ। क्या यह monorepo की वजह से है?
  • एक समाधान यह है कि code को modularize किया जाए और version dependencies के ज़रिए refer किया जाए

• व्यक्तिगत रूप से मुझे साफ़ नहीं है कि यह system कौन-सी समस्या हल कर रहा है
  abstract स्तर पर दिलचस्प है, लेकिन व्यवहार में jj Git से कहीं ज़्यादा practical है
  मुझे लगता है अगला कदम file-level नहीं बल्कि AST level version control होना चाहिए।
  LightTable या Dark जैसे प्रयास हुए थे; ऐसे tree-based VCS पर प्रयोग करना अच्छा रहेगा

  • उस दिशा में काम पहले से चल रहा है। एक नया parser system बनाया जा रहा है