ग्राफिक्स के लिए संस्करण नियंत्रण

Question

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

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

Answer 1

हां, संस्करण नियंत्रण में कला संपत्तियां बहुत उपयोगी हैं। आपको इतिहास ट्रैक करने, वापस परिवर्तनों को बदलने की क्षमता मिलती है, और आपके पास बैकअप करने के लिए एक एकल स्रोत होता है। ध्यान रखें कि कला संपत्तियां बहुत बड़ी हैं इसलिए आपके सर्वर को बहुत सारी डिस्क स्पेस & नेटवर्क बैंडविड्थ की आवश्यकता है।

मुझे बहुत बड़ी परियोजनाओं (+100 जीबी) पर perforce का उपयोग करने में सफलता मिली है, हालांकि हमें कुछ और कलाकार अनुकूल के साथ संस्करण नियंत्रण सर्वर तक पहुंच लपेटनी पड़ी।

मैंने Alienbrain के बारे में कुछ अच्छी बातें सुनी हैं, ऐसा लगता है कि ऐसा लगता है कि यह बहुत ही धीमी यूआई है।

Answer 2

हम उपversण का उपयोग करते हैं। बस comps के लिए/trunk/docs के अंतर्गत एक फ़ोल्डर रखें और डिज़ाइनर जांचें और उस फ़ोल्डर को प्रतिबद्ध करें। एक चैंप की तरह काम करता है।

Answer 3

मैं निश्चित रूप से ग्राफिक्स को संस्करण नियंत्रण के तहत रखूंगा। Diffmerge जैसे diff उपकरण के भीतर diff बहुत उपयोगी नहीं हो सकता है, लेकिन आप अभी भी ग्राफिक के दो संस्करणों को चेकआउट कर सकते हैं और अंतर देखने के लिए उन्हें एक तरफ देख सकते हैं।

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

Answer 4

@lomaxx TortoiseSVN में टोर्टोइजिसिफ़ नामक एक प्रोग्राम शामिल है जो छवियों के लिए एक अंतर दिखता है। मैंने इसका इस्तेमाल नहीं किया है लेकिन दिलचस्प लग रहा है।

Answer 5

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

डिजाइनरों के साथ काम करने के मामले में, जो एक अलग संभावना है, मुझे निकट भविष्य में सामना करना पड़ता है, मैं नियमित रूप से उनके स्रोत फ़ाइलों के अपने विभिन्न संस्करणों को "चेक-इन" करने का प्रयास करना चाहता हूं आधार। मुझे पढ़ने के लिए उत्सुकता होगी कि कुछ अनुभव वाले अन्य लोग इसके जवाब में क्या कहेंगे।

Answer 6

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

Answer 7

हम भी, बस बाइनरी को स्रोत नियंत्रण में डालते हैं। हम गिट का उपयोग करते हैं, लेकिन यह सबवर्सन के साथ ही लागू होगा।

एक सुझाव है कि जहां संभव हो, एसवीजी का उपयोग करना है, क्योंकि आप वास्तविक मतभेद देख सकते हैं। द्विआधारी (अधिकतर अन्य छवि प्रारूप) के साथ, आप जो भी प्राप्त कर सकते हैं वह एक संस्करण इतिहास है।

Answer 8

बहुत सारे ग्राफिक्स प्रकार लोग उपversण से कुछ अधिक परिष्कृत करना चाहते हैं।हालांकि यह संस्करण नियंत्रण के लिए अच्छा है, वे एक सामग्री प्रबंधन प्रणाली चाहते हैं जो संपत्ति, टैगिंग, थंबनेल और उस तरह की चीज़ (साथ ही संस्करण) के क्रॉस-रेफरेंसिंग की अनुमति दे।

Answer 9

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

Answer 10

हम पेर्सफोर्स का उपयोग करके बाइनरी फ़ाइलों और छवियों को संशोधन नियंत्रण में रखते हैं। यह बहुत अच्छा है!

हम बहुत सारी कला संपत्तियां रखते हैं, और यह बहुत बड़ी फ़ाइलों के लिए अच्छी तरह से स्केल करता है। यह बाइनरी फाइलों को पहचानता है, जिन्हें अलग नहीं किया जा सकता है, और उन्हें बैक एंड में पूर्ण फ़ाइल प्रतियों के रूप में स्टोर करता है।

इसमें पी 4 वी (क्रॉस-प्लेटफार्म दृश्य ब्राउज़र) है, और एक थंबनेल सिस्टम है ताकि ब्राउज़र में छवि फ़ाइलों को देखा जा सके।

Answer 11

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

Answer 12

आप बोअर पर एक नज़र डालना चाहते हैं: "फोटो, वीडियो और अन्य बाइनरी फ़ाइलों के लिए सरल संस्करण नियंत्रण और बैकअप"। यह किसी भी आकार की बाइनरी फाइलों को संभाल सकता है। http://code.google.com/p/boar/

Answer 13

गिटहब ने हाल ही में "छवि दृश्य मोड" पेश किया, एक नज़र डालें: https://github.com/blog/817-behold-image-view-modes।

Answer 14

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

Answer 15

मेरी राय में Pixelapse बैकअप समाधान के साथ संयुक्त ग्राफिक्स के लिए सबसे अच्छा संस्करण नियंत्रण सॉफ्टवेयर है जो मुझे अब तक मिला है। यह एडोब फाइलों और सामान्य रास्टर छवियों का एक समूह का समर्थन करता है। इसमें संस्करण पूर्वावलोकन द्वारा संस्करण है। यह फ़ाइलों को अद्यतन करते समय स्वतः सहेजता है (सहेजने पर)। यह ड्रॉपबॉक्स की तरह काम करता है लेकिन एक महान वेब इंटरफ़ेस है।

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

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