क्या किसी को पता है कि फ़ाइलों की संख्या और फ़ाइलों के आकार के लिए Git सीमा क्या है?
जवाबों:
खुद लिनुस का यह संदेश आपको कुछ अन्य सीमाओं के साथ मदद कर सकता है
[...] सीवीएस, यानी यह वास्तव में "एक समय में एक फ़ाइल" मॉडल के लिए बहुत अधिक उन्मुख हो रहा है।
जो इसमें अच्छा है कि आपके पास एक लाख फाइलें हो सकती हैं, और फिर उनमें से कुछ की ही जांच करें - आप कभी भी अन्य 999,995 फाइलों के प्रभाव को भी नहीं देख पाएंगे।
मूल रूप से Git वास्तव में कभी भी पूरे रेपो से कम नहीं दिखता है। यहां तक कि अगर आप चीजों को थोड़ा सीमित करते हैं (यानी सिर्फ एक हिस्से की जांच करें, या इतिहास को थोड़ा सा पीछे ले जाएं), तो गित समाप्त हो जाती है फिर भी हमेशा पूरी चीज की देखभाल करते हैं, और ज्ञान को चारों ओर ले जाते हैं।
यदि आप इसे हर चीज को एक विशाल भंडार के रूप में देखने के लिए बाध्य करते हैं तो वास्तव में बुरी तरह से तराजू । मुझे नहीं लगता कि यह हिस्सा वास्तव में ठीक करने योग्य है, हालांकि हम शायद इस पर सुधार कर सकते हैं।
और हाँ, फिर "बड़ी फ़ाइल" समस्याएँ हैं। मैं वास्तव में नहीं जानता कि बड़ी फ़ाइलों के बारे में क्या करना है। हम उन्हें चूसते हैं, मुझे पता है।
मेरे अन्य उत्तर में और देखें : गिट के साथ सीमा यह है कि प्रत्येक रिपॉजिटरी को " फाइलों के सुसंगत सेट ", "सभी सिस्टम" को अपने आप में प्रतिनिधित्व करना चाहिए (आप "रिपॉजिटरी का हिस्सा" टैग नहीं कर सकते हैं)।
यदि आपका सिस्टम स्वायत्त (लेकिन अंतर-निर्भर) भागों से बना है, तो आपको सबमॉड्यूल का उपयोग करना होगा ।
जैसा कि तल्ज़ो के उत्तर से स्पष्ट है , सीमा एक सिस्टम एक (बड़ी संख्या में फ़ाइलें) हो सकती है, लेकिन यदि आप गिट की प्रकृति को समझते हैं (इसके SHA-1 कुंजी द्वारा प्रस्तुत डेटा सुसंगतता के बारे में), तो आपको सही सीमा का एहसास होगा " एक उपयोग है: यानी, आपको एक Git रिपॉजिटरी में सब कुछ स्टोर करने की कोशिश नहीं करनी चाहिए , जब तक कि आप हमेशा सब कुछ वापस पाने के लिए तैयार न हों। कुछ बड़ी परियोजनाओं के लिए, इसका कोई मतलब नहीं होगा।
Git सीमा पर एक अधिक गहराई से देखने के लिए, "देख Git बड़ी फ़ाइलों के साथ "
(जो उल्लेख है Git-LFS ।: एक समाधान Git रेपो बाहर बड़ी फ़ाइलों को स्टोर करने के लिए GitHub अप्रैल 2015)
Git repo को सीमित करने वाले तीन मुद्दे:
एक और हालिया धागा (फरवरी 2015) एक गिट रेपो के लिए सीमित कारकों को दर्शाता है :
केंद्रीय सर्वर से कुछ एक साथ क्लोन भी अन्य उपयोगकर्ताओं के लिए अन्य समवर्ती संचालन धीमा कर देगा?
क्लोनिंग करते समय सर्वर में कोई लॉक नहीं होता है, इसलिए सिद्धांत रूप में क्लोनिंग अन्य कार्यों को प्रभावित नहीं करता है। क्लोनिंग बहुत सारी मेमोरी का उपयोग कर सकता है (और बहुत सी सीपीयू जब तक आप रीचैबिलिटी बिटमैप फीचर को चालू नहीं करते हैं, जो आपको करना चाहिए)।
क्या '
git pull' धीमी होगी?यदि हम सर्वर साइड को बाहर करते हैं, तो आपके पेड़ का आकार मुख्य कारक है , लेकिन आपकी 25k फाइलें ठीक होनी चाहिए (लिनक्स में 48k फाइलें हैं)।
'
git push'?आपके रेपो का इतिहास कितना गहरा है, या आपका पेड़ कितना चौड़ा है, यह इससे प्रभावित नहीं है, इसलिए जल्दी करना चाहिए ।।
आह refs की संख्या दोनों को प्रभावित कर सकता
git-pushहै औरgit-pull।
मुझे लगता है कि स्टीफन इस क्षेत्र में मुझसे बेहतर जानता है।'
git commit'? (इसे संदर्भ 3 में धीमी गति से सूचीबद्ध किया गया है ।) 'git status'? (संदर्भ 3 में फिर से धीमा हालांकि मैं इसे नहीं देखता।)
(भीgit-add)फिर से, अपने पेड़ का आकार। आपके रेपो के आकार पर, मुझे नहीं लगता कि आपको इसके बारे में चिंता करने की आवश्यकता है।
हो सकता है कि कुछ संचालन दिन-प्रतिदिन के लिए न हों, लेकिन अगर उन्हें अक्सर वेब फ्रंट-एंड द्वारा गिटलैब / स्टैश / गीथहब आदि कहा जाता है, तो वे अड़चन बन सकते हैं। (उदाहरण के लिए '
git branch --contains' बड़ी संख्या में शाखाओं से बहुत अधिक प्रभावित होता है।)
git-blameधीमी हो सकती है जब किसी फ़ाइल को बहुत संशोधित किया जाता है।
कोई वास्तविक सीमा नहीं है - सब कुछ 160-बिट नाम के साथ नाम दिया गया है। फ़ाइल का आकार 64 बिट संख्या में प्रतिनिधित्व करने योग्य होना चाहिए ताकि वहां कोई वास्तविक सीमा न हो।
हालांकि एक व्यावहारिक सीमा है। मेरे पास एक रिपॉजिटरी है जो ~ 8,000> 880,000 फाइलों के साथ है और git gc में कुछ समय लगता है। काम करने वाला पेड़ बहुत बड़ा होता है इसलिए पूरे कामकाजी निर्देशिका का निरीक्षण करने में काफी समय लगता है। इस रेपो का उपयोग केवल डेटा स्टोरेज के लिए किया जाता है, हालांकि, यह केवल स्वचालित टूल का एक गुच्छा है जो इसे संभालता है। रेपो से परिवर्तनों को खींचना, समान डेटा को rsyncing की तुलना में बहुत तेज है।
%find . -type f | wc -l
791887
%time git add .
git add . 6.48s user 13.53s system 55% cpu 36.121 total
%time git status
# On branch master
nothing to commit (working directory clean)
git status 0.00s user 0.01s system 0% cpu 47.169 total
%du -sh .
29G .
%cd .git
%du -sh .
7.9G .
.gitडायरेक्टरी से बड़ी है ? मेरी भोली धारणा यह थी कि .gitइसमें वर्किंग डायरेक्टरी और इतिहास की एक प्रति शामिल है, इसलिए इसे बड़ा होना चाहिए। क्या कोई मुझे संसाधन समझ के बारे में बता सकता है कि ये आकार कैसे संबंधित हैं?
.gitनिर्देशिका में सामग्री संपीड़ित है। तो अपेक्षाकृत कुछ कमिट के साथ एक रिपॉजिटरी के असम्पीडित वर्किंग डायरेक्टरी की तुलना में एक छोटा संकुचित इतिहास होने की संभावना है। मेरा अनुभव बताता है कि व्यवहार में, C ++ कोड के साथ, पूरा इतिहास आम तौर पर कार्यशील निर्देशिका के समान आकार के बारे में है।
यदि आप ऐसी फाइलें जोड़ते हैं जो बहुत बड़ी हैं (मेरे मामले में जीबी, साइगविन, एक्सपी, 3 जीबी रैम), तो यह अपेक्षा करें।
घातक: स्मृति से बाहर, मॉलॉक विफल रहा
अधिक जानकारी यहाँ
अद्यतन 3/2/11: कछुआ गिट के साथ विंडोज 7 x64 में देखा गया। टोंस ऑफ़ मेमोरी का उपयोग, बहुत धीमी प्रणाली प्रतिक्रिया।
फरवरी 2012 में, जोशुआ रेडस्टोन की एक बड़ी सॉफ्टवेयर रिपॉजिटरी में Git मेलिंग सूची में , जोशुआ रेडस्टोन से एक बहुत ही दिलचस्प सूत्र था, Git का परीक्षण कर रहा था:
टेस्ट रेपो में 4 मिलियन कमिट्स, लीनियर हिस्ट्री और लगभग 1.3 मिलियन फाइल्स हैं।
चलाए गए परीक्षण बताते हैं कि इस तरह के रेपो गिट के लिए अनुपयोगी (ठंडा ऑपरेशन स्थायी मिनट) है, लेकिन यह भविष्य में बदल सकता है। मूल रूप से प्रदर्शन stat()कर्नेल एफएस मॉड्यूल को कॉल की संख्या से दंडित किया जाता है , इसलिए यह रेपो में फ़ाइलों की संख्या और एफएस कैशिंग दक्षता पर निर्भर करेगा। इस Gist को आगे की चर्चा के लिए भी देखें ।
2018-04-20 के अनुसार विंडोज के लिए Git में एक बग है जो प्रभावी रूप से उस विशेष कार्यान्वयन का उपयोग करके फ़ाइल के आकार को 4GB अधिकतम तक सीमित करता है (यह बग lfs को भी प्रचारित करता है )।
यह इस बात पर निर्भर करता है कि आपका अर्थ क्या है। व्यावहारिक आकार सीमाएं हैं (यदि आपके पास बहुत बड़ी फाइलें हैं, तो यह बोरिंग धीमा हो सकता है)। यदि आपके पास बहुत सारी फाइलें हैं, तो स्कैन भी धीमा हो सकता है।
मॉडल के लिए वास्तव में अंतर्निहित सीमाएं नहीं हैं, हालांकि। आप निश्चित रूप से इसका खराब उपयोग कर सकते हैं और दुखी हो सकते हैं।
मुझे लगता है कि रिपॉजिटरी का हिस्सा होने के नाते बड़ी फाइल से बचने की कोशिश करना अच्छा है (जैसे डेटाबेस डंप कहीं और बेहतर हो सकता है), लेकिन अगर कोई अपनी रिपॉजिटरी में कर्नेल के आकार पर विचार करता है, तो आप शायद आराम से काम करने की उम्मीद कर सकते हैं आकार में कुछ भी छोटा और उससे कम जटिल।
मेरे पास डेटा की एक उदार राशि है जो मेरे रेपो में व्यक्तिगत JSON टुकड़े के रूप में संग्रहीत है। कुछ निर्देशिकाओं के तहत लगभग 75,000 फाइलें बैठी हैं और यह वास्तव में प्रदर्शन के लिए हानिकारक नहीं है।
पहली बार में उन्हें जाँचना, जाहिर है, थोड़ा धीमा था।
मैंने पाया कि रेपो में बड़ी संख्या में फाइलों (350k +) को संग्रहीत करने की कोशिश की जा रही है। हां, स्टोर करें। हंसते हुए कहते हैं।
$ time git add .
git add . 333.67s user 244.26s system 14% cpu 1:06:48.63 total
Bitbucket प्रलेखन से निम्नलिखित अर्क काफी दिलचस्प हैं।
जब आप डीवीसीएस रिपॉजिटरी क्लोनिंग के साथ काम करते हैं, तो आप पूरे रिपॉजिटरी और उसके इतिहास के साथ काम कर रहे होते हैं। व्यवहार में, एक बार जब आपका भंडार 500MB से बड़ा हो जाता है, तो आप मुद्दों को देखना शुरू कर सकते हैं।
... Bitbucket के 94% ग्राहकों के पास रिपॉजिटरी हैं जो 500MB से कम के हैं। लिनक्स कर्नेल और Android दोनों 900MB से कम के हैं।
उस पृष्ठ पर अनुशंसित समाधान आपकी परियोजना को छोटे टुकड़ों में विभाजित करना है।
रेपो के लिए git में 4 जी (32 बिट) की सीमा है।