टेक्स्ट डिफ चेकर

यह कैसे काम करता है

यह तुलना लॉन्गेस्ट कॉमन सबसीक्वेंस (LCS) एल्गोरिद्म पर बना एक लाइन-लेवल डिफ है, जो git diff के पीछे वाले लॉजिक के उसी परिवार का है। दोनों टेक्स्ट को लाइनों में बांटा जाता है, फिर एक डायनामिक-प्रोग्रामिंग टेबल यह पता लगाती है कि दोनों वर्ज़न किस क्रम में सबसे ज़्यादा लाइनें शेयर करते हैं। उस टेबल को पीछे की ओर ट्रेस करने पर वे ऑपरेशन मिलते हैं जो आप देखते हैं: सिर्फ़ बाईं तरफ़ की लाइनें लाल रंग में रिमूवल के रूप में मार्क होती हैं, सिर्फ़ दाईं तरफ़ की लाइनें हरे रंग में एडिशन के रूप में, और शेयर की गई लाइनें न्यूट्रल रहती हैं, हर एक अपनी ओरिजिनल लाइन नंबर के साथ।

लाइन-लेवल डिफिंग एक जानबूझकर लिया गया ट्रेडऑफ़ है। कैरेक्टर-लेवल डिफ यह दिखा सकते हैं कि किसी लाइन के अंदर एक शब्द बदला, लेकिन असली डॉक्यूमेंट्स पर वे कन्फ़ेटी में बदल जाते हैं: सैकड़ों छोटे-छोटे टुकड़े जो सिर्फ़ पुरानी लाइन हटी और नई लाइन जुड़ी देखने से ज़्यादा पढ़ने में मुश्किल होते हैं। लाइन-लेवल आउटपुट पढ़ने लायक बना रहता है और सीधे उस तरीक़े से मेल खाता है जैसे कोड रिव्यू और वर्ज़न कंट्रोल बदलावों को दिखाते हैं। दोनों चेकबॉक्स यह ट्यून करते हैं कि "बराबर" का मतलब क्या है: व्हाइटस्पेस इग्नोर करें, तुलना से पहले लगातार स्पेस को समेट देता है और लाइन के आख़िर को ट्रिम कर देता है (रीफ़ॉर्मैट किए गए कोड के लिए बढ़िया), और केस इग्नोर करें दोनों तरफ़ को लोअरकेस कर देता है। दिखाई गई लाइनें दोनों ही स्थिति में अपना ओरिजिनल फ़ॉर्मैटिंग बनाए रखती हैं।

चूंकि DP टेबल की मेमोरी और समय की लागत (A में लाइनें) x (B में लाइनें) के अनुपात में होती है, टूल इनपुट को हर तरफ़ 4,000 लाइनों तक सीमित रखता है; इस लिमिट के बाद, अकेले टेबल में करोड़ों सेल हो जातीं और टैब अटकने लगता। लिमिट के अंदर, सब कुछ आपके ब्राउज़र में सिंक्रोनसली चलता है: दोनों टेक्स्ट सिर्फ़ आपके टैब में रहते हैं, टाइप करते समय कोई रिक्वेस्ट फ़ायर नहीं होती (डेवटूल्स के Network पैनल में चेक करें), और गोपनीय ड्राफ़्ट या कॉन्फ़िग कभी सर्वर को नहीं छूते।