सहयोगी संपादन के बारे में झूठ, भाग 1: ऑफलाइन संपादन के लिए एल्गोरिद्म

 (moment.dev)
2 पॉइंट द्वारा GN⁺ 2024-12-08 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Moment ने अपने मुख्य टेक्स्ट एडिटर के लिए सहयोगी संपादन का मूल्यांकन किया और पाया कि CRDT और OT श्रेणी के एल्गोरिद्म ऑफलाइन प्रत्यक्ष टकराव में ऐसे merge परिणाम बना सकते हैं जिन्हें उपयोगकर्ता डेटा क्षति मान सकते हैं
  • एक सरल उदाहरण में, जहाँ Alice पूरे वाक्य को मिटा देती है और Bob Color को Colour में बदलता है, अंतिम दस्तावेज़ में केवल u अक्षर बचता है जैसे मानवीय इरादे से परे परिणाम सामने आ सकते हैं
  • Moment के उपयोग मामलों में, आज़माए गए प्रत्यक्ष टकरावों में लगभग 20~30% के परिणाम स्वीकार करना कठिन थे, और उनकी आवृत्ति व नकारात्मक प्रतिक्रिया को देखते हुए इन्हें product experience के स्तर पर संभालना मुश्किल लगा
  • Yjs, ShareJS और Peritext ऑफलाइन संपादन, लंबे विलंब वाले collaboration, और स्वतंत्र प्रतियों के automatic merge का दावा करते हैं, लेकिन एल्गोरिद्म उपयोगकर्ताओं के इरादे और क्रम को जान नहीं सकते, इसलिए वे heuristic पर निर्भर करते हैं
  • ऑफलाइन सहयोगी संपादन केवल एल्गोरिद्म की समस्या नहीं, बल्कि अधिक UI/UX समस्या है; git merge UI या Ink & Switch की collaborative history जैसी ऐसी merge experience की ज़रूरत है जिसे इंसान पढ़कर समझ और जाँच सके

Moment के सहयोगी संपादन मूल्यांकन में उजागर सीमाएँ

  • 2024 की शुरुआत में Moment ने अपने मुख्य टेक्स्ट एडिटर में इस्तेमाल के लिए सहयोगी संपादन सिस्टम की जाँच शुरू की
  • कई एल्गोरिद्म यह दावा करते हैं कि वे सिर्फ online simultaneous editing ही नहीं, बल्कि ऐसे ऑफलाइन मामलों को भी संभालते हैं जहाँ उपयोगकर्ता बिना समय सीमा के ऑफलाइन संपादन करने के बाद फिर online होकर बदलावों को अपने आप merge कर सकें
  • शुरुआती दौर में papers और presentations देखने के बाद उम्मीद थी कि सहयोगी संपादन समुदाय इस समस्या के लिए व्यापक रूप से “सही उत्तर” तक पहुँच चुका है
  • लेकिन मूल्यांकन के दौरान CRDT और OT श्रेणी के एल्गोरिद्म ने प्रत्यक्ष संपादन टकरावों को सहज तरीके से हल नहीं किया, और उपयोगकर्ताओं ने उन परिणामों को डेटा क्षति की तरह लिया
  • चूँकि ऑफलाइन संपादन प्रत्यक्ष टकराव की संभावना को काफी बढ़ा देता है, केवल ऐसे एल्गोरिद्म के भरोसे Moment अपने मनचाहे ऑफलाइन editing experience तक नहीं पहुँच सका

deletion और spelling edit के टकराव का एक सरल उदाहरण

  • Alice और Bob दोनों ऑफलाइन स्थिति में एक ही दस्तावेज़ को संपादित कर रहे हैं
  • दस्तावेज़ में The Color of Pomegranates लिखा है
  • Bob, Color की वर्तनी को British English के अनुसार Colour में बदलता है, और Alice पूरा टेक्स्ट मिटा देती है
  • जब दोनों बाद में online होते हैं, तो दोनों edits में टकराव होता है, और सिस्टम को यह जाने बिना कि कौन-सा edit पहले हुआ, उन्हें समायोजित करना पड़ता है
  • इस मामले में Alice और Bob को अंततः ऐसा दस्तावेज़ मिलता है जिसमें केवल u अक्षर होता है
    • यह न कोई वैध वाक्य है, न कोई वैध शब्द
    • उपयोगकर्ता ऐसे परिणाम को इस तरह देखेंगे कि Moment ने उनके डेटा को क्षतिग्रस्त कर दिया

प्रत्यक्ष टकरावों के अजीब परिणाम दुर्लभ नहीं हैं

  • यह टकराव मामूली और सीधा editing conflict है, लेकिन फिर भी लोकप्रिय सहयोगी संपादन एल्गोरिद्म के कथित समर्थन दायरे के भीतर आता है
  • वास्तविक परिणाम ऐसा दस्तावेज़ था जिसे कोई इंसान खुद नहीं लिखेगा, और Moment के product ने मानो डेटा खराब कर दिया हो, ऐसा लगा
  • उपयोग मामला अलग-अलग हो सकता है, लेकिन Moment ने जिन प्रत्यक्ष टकरावों को आज़माया उनमें लगभग 20~30% ऑफलाइन editing use case में स्वीकार करना कठिन था
  • नकारात्मक feedback और उनकी आवृत्ति को साथ देखकर लगा कि ऐसे परिणामों को उपयोगकर्ताओं के सामने समझाना और defend करना कठिन है

टूल्स के ऑफलाइन editing समर्थन के दावे

  • शुरुआत में लगा कि शायद ऐसे परिणाम आने का मतलब यह है कि इन टूल्स के semantics को ठीक से समझा नहीं गया
  • लेकिन हर project का विवरण ऐसा पढ़ा जा सकता है कि यह scenario उसके समर्थित दायरे में आता है
    • Yjs अपने README में स्पष्ट रूप से offline editing समर्थन की बात करता है
    • ShareJS कहता है कि वह zero latency से लेकर लंबी छुट्टी जितनी देरी तक, किसी भी latency में collaboration को संभाल सकता है
    • Peritext कहता है कि उपयोगकर्ता दस्तावेज़ की स्वतंत्र प्रतियों को संपादित कर सकते हैं और उपयोगकर्ता के इरादे को यथासंभव सुरक्षित रखते हुए उन्हें automatically merge किया जा सकता है
  • Moment अब भी इस समस्या का समाधान ढूँढ रहा है, लेकिन वास्तव में देखी गई त्रुटियों की आवृत्ति और प्रकार को इन दावों के साथ मिलाना कठिन मानता है

समन्वय के बिना एल्गोरिद्म की मूलभूत सीमाएँ

  • मूल्यांकन आगे बढ़ने पर निष्कर्ष यह बना कि ये एल्गोरिद्म वह व्यवहार नहीं देते जो Moment चाहता है
  • बचा हुआ प्रश्न यह था कि क्या यह योगदान देकर ठीक किया जा सकने वाला मुद्दा है, या फिर एल्गोरिद्म की मूलभूत सीमा है
  • इसे मूलभूत समस्या मानने के तीन कारण हैं
    • एल्गोरिद्म Alice और Bob के इरादे नहीं जान सकते, और न ही वे ईमेल करके पूछ सकते हैं कि दोनों क्या चाहते थे, या GitHub Pull Request UI की तरह समीक्षा कर सकते हैं
    • Alice के पूरे deletion प्रस्ताव और Bob के spelling change प्रस्ताव को लेकर उन्हें heuristic के आधार पर परिणाम तय करना पड़ता है
    • वे character स्तर पर काम करते हैं और output के बारे में बहुत कमज़ोर guarantees देते हैं
    • अगर Alice और Bob को पता होता कि दूसरा क्या कर रहा है, तो वे शायद संपादन करने या न करने का फैसला अलग तरह से करते
  • यह बात उस समस्या से भी जुड़ती है कि ऐसे एल्गोरिद्म causal order का पालन नहीं कर पाते

ऑफलाइन editing, UI/UX के अधिक करीब की समस्या है

  • Moment को उम्मीद थी कि अगर वह जटिल एल्गोरिद्म लागू कर ले, तो सच्चे अर्थों में offline editing एक सहायक सुविधा की तरह मिल जाएगी, लेकिन मूल्यांकन के बाद यह मानना मुश्किल हो गया
  • उपयोगकर्ताओं का एल्गोरिद्म के परिणामों को डेटा क्षति मानना उचित था, अजीब परिणाम एल्गोरिद्म में अंतर्निहित हैं, और वे इतनी बार हो सकते हैं कि वास्तविक समस्या बन जाएँ
  • एक दूसरी व्याख्या यह है कि सहयोगी संपादन में पर्याप्त UI/UX संसाधन लगाने होंगे
  • एल्गोरिद्म समस्या को पूरी तरह हल नहीं कर सकते, लेकिन समाधान के एक हिस्से की भूमिका ज़रूर निभा सकते हैं

git merge UI और शोध की दिशा

  • दस्तावेज़ merge के लिए पहले से व्यापक रूप से अपनाया गया UI git है
  • शोध का प्रश्न इस बात के अधिक करीब है कि इस अनुभव को कितना अधिक सुलभ, समझने में आसान, और automate किया जा सकता है
  • 2009 के आसपास git द्वारा बदलावों को automatically merge करने में इस्तेमाल एल्गोरिद्म को लेकर काफी चर्चा थी
    • git ने Myers O(ND) diff algorithm अपनाया, और यह एल्गोरिद्म मुख्यतः जीवविज्ञानी BLAST-प्रकार sequence analysis में इस्तेमाल करते थे
    • Bram Cohen ने पाया कि diff परिणाम सहज नहीं लगते, इसलिए उन्होंने patience diff algorithm बनाया, जिसे अब बंद हो चुके git प्रतिद्वंद्वी टूल bzr ने अपनाया
  • उस समय की चर्चा का केंद्र इंसानों द्वारा पढ़े जा सकने वाले diff बनाना था, जबकि आज की चर्चा इस पर अधिक है कि क्या एल्गोरिद्म बिना मानवीय हस्तक्षेप के वही परिणाम हासिल कर सकते हैं
  • Ink & Switch की collaborative history जैसी रिसर्च सहयोगी संपादन को UI/UX समस्या की तरह देख रही है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-08
Hacker News की राय

  • मैं Eg-walker और ShareJS का लेखक हूं। लेख का टोन मेरे काम के खिलाफ लग सकता है, लेकिन असल में मैं पूरी तरह सहमत हूं और HN पर भी कई सालों से यही बात कहता आया हूं
    आज के real-time collaboration tools तब अच्छे चलते हैं जब सभी लोग online साथ में edit कर रहे हों, लेकिन अगर users offline या लंबे समय तक चलने वाली branch पर edit करते हैं, तो merge के समय conflict संकेत और manual review option चाहिए। खासकर code में यह और भी जरूरी है
    अच्छी बात यह है कि egwalker जैसे algorithms हर user के character-level edit traces और causal order, यानी Git DAG जैसी change order, को store करते हैं, इसलिए उनके पास Git से कहीं ज्यादा जानकारी होती है। इसलिए branch merge करते समय conflict range detect और display करने वाला CRDT बनाना संभव होना चाहिए, और user से manual resolution कराया जा सकता है
    Algorithmically यह दिलचस्प लेकिन पूरी तरह हल करने योग्य समस्या लगती है, और अजीब बात है कि text editing में अभी तक लगभग किसी ने इसे try नहीं किया लगता। अगर आप इस field में कोई मौलिक और valuable contribution करना चाहते हैं, तो यह CRDT ecosystem का एक महत्वपूर्ण missing piece है, इसलिए उम्मीद है कोई इसे करेगा
    [1] इस comment के नीचे की तरफ: https://news.ycombinator.com/item?id=19889174

    • ऐसा करने पर आखिरकार आप data model के हिस्से के रूप में conflict डाल रहे होंगे। CRDT के C, यानी “conflict-free”, को हासिल करने के तरीके के रूप में यह मजेदार है, लेकिन पूरी तरह justified है और शायद इकलौता तरीका भी हो सकता है
      अगला दिलचस्प challenge तब होगा जब conflict resolution को लेकर ही conflict पैदा हो जाए
    • Joseph, मेरा मतलब यह कहने का नहीं था कि तुम्हारा काम खराब है। इरादा practitioners को यह समझाने में मदद करने का था कि वे क्या expect कर सकते हैं, और आखिर में बताए गए issues जैसी चीजों के लिए motivation देने का था
      ऐसे systems को evaluate करना अपने आप में काफी कठिन technical problem है, इसलिए मुझे लगता है कई teams struggle करेंगी। इसलिए वे practical advice की हकदार हैं, और मुझे लगता है काश हमें भी यह पहले पता होता
    • मैं इस बात पर skeptical हूं कि algorithmic solution संभव होगा या नहीं, लेकिन उसके ऊपर की UX layer में इसे handle किया जा सकता है। उदाहरण के लिए, client edit traces के आधार पर conflicts detect कर सकता है और conflict resolution dialog दिखा सकता है, जिसमें resolution result को new edit बनाया जाए
      मुश्किल हिस्सा यह mark करना है कि conflict resolve हो चुका है। CRDT में एक field जोड़ना जितना simple हो सकता है, लेकिन फिर पता नहीं इसे algorithmic solution माना जाना चाहिए या नहीं
      [1] https://josephg.com/blog/crdts-go-brrr/
    • लेख overlapping concurrent splice cases को handle करता है, जो एक well-known अजीब edge case है
      अगर program code editing की बात हो, तो आप expect करते हैं कि merge result एक valid program हो, इसलिए यह कहीं ज्यादा गहरी rabbit hole बन जाती है। सुना है JetBrains में AST-based merge से यह समस्या हल करने की कोशिश करने वाला project था, लेकिन काफी गहराई तक जाने के बाद उन्होंने तय किया कि यह करने लायक नहीं है
    • मुझे लगता है “offline” editing इंसानी समस्या है, इसलिए automation से हल नहीं हो सकती। लोग automation या system को तोड़ने या bypass करने का तरीका खोज ही लेते हैं
      इंसानों द्वारा इस्तेमाल किए जाने वाले documents में जिस “offline editing” की अनुमति होनी चाहिए, वह सिर्फ comments जोड़ना है। कोई editing नहीं, कोई auto-merge नहीं
      Automation target source code की “offline editing” के लिए Git इस्तेमाल होता है, और Git merge solve करने का दिखावा नहीं करता, सिर्फ revisions दिखाता है। Merge वह काम है जिसे इंसान supervise करते हैं या specialized automation best guess के रूप में करता है, और success verify करने के लिए अब भी review और tests चाहिए

  • Mechanical merge algorithms conflict के type के हिसाब से बेहतर या खराब कर सकते हैं, लेकिन आखिरकार कोई भी CRDT यह judge नहीं कर सकता कि merged text वही है जो user कहना चाहता था
    Upwelling paper writing में semantic conflict और grammatical conflict कहलाने वाले फर्क को और detail में cover करता है: https://inkandswitch.com/upwelling/
    मुझे लगता है serious collaboration आखिरकार document review problem भी है। Journalism या scientific publishing में खासकर ऐसा है, और meeting notes में आम तौर पर इसे ignore किया जा सकता है

    • Peter, अच्छी बात कहने के लिए धन्यवाद। उम्मीद है आपने देखा होगा कि लेख का बड़ा हिस्सा अंत में सीधे जिस Ink & Switch काम का जिक्र करता है, उसे motivate करने की दिशा में खत्म होता है
      मैं Upwelling को भी link करना चाहता था, लेकिन नाम याद नहीं आ रहा था, इसलिए deadline के कारण दूसरे link से काम चलाया

  • CRDT implementation का एक और dark side infrastructure load है। मैंने पहले इस बारे में detail में लिखा था[0], और यह जानकर अच्छा लगा कि Supabase ने भी कुछ साल पहले Postgres के लिए CRDT extension पर अपने article[1] में मेरे empirical results जैसी ही conclusion निकाली
    अगर आप CRDT इस्तेमाल करने वाले हैं, तो Redis जैसी चीज इस्तेमाल करें, या memory usage के बारे में सोचते ही सिरदर्द होता है फिर भी MyRocks[2] या RocksDB/LevelDB based backend बेहतर है। जो भी करें, RDBMS, खासकर Postgres, को backend न रखें
    [0]: https://news.ycombinator.com/item?id=40834759
    [1]: https://supabase.com/blog/postgres-crdt
    [2]: http://myrocks.io

    • मैं Yjs + Postgres से खुद बना रहा हूं, इसलिए यह सचमुच उपयोगी लग रहा है। शायद किसी दिन यह मुझे बड़े संकट से बचा दे

  • इस लेख की observations सही हैं। CRDT distributed data structures के लिए एक बेहतरीन formal model है, लेकिन यह विचार कि सभी conflicts को अपने-आप resolve होना चाहिए, और नाम के मुताबिक conflict-free replicated data type की धारणा, मुझे हमेशा असहज करती रही है
    जैसा कि लेख दिखाता है, मुझे लगता है कि यह एक निराशाजनक कोशिश है। जरूरत conflicts को साझा करने और collaboration से हल करने के लिए एक सही structural representation की है, जिससे users को control वापस मिले और resolution process को support किया जा सके। मेरे पसंदीदा papers में से एक “Turning Conflicts into Collaboration” [1] इस idea को प्रभावी ढंग से समझाता है
    अपने ongoing PhD research में मैंने lattice theory पर आधारित structural conflict representation का formal model “Lazy Merging: From a Potential of Universes to a Universe of Potentials” [2] विकसित किया है। संयोग से यह भी CRDT है, लेकिन conflicts को अपने-आप resolve करने की कोशिश नहीं करता, बल्कि उन्हें collaborative document के अंदर represent करता है। Mathematical approach अपनाने से मैं एक simple conceptual model तक पहुंच सका, जो repeated merging से गुजर चुके existing conflicts के बाद भी merge की completeness, minimality, uniqueness जैसी मजबूत properties guarantee करता है, और merge computation भी बहुत आसान है
    [1] https://doi.org/10.1007/s10606-012-9172-4
    [2] https://doi.org/10.14279/tuj.eceasst.82.1226

    • जब मैंने पहली बार CRDT सीखा था, तब इसका full form commutative replicated data types, यानी commutative replicated data types था। Shapiro वगैरह के papers में भी यही था, और उच्चारण कठिन होने के बावजूद मुझे यह ज्यादा पसंद है
      Conflict एक जटिल concept है, और “conflict-free” result को describe करने के लिए technically सही है, लेकिन जैसा इस लेख और ऊपर की बातों में दिखता है, यह गलतफहमी पैदा कर सकता है
      Commutativity वह property है जिसमें Bob changes को [Bob, Alice] क्रम में apply करे और Alice [Alice, Bob] क्रम में apply करे, फिर भी दोनों same document पर पहुंचते हैं। इसका मतलब यह नहीं है कि higher abstraction level पर document meaningful तरीके से “conflict-free” है

  • बिना real-time coordination के कई अलग-अलग entities का एक ही data piece पर एक साथ authority रखना, सामान्य तौर पर हल नहीं किया जा सकता—मुझे ऐसा लगता है। यह distributed systems से पहले ही सीखा गया सबक है, और document distributed editing के बारे में सोचें तो इस लेख में भी यह साफ दिखता है
    Aeroplane cockpit में dual input, parenting, और ऐसे दूसरे अलग-अलग examples पर भी शायद यही principle लागू होता है

    • इसे हल किया जा सकता है, लेकिन इसके लिए ज्यादा complex contextual information चाहिए, जिसे input करना बहुत से लोगों को झंझट लगेगा। जैसे “अभी बदला गया यह word तभी meaningful है जब यह पूरे sentence का हिस्सा हो, और वह पूरा sentence पूरे paragraph के लिए अनिवार्य नहीं है” जैसी information
      और इसे “हल किया जा सकता है” कहना भी मजाकिया है, क्योंकि आज की स्थिति में दुनिया का बड़ा हिस्सा शायद यह मानने के करीब है कि LLM के chaotic output ही computation के final result को तय करें
    • यह distributed data storage के लिए Brewer का CAP theorem है। तीन में से केवल दो चीजें मिल सकती हैं: consistency, availability, partition tolerance

  • Collaborative text editing में आम तौर पर इस्तेमाल होने वाले algorithms, CRDT और OT, editing operations क्या करते हैं और कैसे interact करते हैं, इस पर सख्त algebraic requirements रखते हैं
    इसलिए server “Colour” example को UX के लिहाज से reasonable तरीके से handle करने जितना smart हो, तब भी optimistic client-side editing के लिए corresponding CRDT/OT design करना बहुत मुश्किल है
    CRDT/OT न इस्तेमाल करें तो इससे बचा जा सकता है। उदाहरण के लिए server operations को receive order में process करे और desired UX logic apply करे, और clients उसके ऊपर optimistic editing allow करने के लिए rebase/prediction strategy इस्तेमाल करें। संदर्भ: https://doc.replicache.dev/concepts/how-it-works
    इसे text editing पर apply करने में भी कठिनाइयां हैं, लेकिन वे यहां discuss हो रही CRDT/OT problems से अलग हैं

    • यह comment बहुत underrated है, और मैं पूरी तरह सहमत हूं

  • मुझे लगता है ऐसा इसलिए होता है क्योंकि mathematical, causal, और entropic conflict concepts semantic conflicts के साथ घुल-मिल गए हैं। मैंने भी पहले उल्टा वही गलती की थी, और मुझे साफ-साफ कहा गया था कि मुझे पता नहीं मैं क्या कह रहा हूं
    Trees पर विचार करना शुरू करें तो मामला और भी गड़बड़ हो जाता है। उदाहरण के लिए yJS JSON documents पर काम करता है। अगर UI केवल shallow level दिखाता है और deeper levels expanded नहीं हैं, तो user deleted edits को देख ही नहीं पाएगा
    Conflict-preserving CRDTs की category—जहां तक याद है, registers के multiple values हो सकने वाला case सबसे promising लगता है। Users को ऐसे conflicts दिखाए जाने चाहिए, और उन्हें पूरी तरह visual रूप में भी दिखाया जा सकता है। History browse करने देना भी एक practical alternative लगता है, जिससे user समझ सके कि कोई अजीब चीज कैसे हुई, या उसका change कैसे गायब हो गया

    • इस तरह के CRDT के लिए “Git” नाम अच्छा लगेगा
    • उस लिहाज से Loro promising लगता है। यह इस problem को actively address कर रहा है

  • मुझे याद है कि Torvalds खुद भी automatic merge से क्या हासिल किया जा सकता है, इसे लेकर काफी निराशावादी थे। और उनका आकलन सही था
    उन्होंने कहा था कि Git ने इस विचार को खारिज किया कि कोई version control system “merge problem को हल” कर सकता है या उसे करना चाहिए, इस तरह कि कोई पर्याप्त smart algorithm अपने-आप सही काम कर दे
    मैं सहमत हूं कि offline editing एक UI/UX समस्या है। इसकी गहरी वजह computing industry की पुरानी समाधानों को दोहराने की आदत है, और यह विश्वास कि “आम तौर पर 5-pound का थैला 10-pound के थैले से संभालना आसान होता है, इसलिए 10-pound का सामान एक 5-pound के थैले में डाल देना चाहिए”
    “text editor” की मूल छवि Mosaic textarea, MacWrite, या इनके बीच की कोई चीज़ है, इसलिए आम तौर पर लोग न्यूनतम बदलावों के साथ merge को उसी के ऊपर चिपकाने की कोशिश करते हैं। जैसे किसी menu item या छोटे dialog box में कुछ options जोड़ देना। menus के अंदर कहीं GUI merge support हो भी तो वह programmer-oriented diff/merge horror जैसा होता है, या फिर strikethrough-based view तक सीमित रहता है जिसमें ऐसा लगता है जैसे धुंध में जहाज़ चला रहे हों
    लेकिन offline collaboration वाले text editor में आंशिक manual merge प्रक्रिया का केंद्र होता है, और editor design के केंद्र में भी होना चाहिए। दुर्भाग्य से MacWrite एक ऐसा local optimum है जिससे निकलना मुश्किल है

    • फिर सवाल बचता है कि विकल्प क्या है
      उदाहरण के लिए, “cargo-cult style copying” और “पुराने समाधान” की बात करने वाले व्यक्ति की अगली बात अक्सर होती है कि “code को text की तरह edit मत करो, उसे syntax tree की तरह edit करो”, लेकिन समस्या वैसी ही रहती है। बस “character” को “sentence” से बदल देना है
      अगर Bob ने if statement की else branch में एक line जोड़ी और Alice ने पूरी statement को else branch समेत delete कर दिया, तो smart system को क्या करना चाहिए?
    • लगता है मैंने automatic merge वाली बात भ्रमित तरीके से लिख दी। मेरा मतलब यह था कि अगर कई commits एक file बदलते हैं तो Git उन्हें साथ merge करने की कोशिश करता है, लेकिन direct conflicts को अनिवार्य रूप से दिखाना चाहिए
      कुल मिलाकर लगता है कि हम सहमत हैं कि यह approach सही है

  • सवाल या feedback लेने को तैयार हूं। एक-दो घंटे तक meetings में रहूंगा, लेकिन ऐसी बातों पर चर्चा करना पसंद है। यहां भेजें या email पर, जो सुविधाजनक हो: alex@moment.dev

    • अगर offline support बनाए रखते हैं तो आखिरकार और दिलचस्प cases सामने आएंगे। उदाहरण के लिए: “plane में Wi-Fi नहीं था, इसलिए मैं इस पर काम कर रहा था, फिर दिशा पसंद नहीं आई तो laptop बंद करके झपकी ले ली। उसके बाद कुछ दिनों तक desktop पर document पर काम किया। weekend में laptop पर document खोला तो plane में किए गए सारे changes document में आ गए और सब गड़बड़ हो गया। मदद करें, मेरा merge करने का इरादा नहीं था!”
      Git explicit consent के बिना local changes को अपने-आप mix नहीं करता। bzr ने भी शायद ऐसा करने का सपना नहीं देखा होगा। लेकिन Google Docs जैसी चीज़ें खुशी-खुशी ऐसा कर देती हैं
      अब तक की progress शानदार है, और आशा है कि early access program भी अच्छा चलेगा
    • बस patch/diff-based merge अपनाने में क्या दिक्कत है? अगर offline collaborative text editing को केवल UX optimization problem के रूप में पेश किया जाए, तो यह समस्या दशकों पहले हल हो चुकी है

  • मैंने differential sync(https://neil.fraser.name/writing/sync/) implement किया। बाकी चीज़ें समझ नहीं आईं, और grugnotes.com app के लिए यह सबसे सरल लगा
    app काफी rough है और पूरी तरह real-time भी नहीं है, लेकिन example वाला merge, जो भी पहले online वापस आए, सही तरीके से handle करता है। अगर deletion पहले online आता है, तो colour version फेंक दिया जाता है और edit history में भी save नहीं होता
    और भी समस्याएं होंगी, और दो से ज्यादा users के case में क्या होगा यह भी नहीं पता, लेकिन मेरे use case के लिए मैं संतुष्ट हूं