2015-04-29 6 views
16

हमारे पास एक गिट भंडार है जिसमें एसवीएम एआई इनपुट डेटा और परिणाम शामिल हैं। हर बार जब हम एक नया मॉडल चलाते हैं, हम इतना है कि हम समय के साथ हमारे परिणामों को व्यवस्थित कर सकते है कि मॉडल के लिए एक नया रूट फ़ोल्डर बनाने के लिए:गिट स्टोर डुप्लिकेट फ़ाइलों को कैसे स्टोर करता है?

/run1.0 
    /data 
    ... 100 mb of data 
    /classification.csv 
    /results.csv 
    ... 
/run2.0 
    /data 
    ... 200 mb of data (including run1.0/data) 
    /classification.csv 
    /results.csv 
    ... 

हम नए मॉडल का निर्माण के रूप में हम डेटा प्राप्त कर सकते हैं (बड़े .wav फ़ाइलें) पिछले रन से। इसका अर्थ यह है कि हमारे डेटा फ़ोल्डर 2.0 में 1.0/डेटा और अतिरिक्त डेटा जो हम एकत्र कर सकते हैं, से सभी फाइलें हो सकती हैं।

यदि हम इसे जारी रखते हैं तो रेपो आसानी से गीगाबाइट से अधिक होने जा रहा है।

क्या गिट के पास डुप्लिकेट बाइनरी फाइलों को पहचानने और उन्हें केवल एक बार स्टोर करने का तरीका है (उदा। सिमलिंक की तरह)? यदि नहीं, तो हम पुन: कार्य करेंगे कि डेटा कैसे संग्रहीत किया जाता है।

उत्तर

14

मैं शायद नहीं यह काफी सही समझाने जा रहा हूँ, लेकिन मेरी समझ है कि हर भंडार केवल एक वृक्ष संरचना वास्तविक फ़ाइलें जो एक वस्तुओं उप में जमा हो जाती संकेत के साथ अपनी परियोजना की फ़ाइल संरचना का प्रतिनिधित्व करने के लिए प्रतिबद्ध है फ़ोल्डर।

ob064b56112cc80495ba59e2ef63ffc9e9ef0c77 

यह रूप में संग्रहीत किया जाएगा: Git, फ़ाइल नाम और उप फ़ोल्डर बनाने के लिए तो उदाहरण के लिए एक फ़ाइल की सामग्री निम्नलिखित हैश बनाया है फ़ाइल सामग्री की एक SHA1 हैश का उपयोग करता

.git/ऑब्जेक्ट्स/ओबी/064b56112cc80495ba59e2ef63ffc9e9ef0c77

पहले दो अक्षर निर्देशिका नाम के रूप में उपयोग किए जाते हैं और शेष फ़ाइल नाम के रूप में उपयोग किए जाते हैं।

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

+0

दिलचस्प ... इससे बहुत समझ आएगी और मैं सोच रहा था कि यह क्या हो रहा है। मुझे यह देखने के लिए कुछ खोदना होगा कि यह वास्तव में मामला है (जब मुझे कुछ खाली समय मिलता है)। भी प्रयोग करने के लिए :) एक ही वस्तु आलसी आप में से उन लोगों के लिए – JoshJ

+2

pastebin.com/p0KpqBPX, केवल थोड़ा और अधिक स्थान .git में 1 फ़ाइल से आवश्यक/वस्तुओं – opatut

+0

यह आलस्य नहीं, समय की बस कमी :) अच्छा काम था! – JoshJ

7

डिफ़ॉल्ट/खुद द्वारा: सं हां।

गिट इस आधार पर काम करता है कि यह फाइलों के स्नैपशॉट बनाता है, और अन्य वीसीएस की तरह वृद्धिशील मतभेद नहीं बनाता है।

संपादित

डेव और opatut से उल्लेख किया है, कैसे Git भंडार फ़ाइलों की मेरी समझ गलत था और मैं माफी माँगता हूँ के लिए भ्रम का कारण। अधिक शोध करने पर, गिट डुप्लीकेट फाइलों को पॉइंटर्स के रूप में 1 फ़ाइल में स्टोर करता है। this question के स्वीकार किए जाते हैं जवाब में VonC का हवाला देते हुए,

... एक ही सामग्री के साथ कई फ़ाइलों को केवल एक बार जमा हो जाती है।

कृपया ध्यान दें कि के रूप में है कि इसका जवाब में उल्लेख किया है, धारणात्मक ...

संदर्भित git-scm documentation:

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

हालांकि, एक भंडारण स्तर पर, डेल्टा अभी भी उपयोग किया जाता है, जिसमें Git यथासंभव शीघ्र धब्बे की अनुमानी चयन के आधार पर छोटी संभव डेल्टा उत्पन्न करने के लिए कोशिश करता है, वहाँ विकल्प है कि संपीड़न के लिए अनुकूलित कर रहे हैं। जो भंडार के आकार को कम करेगा।

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

अन्य विकल्प: सिमलिंक

आप सिमलिंक पिछले फ़ाइलों को, कि जिस तरह से जब आप उन पर काम करते हैं, वे एक ही बड़ी फ़ाइल को इंगित करेगा लेकिन ध्यान दें कि Git ट्रैक नहीं करता सेट कर सकते हैं फाइलें जो सिम्लिंक पर इंगित करती हैं, जिसका अर्थ है कि वे केवल सिम्लिंक स्टोर करेंगे। यह पोर्टेबिलिटी के बलिदान पर अंतरिक्ष को कम करने की आपकी ज़रूरत को पूरा करता है, यानी, यदि आप किसी अन्य देव मशीन पर जाते हैं, तो आपको यह सुनिश्चित करना होगा कि फाइलें सिमलिंक इंगित करती हैं। जो आप चाहते हैं वह हो सकता है। this very good SO Q&A देखें कि सिमलिंक के लिए क्या गिट करता है।

एक और वैकल्पिक: उपकरण!

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

आप git-annex को आजमा सकते हैं, जहां यह मूल रूप से केवल बाइनरी फ़ाइलों के नवीनतम संस्करण को ट्रैक करता है और बाकी को सिम्लिंक द्वारा बनाए रखा जाता है, इसलिए एक तरह से यह प्रतीकात्मक लिंक को संभालने का एक और स्वचालित तरीका है। Here's their project site.

या git-submodules में निर्मित और आप जो चाहते हैं उसे प्राप्त करने के लिए एक अलग रेपो, जहां आप केवल उन्हें उपयोग करने के लिए बड़ी बाइनरी फाइलें लाते हैं।

मान्य है कि मैंने इन विकल्पों का कोई प्रयास नहीं किया है, इसलिए उनके बारे में अधिक स्पष्टीकरण पढ़ने के लिए संदर्भ लिंक यहां दिया गया है। संदर्भ: this SO question

+1

क्या एक शानदार जवाब। मैं मानसिक रूप से सिम्लिंक के विचार का पता लगाना शुरू कर रहा था लेकिन यह सुनिश्चित नहीं था कि क्या उपलब्ध था। मैं अब उसमें देख लूंगा। धन्यवाद। – JoshJ

+0

@ जोशजे कोई समस्या नहीं, खुशी है कि मैं मदद कर सकता हूं, और मैं आपकी तारीफ से नम्र हूं। इसे लागू करने के लिए शुभकामनाएँ! – matrixanomaly

+1

आपका उत्तर भ्रामक और थोड़ा उलझन में है, आईएमओ। असल में, गिट एक ही एसएचए के साथ दो फाइलों को समान मानता है, उनके पथ कोई फर्क नहीं पड़ता। तो ओपी के सवाल के लिए, यह ठीक है, गिट एक ही फाइल को कई बार स्टोर नहीं करेगा। क्यों डेव सेक्स्टन के जवाब के लिए देखें। – opatut

0

भले ही गिट चीजों को स्टोर करने के लिए आपके रास्ते में सहेजने के बाद भी, आप खराब तरीके से वीसीएस का उपयोग कर रहे हैं और वीसीएस का उपयोग करने के सभी फायदे खो रहे हैं, यह देखने में सक्षम नहीं है कि कौन से बदलाव किए गए हैं 2 संस्करणों के बीच।

आपके पास अपनी फ़ाइलों के साथ 'रन' निर्देशिका बेहतर होगी और प्रत्येक नए संस्करण के लिए प्रतिबद्धता होगी (टैग के साथ भी यदि आप अपने महत्वपूर्ण 'रन' को अधिक आसानी से देखना चाहते हैं)।

इस तरह आप संस्करणों के बीच क्या किया गया था और अपने काम में सुधार कर सकते थे।

सूरजमुखी में सब कुछ रखने की आवश्यकता नहीं है!

आप जो करने का प्रयास करते हैं वह एक बुरी बात है !!

+0

हाँ, दुर्भाग्यवश ये संस्करण संख्या नहीं हैं। ये पूरी तरह से अलग मॉडल रन हैं और इन्हें जानकारी साझा करने की आवश्यकता हो सकती है और उन सभी को एक ही चेकआउट में पुनर्प्राप्त करने के लिए बिना किसी चेकआउट में पुनर्प्राप्त करने की आवश्यकता हो सकती है। – JoshJ

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