2012-11-30 38 views
6

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

एकीकृत भंडार का एक लाभ यह है कि हमें कई संशोधनों का ट्रैक रखने की आवश्यकता नहीं है: यदि हमें कभी भी पिछले रन से आउटपुट फिर से बनाने की आवश्यकता है, तो हमें केवल सिस्टम को एक संशोधन संख्या में अपडेट करने की आवश्यकता है आउटपुट लॉग।

एक नुकसान यह है कि यदि हम कई सिर सक्रिय होने पर डेटा संशोधित करते हैं, तो हम डेटा परिवर्तनों को तब तक खो सकते हैं जब तक हम मैन्युअल रूप से उन परिवर्तनों को प्रत्येक सिर में कॉपी नहीं करते।

क्या कोड और डेटा को अलग-अलग भंडारों में विभाजित करने के लिए कोई अन्य पेशेवर/विपक्ष है?

उत्तर

1

एकाधिक रेपोस:

  • पेशेवरों:

    • component-based approach
    • विन्यास विनिर्देश (आप फ़ाइलों के समूह है कि स्वतंत्र रूप से एक-दूसरे विकसित कर सकते हैं की पहचान): आप उन संदर्भों को सूचीबद्ध करें (यहां "संशोधन") जिन्हें आप की आवश्यकता है काम करने के लिए आर प्रणाली। यदि आप दूसरे को बदले बिना एक भाग को संशोधित करना चाहते हैं, तो आप उस सूची को अपडेट करते हैं।
    • आंशिक क्लोन: यदि आप सभी घटकों की जरूरत नहीं है, आप केवल लोगों को आप चाहते हैं क्लोन कर सकते हैं (आपके मामले में लागू नहीं होता)
  • विपक्ष

    • विन्यास प्रबंधन : आपको उस कॉन्फ़िगरेशन को ट्रैक करने की आवश्यकता है (आमतौर पर पेरेंट रेपो के माध्यम से, subrepos पंजीकरण)
    • आपके मामले में, डेटा परियोजनाओं के कुछ संस्करणों पर काफी निर्भर है (आपके पास नया डेटा हो सकता है जो पुरानी बनाम के लिए समझ में नहीं आता परियोजना के आयनों)

एक रेपो

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

गैर बाइनरी डेटा के लिए, मैं अभी भी एक ही रेपो में बनाए रखते हुए।

+0

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

+0

@max: हाँ, जब तक कि मैं उन्हें रोक नहीं देता (http://mercurial.selenic.com/wiki/TipsAndTricks#Prevent_a_push_that_would_create_multiple_heads), मर्ज करने का प्रयास करने के बाद (http://kiln.stackexchange.com/questions/1696/how-to -fix-बहु-सिर) – VonC

0

हां, आपको कोड और डेटा अलग करना चाहिए। आपको डेटा नियंत्रण में डेटा और डेटाबेस में अपना डेटा रखें।

मुझे संस्करण नियंत्रण पसंद है क्योंकि मैं दस साल से अधिक प्रोग्रामर हूं और मुझे यह नौकरी पसंद है।

लेकिन पिछले महीनों के दौरान मुझे एहसास हुआ: डेटा संस्करण नियंत्रण में नहीं होना चाहिए। कभी-कभी किसी ऐसे व्यक्ति के लिए मुश्किल होती है जो गिट (या एक अन्य संस्करण नियंत्रण प्रणाली) से परिचित है "इसे जाने दें"।

आपको एक अच्छा ओआरएम चाहिए जो डेटाबेस स्कीमा माइग्रेशन का समर्थन करता है। प्रवासन (schemamigrations और डेटामैग्रेशन) संस्करण नियंत्रण में रखा जाता है, लेकिन डेटा नहीं है।

मुझे पता है कि आपका प्रश्न एक या दो भंडारों का उपयोग करने के बारे में था, लेकिन शायद मेरा जवाब आपको एक अलग दृश्य बिंदु प्राप्त करने में मदद करता है।

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

  • कोई संबंधित समस्या नहीं^_^