मुझे एक परीक्षण भंडार मिला है जिसे मैंने गिट के नीचे रखा है। अधिकांश फाइलें बहुत छोटी हैं लेकिन उनमें से बहुत बड़ी संख्या है और बस गिट ऑपरेशंस जैसे जोड़ और स्थिति को पूरा करने में दस मिनट लग रहे हैं। इन्हें संशोधन नियंत्रण के तहत रखने और उचित प्रदर्शन करने के लिए मेरे विकल्प क्या हैं? क्या मुझे submodules का उपयोग करने का प्रयास करना चाहिए या क्या मुझे DVCSes से साफ़ करना चाहिए?धीमी गिट ऑपरेशंस
add और status जैसे गिट ऑपरेशंस stat फाइल सिस्टम में प्रत्येक फ़ाइल (परिवर्तनों का पता लगाने के लिए) की आवश्यकता होती है। या तो आपके पास वास्तव में बड़ी संख्या में फाइलें हैं (कहें, दसियों या सैकड़ों हजारों फाइलें), या आपके पास एक फाइल सिस्टम है जिसमें stat ऑपरेशन धीमा है।
किसी भी मामले में, यदि आपको सिस्टम पर काम करने की आवश्यकता है, जहां यह बेहद धीमी है, तो आप इंडेक्स में "अपरिवर्तित" बिट का उपयोग कर सकते हैं, जो गिट को फ़ाइल में stat परेशान नहीं करने के लिए कहता है। यदि आप इसे चालू करते हैं, तो आपको व्यक्तिगत फ़ाइलों में परिवर्तन लेने के लिए गिट को मैन्युअल रूप से निर्देशित करने की आवश्यकता होती है, उदा। उन्हें git add पर सीधे पास करके, अन्यथा गिट को कुछ भी नहीं बदला जाएगा। आप इसे git config core.ignoreStat true सेट करके चालू कर सकते हैं और फिर git reset --hard HEAD जैसे कुछ चला सकते हैं।
बिंगो! मैंने उन्हें गिनती नहीं की है क्योंकि मुझे डर है लेकिन मुझे यह जानकर आश्चर्य नहीं होगा कि यह सैकड़ों हजारों या यहां तक कि लाखों फाइलें हैं, लगभग सभी मानव उत्पन्न हुए हैं। मैंने उस ध्वज को स्थापित करने की कोशिश की और इससे कुछ परिचालनों में थोड़ा सा मदद मिली लेकिन अभी भी धीमी है। शायद मुझे इसके बजाय बहुत से छोटे भंडार बनाना चाहिए। – dromodel
मुझे आश्चर्य है कि यहां "बहुत बड़ा" नंबर क्या है। आम तौर पर यह छोटी फाइलों की मात्रा नहीं है जो गिट को परेशानी पाती है लेकिन बड़ी बाइनरी फाइलें पाती हैं। हालांकि, मैं कल्पना कर सकता हूं कि यदि राशि काफी बड़ी है, तो आप उन्हें कई रिपॉजिटरीज़ में विभाजित करना चाहते हैं - या तो सबमिड्यूल या किसी अन्य तरीके से। अगर उन्हें एक एकल रेपो में रहने की ज़रूरत है, तो आपको उदाहरण के लिए सबवर्जन अधिक प्रदर्शन करने वाला मिल सकता है।
संपादित करें: ठीक है, इसलिए आपने टिप्पणी के रूप में जोड़ा है कि आप एक एनएफएस माउंट का उपयोग करते हैं, जो यहां संभावित बाधा की तरह लग रहा है। this thread में उस पर समाधान की जांच करें। विशेष रूप से core.preloadindex यहां रुचि का हो सकता है।
the documentation से:
core.preloadindex
यह Git यदि अंतर और फ़ाइल सिस्टम पर Git स्थिति विशेष रूप से जैसे कार्य में तेजी लाने के कर सकते हैं Git diff जैसे कार्य के लिए समानांतर सूचकांक प्रीलोड सक्षम करें एनएफएस की तरह कमजोर कैशिंग सेमेन्टिक्स है और इस प्रकार अपेक्षाकृत उच्च आईओ विलंबताएं हैं। इस सेट को सही करने के साथ, गिट समानांतर में फाइल सिस्टम डेटा से सूचकांक तुलना करेगा, जिससे ओवरलैपिंग आईओ की अनुमति मिल जाएगी।
EDIT2: टिप्पणियों पर 6 मिलियन फाइलों का उल्लेख किया गया था। मैं समझ सकता हूं कि यह एक बाधा बन रहा है - यह वास्तव में बहुत बड़ी राशि है।
मुझे किसी भी तरह संदेह है कि एसवीएन गिट की तुलना में अधिक प्रदर्शनकारी है - और यहां तक कि यदि यह भी है, तो गिट बहुत बेहतर है (लिनस टोरवाल्ड्स के अनुसार आप गिट का उपयोग नहीं करते समय बदसूरत और बेवकूफ हैं: पी) – ThiefMaster
ठीक है, आपको बस मेरी आवश्यकता नहीं है इसके लिए शब्द - यहां तक कि लिनस [सहमत] (http://stackoverflow.com/questions/984707/what-are-the-git-limits) कि कुछ उपयोग मामलों के लिए यह स्थिति है। गिट रेपो पर पूरी तरह से काम करता है, इसलिए यह कुछ परिदृश्यों में सबसे अच्छा विकल्प नहीं है। – eis
कुछ बाइनरी फाइलें हैं। किसी भी ओपन सोर्स प्रोजेक्ट में आपके द्वारा प्राप्त की जाने वाली संख्या की तुलना में फ़ाइलों की संख्या काफी बड़ी है। – dromodel
आप किस प्रकार की फाइल सिस्टम पर काम कर रहे हैं? – Useless
गिट बड़ी परियोजनाओं को तेजी से संभालने में सक्षम होने के लिए जाना जाता है। क्या आप धीमी फाइल सिस्टम का उपयोग कर रहे हैं? –
माउंट एनएफएस पर है, हालांकि सिर काफी उच्च अंत है। – dromodel