version control - मैं DVCS में उचित रूप से बड़ी कला संपत्ति का प्रबंधन कैसे करूं?




version-control asset-management (2)

क्या डीवीसी टूल जैसे कि hg और git साथ बड़ी संपत्ति (यानी 1000 की इमेज, फ्लैश मूवी आदि) को संभालने का कोई अच्छा तरीका है। जैसा कि मैं इसे देखता हूं, 4 जीबी परिसंपत्तियों से भरी रिपॉजिटरी को क्लोन करने के लिए एक अनावश्यक ओवरहेड की तरह लगता है जैसे आप फाइलों की जांच करेंगे। यदि आप स्रोत कोड को परिसंपत्ति फ़ाइलों के साथ मिश्रित करते हैं तो यह बोझिल लगता है।

किसी को भी वेब विकास के संदर्भ में यह करने में कोई विचार या अनुभव है?


मैंने खुद इसके साथ संघर्ष किया है। जैसा कि आपने कहा, संपत्ति का जीबी संस्करण एक बहुत बड़ा दर्द हो सकता है।

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

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


ये कुछ विचार हैं जो मैंने इस विषय पर लिए हैं। अंत में आपको परिसंपत्तियों और कोड को यथासंभव अलग रखने की आवश्यकता हो सकती है। मैं कई संभावित रणनीतियों के बारे में सोच सकता हूं:

वितरित, दो रिपोजिटरी

एक रेपो में कोड और दूसरे में कोड।

लाभ

  • यदि आप सीधे ग्राफिक फ़ाइलों के साथ काम नहीं कर रहे हैं, तो वेब विकास के संदर्भ में आपको विशाल संपत्ति भंडार को क्लोन करने की आवश्यकता नहीं होगी। यह संभव है यदि आपके पास एक वेब सर्वर है जो डायनेमिक कंटेंट (PHP, ASP.NET, RoR, आदि) से अलग एसेट्स को हैंडल करता है और एसेट रेपो के साथ सिंक हो रहा है।

नुकसान

  • डीवीसीएस उपकरण अन्य रिपॉजिटरी का ट्रैक अपने आप से नहीं रखते हैं इसलिए कोई प्रत्यक्ष बीओएम (सामग्री का बिल) समर्थन नहीं है, अर्थात दोनों रिपॉजिटरी सिंक में होने पर यह बताने का कोई स्पष्ट तरीका नहीं है। (मुझे लगता है कि यह git-submodule या repo किस लिए है)।

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

  • एसेट रिपोजिटरी ओवरहेड भले ही यह केवल उन लोगों को प्रभावित करता है जो इसका उपयोग करते हैं।

वितरित, वन रिपोजिटरी

एसेट्स और कोड एक ही रिपॉजिटरी में रहते हैं लेकिन वे दो अलग-अलग निर्देशिकाओं में हैं।

लाभ

  • कोड और संपत्ति का संस्करण परस्पर जुड़े हुए हैं इसलिए BOM व्यावहारिक है। बैकट्रैकिंग बिना किसी परेशानी के संभव है।

नुकसान

  • चूंकि वितरित संस्करण नियंत्रण उपकरण पूरे प्रोजेक्ट संरचना का ट्रैक रखते हैं, आमतौर पर सिर्फ एक निर्देशिका की जांच करने का कोई तरीका नहीं है।
  • आपको अभी भी रिपॉजिटरी ओवरहेड के साथ समस्या है। इससे भी अधिक, आपको कोड के साथ-साथ परिसंपत्तियों की भी जांच करनी होगी।

ऊपर सूचीबद्ध दोनों रणनीतियों के पास अभी भी एक बड़ा ओवरहेड होने का नुकसान है क्योंकि आपको बड़ी संपत्ति भंडार को क्लोन करने की आवश्यकता है। इस समस्या का एक समाधान उपरोक्त पहली रणनीति का एक प्रकार है, दो रिपोजिटरी; वितरित VCS रेपो और एक केंद्रीकृत VCS रेपो (जैसे SVN, Alienbrain, आदि) में संपत्ति में कोड रखें।

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

ऑफ-रिपोजिटरी एसेट्स (या इसके बजाय सीएमएस में संपत्ति)

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

लाभ

  • कोड रिपॉजिटरी को ब्लोट नहीं करता है (उदाहरण के लिए सहायक जैसे यह अक्सर फ़ाइल चेकिंग करता है)
  • संपत्ति के लचीले संचालन को सक्षम करता है जैसे कि परिसंपत्तियों की तैनाती केवल संपत्ति के लिए समर्पित सर्वरों के लिए
  • अगर एपीआई के साथ सीएमएस पर, संपत्ति को कोड में संभालना अपेक्षाकृत आसान होना चाहिए

नुकसान

  • कोई बीओएम समर्थन नहीं
  • कोई आसान व्यापक संस्करण बैक-ट्रैकिंग समर्थन नहीं है, यह आपकी संपत्ति के लिए बैकअप रणनीति पर निर्भर करता है




asset-management