भिन्नता

Question

के बजाय सामग्री को संग्रहीत करने पर गिट डिज़ाइन का निर्णय क्या कोई मुझे कुछ विचार दे सकता है कि क्यों गिट डेवलपर्स ने फ़ाइलों (सामग्री) की सामग्री को स्टोर करने का डिज़ाइन निर्णय लिया है, इसलिए जब सामग्री को नए ब्लॉब को बदलने की आवश्यकता होती है?

मेरा मानना ​​है कि सबवर्सन सामग्री की बजाय संशोधनों को संशोधित करता है, इसलिए जब सामग्री बदलती है, तो यह केवल दोनों के बीच अंतर का ट्रैक रखती है। गिट ने ऐसा भी नहीं किया हो सकता है? संशोधन के बजाय सामग्री भंडारण का क्या फायदा है?

Answer 1

मुझे एक त्वरित Google के साथ जवाब नहीं मिला, लेकिन मेरा मानना ​​है कि यह एक साधारण "इससे कोई फर्क नहीं पड़ता" कारण डिस्क स्थान सस्ता है "।

स्रोत कोड प्रबंधन उपकरण के भीतर संशोधन संग्रहीत करना मुश्किल है। ,

1. नवीनतम संशोधन (सामान्य मामले) रिटर्निंग सबसे काम की आवश्यकता है के रूप में कोड है कि संशोधन को इकट्ठा करने की जरूरत है: आप केवल कभी पिछले संशोधन और वर्तमान के बीच के अंतर की दुकान हैं, तो आप दो समस्याओं के साथ खत्म एक साथ प्रत्येक संशोधन संयोजन।
2. एक संशोधन में कोई भी त्रुटि (कहें, एक डिस्क गलती) प्रत्येक बाद के संशोधन तक पहुंच दूषित करती है।

मेरा मानना ​​है कि अधिकांश आधुनिक वीसीएस वास्तव में नवीनतम संशोधन (प्रदर्शन कारणों के लिए) और अंतर का उपयोग करते हैं, यदि उपयोग किए जाते हैं, तो समय पर वापस जाने के लिए उपयोग नहीं किया जाता है, आगे नहीं।

Answer 2

एक लेख जो इस (और संबंधित) मुद्दों को संबोधित करता है Repository Formats Matter है। यह उन लेखों में से एक था जो कुछ साल पहले गिट में जाने के मेरे फैसले को प्रभावित करते थे। यहां एक अंश दिया गया है:

इस तर्क को देखते हुए, यह स्पष्ट होना चाहिए कि मुझे लगता है कि गिट की रिपोजिटरी संरचना कम से कम X.org के उपयोग मॉडल के लिए दूसरों की तुलना में बेहतर है। ऐसा लगता है कि कई रोचक गुण हैं:

1. ऑब्जेक्ट डेटा वाली फ़ाइलें कभी संशोधित नहीं होती हैं। एक बार लिखा जाने पर, प्रत्येक फ़ाइल केवल उस बिंदु से पढ़ी जाती है।

2. संपीड़न ऑफ़लाइन किया जाता है और प्राथमिक वस्तुओं को बैकअप मीडिया में सहेजने के बाद तक देरी हो सकती है। यह विधि किसी भी वृद्धिशील दृष्टिकोण की तुलना में बेहतर संपीड़न प्रदान करती है, जिससे डेटा को उपयोग पैटर्न से मिलान करने के लिए डिस्क पर पुन: आदेश दिया जा सकता है।

3. ऑब्जेक्ट डेटा स्वाभाविक रूप से स्व-जांच है; आप रिपॉजिटरी में ऑब्जेक्ट को संशोधित नहीं कर सकते हैं और ऑब्जेक्ट का संदर्भ देने पर पहली बार पहचान से बच सकते हैं।

Answer 3

मुझे अपने गलतफहमी अप स्पष्ट करते हैं:

किसी को भी मुझे क्यों Git डेवलपर्स फ़ाइलें (धब्बे) की सामग्री स्टोर करने के लिए एक डिजाइन निर्णय लिया करने के लिए कुछ विचार है, इसलिए जब दे सका सामग्री एक नया ब्लॉब बनाने की जरूरत है?

(प्रारंभिक) Git डिजाइन की काफी अच्छा विवरण टॉम प्रेस्टन-वर्नर के The Git Parable निबंध (Greg Hewgill answer में से जुड़ा हुआ एक के अतिरिक्त) में पाया जा सकता।

इसके पीछे विचार यह है कि एक नई संशोधन में आमतौर पर (बड़ी पर्याप्त परियोजना में) एक परियोजना परिवर्तन में बड़ी संख्या में फाइलों से बाहर कुछ फाइलें होती हैं, इसलिए फ़ाइल सामग्री के केवल अलग-अलग संस्करणों को संग्रहीत करने से अंतरिक्ष बचाता है। यह वही विचार है कि सबवर्जन का उपयोग अपनी 'सस्ती प्रति' तकनीक में करता है (यह हार्डलिंकिंग, आईआईआरसी का उपयोग करता है)।

इसके अलावा फ़ाइल की सामग्री zlib (डिफ्लेट) संपीड़ित (या गिट रिपोजिटरी डेटाबेस में प्रत्येक ऑब्जेक्ट को संपीड़ित किया गया है, कॉमिट ऑब्जेक्ट्स सहित संकुचित है)।

मेरा मानना ​​है कि सामग्री सबवर्सन भंडार संशोधन के बजाय, इसलिए जब सामग्री में परिवर्तन, यह बस दोनों के बीच अंतर का ट्रैक रखता है। गिट ने ऐसा भी नहीं किया हो सकता है? संशोधन के बजाय सामग्री भंडारण का क्या फायदा है?

मुझे समझ में नहीं आता कि आप यहां क्या कहना चाहते हैं।

यदि यह भंडारण अंतर अंतरिक्ष को बचाता है, तो मैं आपको बताना चाहता हूं कि 'ढीला' प्रारूप के अलावा (जहां प्रत्येक ब्लॉब, यानी फ़ाइल की प्रत्येक (अलग) सामग्री अलग फ़ाइल में संग्रहीत होती है .git) 'पैक' प्रारूप है, जहां लिबक्सडिफ़ लाइब्रेरी से बाइनरी डेल्टा का उपयोग करके कई वस्तुओं को डेल्टाइफाइड रूप में संग्रहीत किया जाता है।

यह प्रारूप नेटवर्क स्थानांतरण के लिए बनाया गया था (बड़ी डिस्क स्थान सस्ता हो सकती है, लेकिन बैंडविड्थ नहीं है), और ऑन-डिस्क प्रारूप के रूप में अनुकूलित किया गया था। यह प्रारूप बहुत ही कुशल है, यदि अधिक कुशल संस्करण नियंत्रण प्रणाली स्वरूप नहीं हैं, तो गिट रिपॉजिटरीज़ छोटे या विभिन्न संस्करण नियंत्रण प्रणालियों के बीच सबसे छोटे में से एक को अधिक कुशलता में से एक है। परिस्थितियों पर निर्भर करता Git भंडार से भरा क्लोन (जो पूरा इतिहास होता है) बराबर सबवर्सन चेकआउट की तुलना में छोटे हो सकता है (जो प्राचीन परिवर्तन के अतिरिक्त प्रति होता है ताकि नेटवर्क हस्तांतरण की आवश्यकता के बिना svn diff और svn status काम, उचित गति के साथ)।

यह डिज़ाइन ('ढीला' और 'पैक किया गया' प्रारूप) बहुत कुशल पैकिंग का लाभ है, लेकिन यह नुकसान था कि आपको "git gc" (डिस्क स्थान के लिए नहीं, बल्कि प्रदर्शन - डिस्क I के लिए मैन्युअल रूप से दोबारा मरम्मत करना पड़ा था।/ओ); आजकल अधिकांश गिट कमांड रिपॉजिटरी (सुरक्षित रूप से) की आवश्यकता होने पर मरम्मत करते हैं।