गिट एलएफएस छोटी फाइलों को कितनी अच्छी तरह से संभालता है?

क्या गिट एलएफएस में संग्रहीत प्रकार की फाइलों के लिए सबसे अच्छा अभ्यास है? विशेष रूप से न्यूनतम आकार के लिए?गिट एलएफएस छोटी फाइलों को कितनी अच्छी तरह से संभालता है?

उदाहरण के लिए, एक 10 एमबी संगीत फ़ाइल एक स्पष्ट फिट होगी, लेकिन 25 केबी पीएनजी के बारे में क्या होगा? क्या यह एलएफएस में डालने लायक है या गिट को इसे संभालने के लिए बेहतर है?

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

स्रोत

2016-03-04 James McMahon

+1 मैं भी इसका उत्तर जानना चाहता हूं, उदाहरण के लिए यूई 4 में कई बाइनरी यूसेट फाइलें हैं। बहुत छोटे हैं (10-100 केबी) और कुछ बड़े हैं (50 एमबी +)। अगर मैं गिट-एलएफएस काफी अच्छी तरह से काम करता है तो मैं सिर्फ "* .uasset" को ट्रैक करना चाहता हूं। – Chad

मुझे एक सटीक थ्रेसहोल्ड मान देने की उम्मीद नहीं होगी।

एलएफएस रिमोट रिपोजिटरी के साथ सिंक्रनाइज़ करने के लिए डेटा की मात्रा पर बचत करता है। हालांकि, बचत तब तक लागू होती है जब तक कि बड़ी फ़ाइल स्वयं नहीं बदलती है। दरअसल एक बदली गई फ़ाइल के लिए आपको एक एलएफएस ऑब्जेक्ट में बदलाव को संसाधित करने के लिए दूसरी रैंट्रिप की आवश्यकता होगी।

तो, यदि आप अपने उपयोग मामले में बदल रहे हैं (अक्सर) में आप एलएफएस के साथ छोटी फाइलें शामिल कर सकते हैं। विशिष्ट ब्रेक सर्वर की I/O गति पर निर्भर करता है और अधिकांशतः विलंबता और क्लाइंट के बीच विलंबता और थ्रूपुट पर निर्भर करता है।

आपके उदाहरण में, पीएनजी कभी भी बदलने के करीब होने पर मुझे अभी भी सुधार की उम्मीद है। जैसे ही वे प्रत्येक प्रतिबद्धता पर लगभग (लगभग) बदलने जा रहे हैं, यहां तक कि बड़ी फ़ाइलों को एलएफएस में डालने से लाभ नहीं होता है।

इसके अलावा दूसरी राउंड ट्रिप की अतिरिक्त लागत कम से कम महत्वपूर्ण होगी, सामान्य फाइलें बड़ी होंगी। खासकर जब एक फ़ाइल वर्ग (प्रत्यय) का आकार एक विस्तृत श्रृंखला में भिन्न होगा और/या फ़ाइल वर्ग के भीतर परिवर्तन आवृत्ति एक विस्तृत स्पेक्ट्रम को कवर कर रही है, तो हो सकता है कि आपके प्रश्न का स्पष्ट उत्तर न हो।

स्रोत

2016-04-03 18:44:08 rpy

मैं इस धारणा के तहत था कि एलएफएस का लाभ यह था कि अक्सर बाइनरी फाइलों को बदलने से रेपो आकार में वृद्धि नहीं होती है। लेकिन ऐसा लगता है कि आप कह रहे हैं कि जब फाइलें अक्सर बदलती हैं तो यह वास्तव में मदद नहीं करता है; तो इसका इस्तेमाल क्यों करें? – Chad

अधिक सटीक होना चाहिए था। ऑब्जेक्ट ब्लॉब (पैक फ़ाइल) की भावना में रेपो आकार छोटा है। मैं डेटा की मात्रा का जिक्र कर रहा था जिसे betwen क्लाइंट और सर्वर स्थानांतरित करने के लिए कहा जाता है (इसलिए पुश और पुल पर कहने के लिए) ऑपरेशन। चूंकि आमतौर पर स्थानीय परिचालन प्रमुख महत्व नहीं होते हैं और परिवर्तनों को तुलना करने की आवश्यकता होगी, फिर भी, मैंने बड़ी फ़ाइलों के साथ प्रमुख लागत पहलुओं पर ध्यान केंद्रित किया। एलएफएस ऑब्जेक्ट डेटा को संसाधित करने के लिए आवश्यक किसी भी ऑपरेशन पर सहेज लेगा। – rpy

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

गिट एलएफएस छोटी फाइलों को कितनी अच्छी तरह से संभालता है?

उत्तर

संबंधित मुद्दे