क्या मुझे स्रोत नियंत्रण में उत्पन्न कोड स्टोर करना चाहिए


106

यह एक ऐसी बहस है जिसमें मैं भाग ले रहा हूं। मैं अधिक राय और दृष्टिकोण प्राप्त करना चाहूंगा।

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

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

मुझे कोड के इतिहास का पता लगाने का एक तरीका है, भले ही इसे आमतौर पर ब्लैक बॉक्स के रूप में माना जाता है।

कोई तर्क या प्रतिवाद?


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

मैं उपरोक्त कारणों से इस बिंदु पर एक स्वीकृत उत्तर का चयन नहीं करूंगा।


1
आप इसी तरह के सवाल में दिलचस्पी ले सकते हैं: stackoverflow.com/questions/739391/…
mouviciel

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

1
मेरी सोच में, मुख्य समस्या यह है कि विभिन्न डेवलपर्स को कक्षाएं उत्पन्न करते समय एक ही परिणाम नहीं मिलता है। उन्हें उत्पन्न करने के लिए कॉन्फ़िगरेशन की जाँच की जानी चाहिए, और सभी डेवलपर वातावरणों में लगातार निर्माण करना चाहिए।
नवग्रंथ

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

यह एक महान प्रश्न है, लेकिन यह एसओ के लिए बहुत ही मत-आधारित है, जैसा कि कई परस्पर विरोधी जवाबों से संकेत मिलता है, और इस संबंध में ओपी की अपनी टिप्पणी है।
टिमटि

जवाबों:


48

स्रोत नियंत्रण में इसे सहेजना इसके लायक होने से अधिक परेशानी है।

हर बार जब आप इसके लिए एक कमिटमेंट करते हैं तो आपको इसके लिए कोई मूल्य नहीं होता है।

आमतौर पर हम स्रोत नियंत्रण के बाहर उत्पन्न कोड (idl, jaxb stuff, etc) छोड़ते हैं जहाँ मैं काम करता हूँ और यह कभी कोई समस्या नहीं है


43
मैं आपसे "हर बार आपके द्वारा किए गए एक वादे को पूरा करने" से असहमत हूं। इसके कारण कोई अतिरिक्त कमिट नहीं होना चाहिए क्योंकि केवल एक चीज जो कमिट को प्रभावित करना चाहिए वह कोड में बदलाव है, जिससे उत्पन्न स्रोत में बदलाव होता है। इसलिए जब आप पहले से ही उत्पन्न कोड के स्रोत में परिवर्तन शुरू कर रहे हों, तो आपको केवल उत्पन्न कोड ही करना होगा।
जारेपियर

5
जारेपदार से सहमत हैं। साथ ही आपका कोड-जनरेटर एक बाहरी उपकरण हो सकता है, और यदि आप इसे अपडेट करते हैं, तो उत्पन्न कोड बदल सकता है और इसलिए आपको बदलाव करने की आवश्यकता हो सकती है। लेकिन इस मामले में मैं वास्तव में वैसे भी स्रोत-नियंत्रण में बदलाव देखना चाहता हूं।
वैन

विभिन्न उपकरण विभिन्न स्रोत उत्पन्न कर सकते हैं (कम से कम वे टिप्पणियों या कोड स्वरूपण में भिन्न हो सकते हैं)। उदाहरण के तौर पर आइडिया "आइडिया द्वारा जनरेट" टिप्पणी जोड़ता है जबकि एक्लिप्स नहीं करता है।
पेट्र ग्लैडिख

1
राय विभाजित है, इसे एक जवाब के रूप में चिह्नित करना गलत संदेश देगा।
एस्प्रेसो

34

इसे सोर्स कोड कंट्रोल में रखें। भविष्य के डेवलपर्स के लिए आप जो कुछ भी लिखते हैं उसका इतिहास होने का लाभ सिंक के बाद कभी-कभी पुनर्निर्माण के मामूली दर्द को दूर करता है।


18
थॉट्स एक फायदा नहीं है - क्योंकि जो कोड बनाया गया है वह आपके द्वारा पहले से ही चेक किया गया है जो आपके पास भविष्य के डेवलपर्स के लिए उपलब्ध सब कुछ है।
शेन सी। मेसन

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

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

18
उस तर्क के द्वारा आपको अपनी संकलित वस्तु फ़ाइलों, पुस्तकालयों और निष्पादन योग्य वस्तुओं में भी जाँच करनी चाहिए।
लॉरेंस गोंसाल्वेस

9
"मूल भाषा अर्थहीन है", आप किस प्रकार के कोड जनरेटर का उपयोग कर रहे हैं? कोड के प्रत्येक संस्करण का उपयोग करने के लिए आप अपने टूल के कौन से संस्करणों का ट्रैक रखने के बारे में इस बिंदु के लिए, आपको पहले से ही अपने पूरे टूलकिन के लिए उस समस्या को हल करने की आवश्यकता है। आखिरकार, आप अपने उत्पाद के एक पुराने संस्करण में बग को कैसे वापस करने की उम्मीद करते हैं जब तक आपको पता नहीं होता है कि आप वापस संकलक और लिंकर के किस संस्करण का उपयोग कर रहे थे? एक कोड जनरेटर आपके C ++ / Java / C # संकलक से अलग नहीं है। यह तथ्य कि आप इसका आउटपुट पढ़ सकते हैं, सारहीन है: इसका इनपुट स्रोत है।
लॉरेंस गोंसाल्वेस

31

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

मैं संशोधनों की एक क्लीनर सूची रखना पसंद करूंगा जिसमें केवल वास्तविक अपडेट शामिल हैं, जो ऑटो-जनरेट किए गए परिवर्तन नहीं हैं।

उन्हें बाहर छोड़ दें, और फिर एक निर्माण के बाद, उत्पन्न फ़ाइलों में से प्रत्येक पर एक 'उपेक्षा' जोड़ें।


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

5
जब तक मैं वहां हूं, वे तब तक 'बदलते हुए' के ​​रूप में दिखाई नहीं देते जब तक कि वे वास्तव में नहीं बदले। यदि वे पुनर्जीवित हो गए थे, लेकिन अभी भी एक ही सामग्री है तो केवल एक चीज अलग है फ़ाइल बनाएं / संशोधित तिथियां, सिस्टम को लगता है कि वे बदल नहीं गए हैं और सब कुछ ठीक है।
जोएल कोएहॉर्न

+1 मैं केवल यह लिखना चाहता हूं कि मैं क्या कोड लिखता हूं, न कि कुछ कोड जो कुछ टूलकिट द्वारा उत्पन्न हुए हैं जो उस समय समस्या हो सकती थी जो अब नकल करना असंभव है (लेकिन कोई व्यक्ति बहुत समय बिताने की कोशिश कर सकता है।)
dkretz

4
मैंने हर बार चलने वाले टाइमस्टैम्प को अपडेट करने वाले औटोजेनरिंग टूल देखे हैं। मैं उन्हें श्राप देता हूं।
कीवेली

25

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

यदि आपको किसी उत्पन्न फ़ाइल के ऐतिहासिक संस्करण को देखने की आवश्यकता है तो आप इसके स्रोतों के ऐतिहासिक संस्करण को सिंक कर सकते हैं और पुनर्निर्माण कर सकते हैं।

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


20

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


1
FYI करें, मैंने उस तुलना को करने के लिए एक स्क्रिप्ट साझा की है: stackoverflow.com/a/16754923/105137
kostmo

17

मैं DRY सिद्धांत कहता हूं। यदि आपके पास पहले से ही रिपॉजिटरी में "सोर्स फाइल्स" हैं, जो कि इन कोड फाइल्स को बिल्ड टाइम पर जेनरेट करने के लिए उपयोग की जाती हैं, तो समान कोड को "दो बार" करने की आवश्यकता नहीं है।

इसके अलावा, आप इस तरह से कुछ समस्याओं को हल कर सकते हैं यदि उदाहरण के लिए किसी दिन कोड पीढ़ी टूट जाती है।


15

नहीं, तीन कारणों से।

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

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

  3. एक बार जब यह स्रोत नियंत्रण में होता है, तो मैं एक के लिए जिम्मेदारी स्वीकार करता हूं। यह वहाँ है, बी। यह चालू है, और सी। यह वहाँ में बाकी सब कुछ के साथ मज़बूती से एकीकृत किया जा रहा है। जब मैं अब इसका उपयोग नहीं कर रहा हूं तो इसे हटाना शामिल है। जितना कम उतना ही बेहतर जिम्मेदारी।


14

मुझे वास्तव में नहीं लगता कि आपको उन्हें जांचना चाहिए।

निश्चित रूप से उत्पन्न कोड में कोई भी परिवर्तन या तो शोर होने वाला है - वातावरण के बीच परिवर्तन, या किसी और चीज़ के परिणामस्वरूप परिवर्तन - जैसे आपके DB में परिवर्तन। यदि आपकी DB की निर्माण स्क्रिप्ट (या कोई अन्य निर्भरता) स्रोत नियंत्रण में हैं तो आपको उत्पन्न स्क्रिप्ट की भी आवश्यकता क्यों है?


8

सामान्य नियम नहीं है , लेकिन अगर कोड (डीबी एक्सेस, वेब सेवाओं आदि के कारण) को उत्पन्न करने में समय लगता है, तो आप स्रोत नियंत्रण में कैश्ड संस्करण को सहेजना चाहते हैं और सभी को दर्द से बचा सकते हैं।

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

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


6

हम डीबी कोड को या तो स्टोर नहीं करते हैं: चूंकि यह उत्पन्न होता है, आप इसे स्रोत फ़ाइलों से किसी भी दिए गए संस्करण में प्राप्त कर सकते हैं। इसे संचय करना बाइटकोड या इस तरह के भंडारण की तरह होगा।

अब, आपको यह सुनिश्चित करने की आवश्यकता है कि दिए गए संस्करण में उपयोग किए गए कोड जनरेटर उपलब्ध है! नए संस्करण विभिन्न कोड उत्पन्न कर सकते हैं ...


5

इसे छोड़ दो।

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

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

दर्द की दुनिया उन लोगों की प्रतीक्षा करती है जो उत्पन्न फ़ाइलों में जांच करते हैं!


4

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


2
इसी तरह की टिप्पणी ऑटोकॉन्फ़ / स्वचालित-जनरेटेड फ़ाइलों पर लागू होती है; अधिकांश लोग अपने ./configure और Makefile.in फाइलों में जांच करते हैं, भले ही वे उत्पन्न हों - अधिकांश उपयोगकर्ताओं (और कई डेवलपर्स) को उन्हें फिर से बनाने की आवश्यकता नहीं होगी, और उन फ़ाइलों की जांच करके, आपको ऑटोटूल स्थापित करने की आवश्यकता नहीं है बनाने के लिए।
स्टोबोर

1
हाँ, हम अपनी कॉन्फ़िगर स्क्रिप्ट और हमारी जेनरेट की गई निर्भरता को संस्करण नियंत्रण में भी संग्रहीत करते हैं।
फिल मिलर

4

थोड़ी देर से आ रहा है ... वैसे भी ...

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

तो मैं कहूंगा: संस्करण नियंत्रण के तहत उत्पन्न कोड मत डालो, लेकिन जनरेटर और इसके इनपुट।

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


3

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

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


3

कॉन्फ़िगरेशन प्रबंधन का काम (जिसमें से संस्करण नियंत्रण सिर्फ एक हिस्सा है) निम्नलिखित कार्य करने में सक्षम है:

  • जानें कि कौन से बदलाव और बग फिक्स हर डिलीवर किए गए बिल्ड में चले गए हैं।
  • मूल स्रोत कोड से शुरू होने वाले किसी भी वितरित निर्माण को पुन: पेश करने में सक्षम हो। भाषा की परवाह किए बिना स्वचालित रूप से उत्पन्न कोड को "स्रोत कोड" के रूप में नहीं गिना जाता है।

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

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

इसका मतलब है कि आपके कंपाइलर, लाइब्रेरी आदि को भी सीएम का हिस्सा होना चाहिए।

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


2

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

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

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


"यह न केवल आपके स्रोत कोड का मतलब है, बल्कि आपके बिल्ड वातावरण, आपका आईडीई, शायद अन्य पुस्तकालय, जनरेटर या सामान भी है" \ n यह सब सामान है जिसमें मैं जांच करूंगा। यदि आप स्रोत के रूप में प्रत्येक डेवलपर मशीन पर अपने कंपाइलर का निर्माण करते हैं। अपने ऐप्स के समान निर्माण करें (यानी: आप एक बार 'मेक' टाइप करते हैं), स्रोत में देखें। यदि आप नहीं करते हैं, तो बायनेरिज़ में जांचें
KeyserSoze

2

सही उत्तर है "यह निर्भर करता है"। यह ग्राहक की जरूरतों पर निर्भर करता है। यदि आप किसी विशेष रिलीज़ पर वापस कोड रोल कर सकते हैं और इसके बिना किसी बाहरी ऑडिट के लिए खड़े हो सकते हैं, तो आप अभी भी दृढ़ जमीन पर नहीं हैं। देव के रूप में हमें न केवल 'शोर', दर्द और डिस्क स्थान पर विचार करने की आवश्यकता है, बल्कि यह तथ्य कि हमें बौद्धिक संपदा उत्पन्न करने की भूमिका के साथ काम सौंपा जाता है और कानूनी अड़चन हो सकती है। क्या आप एक न्यायाधीश को साबित करने में सक्षम होंगे कि आप एक वेब साइट को फिर से बनाने में सक्षम हैं जिस तरह से एक ग्राहक ने दो साल पहले देखा था?

मैं आपको सुझाव नहीं दे रहा हूं कि आप जीनॉयड फाइलों को सेव करें या सेव न करें, फिर भी आप जो भी निर्णय लेते हैं यदि आप उस निर्णय के विषय विशेषज्ञ को शामिल नहीं कर रहे हैं तो आप शायद गलत हैं।

मेरे दो सेंट।


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

डोमेन में है कि मैं वर्तमान में हूँ, हमारे (बहुत बड़े) ग्राहक बीमा कम से कम 10 साल के लिए रहता है। हम WCF सेवाओं को जनरेट करने के लिए परिष्कृत उपकरण बनाते हैं। ग्राहक जनरेट किए गए कोड, टेम्प्लेट, पूरी चीज़ को रखते हैं। लेकिन वह मेरा मुवक्किल है। लगता है कि आप उस बिंदु से चूक गए जो मैं कह रहा था कि "यह ग्राहक की जरूरतों पर निर्भर करता है" और "जो भी आप तय करते हैं कि यदि आप निर्णय के विषय विशेषज्ञ को शामिल नहीं कर रहे हैं तो आप शायद गलत हैं।" अगर किसी तरह यह एक बुरा जवाब है, या यह आपको बेहतर -1 देने में मदद करता है, तो खुशी है कि आपने मदद की है। मेरे उत्तर के ऊपर टिप्पणी पर 'आघात' का संदर्भ लें।
जेम्स फ्लेमिंग

2

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

मेरे लिए मुख्य विचार उत्पन्न आउटपुट को अलग कर रहा है जब या तो इनपुट या जनरेटर स्वयं अपडेट किया जाता है।

यदि आपके पास अपना आउटपुट चेक नहीं किया गया है, तो आपको नए संस्करण से आउटपुट के साथ तुलना करने में सक्षम होने के लिए जनरेटर या संशोधित इनपुट को अपग्रेड करने से पहले सभी उत्पन्न कोड की एक प्रति लेनी होगी। मुझे लगता है कि यह काफी थकाऊ प्रक्रिया है, लेकिन आउटपुट में जाँच के साथ, यह रिपॉजिटरी के खिलाफ नए आउटपुट को अलग करने का एक सरल मामला है।

इस बिंदु पर, यह पूछना वाजिब है कि "आप उत्पन्न कोड में बदलावों की परवाह क्यों करते हैं?" (विशेष रूप से ऑब्जेक्ट कोड की तुलना में।) मेरा मानना ​​है कि कुछ प्रमुख कारण हैं, जो किसी भी अंतर्निहित समस्या के बजाय कला की वर्तमान स्थिति में आते हैं।

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

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

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

अनिवार्य रूप से ये सभी चीजें उपकरण की परिपक्वता के लिए नीचे आती हैं - अधिकांश व्यवसाय ऐप कोड जनरेटर उस स्तर के करीब नहीं होते हैं जो संकलक या यहां तक ​​कि lex / yacc- स्तर के उपकरण वर्षों से हैं।


2

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

अब, दोनों पक्षों की दलीलें इस तरह की जा सकती हैं:

  • "जब मैं चेकआउट करता हूं तो मैं इन सभी उत्पन्न फ़ाइलों को प्राप्त करना चाहता हूं, क्योंकि मेरे पास इस मशीन में उत्पन्न करने के लिए उपकरण नहीं है।"
  • "मुझे उन्हें वीसीएस में नहीं डालना चाहिए, क्योंकि मुझे इस फाइल के बदलाव में कोई दिलचस्पी नहीं है।"

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

सारांश

मैं एक उदाहरण के रूप में बताऊंगा कि मेरा क्या मतलब है।

  • git status उत्पन्न फ़ाइलों को डिफ़ॉल्ट रूप से नहीं दिखाना चाहिए।
  • git commit इसमें स्नैपशॉट के रूप में उत्पन्न फाइलें शामिल होनी चाहिए।
  • git diff उत्पन्न फ़ाइलों को डिफ़ॉल्ट रूप से नहीं दिखाना चाहिए।

पुनश्च

गिट हुक को वर्कअराउंड के रूप में इस्तेमाल किया जा सकता है, लेकिन यह बहुत अच्छा होगा यदि गिट मूल रूप से इसका समर्थन करता है। gitignoreहमारी आवश्यकता को पूरा नहीं करता है, अनदेखा फ़ाइलों के लिए VCSs में नहीं जाएगा।enter code here


1

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

इसके अतिरिक्त, यह हर "स्नैपशॉट" का हिस्सा और पार्सल है जो आप अपने सॉफ़्टवेयर रिपॉजिटरी से लेते हैं। यदि यह सॉफ्टवेयर का हिस्सा है, तो यह रिपॉजिटरी का हिस्सा होना चाहिए।


5
मुझे ड्राइव -1 से बहुत पसंद है। यदि आप सहमत नहीं हैं, तो इसे वोट न करें - अन्य उत्तरों को वोट करें। गलत उत्तर के लिए चढ़ाव को बचाएं। यह एक व्यक्तिपरक प्रश्न है।
womp

1

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


2
क्या आप अपनी ऑब्जेक्ट फ़ाइलों (.o) में जांचते हैं?
KeyserSoze

1

सामान्य तौर पर, उत्पन्न कोड को स्रोत नियंत्रण में संग्रहीत नहीं किया जाना चाहिए क्योंकि इस कोड के संशोधन इतिहास को उस कोड के संशोधन इतिहास से पता लगाया जा सकता है जिसने इसे उत्पन्न किया था!

हालाँकि, ऐसा लगता है कि ओपी उत्पन्न कोड का उपयोग कर रहा है क्योंकि मैन्युअल रूप से लिखने के बजाय एप्लिकेशन की डेटा एक्सेस परत है। इस स्थिति में, मैं निर्माण प्रक्रिया को बदलूंगा, और कोड को स्रोत नियंत्रण के लिए प्रतिबद्ध करूंगा क्योंकि यह रनटाइम कोड का एक महत्वपूर्ण घटक है। डेवलपर्स द्वारा विभिन्न शाखाओं के लिए टूल के अलग-अलग संस्करण का उपयोग करने की आवश्यकता होने की स्थिति में यह कोड निर्माण टूल से निर्भरता को भी हटाता है।

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


मैं असहमत हूं। यदि आप इसे एक मैन्युअल प्रक्रिया बनाते हैं, तो यह टूट जाएगा , और कोई भी इसे तब तक नोटिस नहीं करेगा जब तक कि इसे पुनर्मिलन करने का समय नहीं आता। यदि यह आपके बिल्ड सर्वर पर हर दिन उत्पन्न होता है (और प्रत्येक डेवलपर्स मशीन जब 'क्लीन' बिल्ड करता है), तो आपको आश्चर्य नहीं होगा।
KeyserSoze

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

1

मैं (अफसोस) स्रोत नियंत्रण के तहत बहुत सारे व्युत्पन्न स्रोत डाल रहा हूं क्योंकि मैं उन लोगों के साथ दूर से काम करता हूं जो या तो एक उचित बिल्ड वातावरण स्थापित करने के लिए परेशान नहीं हो सकते हैं या जिनके पास इसे स्थापित करने का कौशल नहीं है व्युत्पन्न स्रोत बिलकुल सही बने हैं। (और जब यह ग्नू ऑटोटूल की बात आती है, तो मैं खुद उन लोगों में से एक हूं! मैं तीन अलग-अलग प्रणालियों के साथ काम नहीं कर सकता हूं, जिनमें से प्रत्येक ऑटोटूल के एक अलग संस्करण के साथ काम करता है- और केवल वह संस्करण है।)

इस तरह की कठिनाई शायद भुगतान की गई परियोजनाओं की तुलना में अंशकालिक, स्वयंसेवक, ओपन-सोर्स परियोजनाओं पर अधिक लागू होती है जहां बिलों का भुगतान करने वाला व्यक्ति एक समान बिल्ड वातावरण पर जोर दे सकता है।

जब आप ऐसा करते हैं, तो आप मूल रूप से केवल एक साइट पर या केवल ठीक से कॉन्फ़िगर की गई साइटों पर व्युत्पन्न फ़ाइलों के निर्माण के लिए प्रतिबद्ध हैं। आपके Makefiles (या जो भी) को नोटिस करने के लिए सेट किया जाना चाहिए कि वे कहां चल रहे हैं और उन्हें स्रोतों को फिर से प्राप्त करने से मना करना चाहिए जब तक कि उन्हें पता न हो कि वे एक सुरक्षित बिल्ड साइट पर चल रहे हैं।


1

यदि यह स्रोत कोड का हिस्सा है, तो इसे स्रोत नियंत्रण में रखा जाना चाहिए, चाहे कोई भी हो या जो इसे उत्पन्न करता है। आप चाहते हैं कि आपका स्रोत नियंत्रण आपके सिस्टम की वर्तमान स्थिति को फिर से उत्पन्न किए बिना प्रतिबिंबित करे।


"इसे पुनर्जीवित किए बिना।" तो आप संकलित बायनेरिज़ में जांच करते हैं? क्या आप लक्ष्य प्लेटफ़ॉर्म के संस्करण में भी जांचते हैं? वह रणनीति अच्छी नहीं होगी। :(
dss539

1
और वह मुझे एक डाउन वोट मिलता है ?? बेशक आप संकलित बायनेरिज़ में जांच नहीं करते हैं (जब तक कि वे तीसरे पक्ष के पुस्तकालयों से नहीं हैं) क्योंकि वे आपके स्रोत कोड से पुनर्जीवित हो सकते हैं। मैं बायनेरिज़ नहीं जनरेट किए गए कोड को फिर से बनाने के बारे में बात कर रहा था। लेकिन हे, अगर आप गलत
बोलना

इस जवाब के लायक नहीं था! बहुत कम से कम, यह SC में उत्पन्न कोड डालने के लिए ध्वनि लगता है (शायद एक स्पष्ट रूप से पहचानी गई जगह में) ताकि बहुत कम से कम आप उस कोड के हैश की तुलना कर सकते हैं जिसका उपयोग उस नए कोड के विरुद्ध वस्तु उत्पन्न करने के लिए किया जा रहा है जिसे आप जा रहे हैं एक नए निर्माण के लिए उत्पन्न। दिलचस्प है कि यह सवाल कितना ध्रुवीकरण करता है।
आर.पी.

1

कई कारणों से स्रोत नियंत्रण में बिलकुल उत्पन्न कोड है। मैं दोहरा रहा हूं कि बहुत सारे लोगों ने पहले ही कहा है, लेकिन कुछ कारण जो मैं कर सकता हूं

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

1
और अपने कोड जनरेटर ही स्रोत नियंत्रण में नहीं है क्योंकि ...?
जेफरी हेंटिन

@ जेफ्री: मैंने कभी नहीं कहा कि कोड जनरेटर स्रोत नियंत्रण में नहीं था।
जो एनोस

मुझे पता है, मैं सिर्फ चिढ़ा रहा हूं। :-) मैंने पाया है कि बहुत सारे कोडडॉम-आधारित कोड जनरेटर यादृच्छिक क्रम में अपने उत्पादन का उत्पादन करना पसंद करते हैं, हालांकि, इसलिए पुनरावृत्ति के लिए (और इस प्रकार आसानी से बताने की क्षमता है कि यदि उत्पन्न रन से रन में परिवर्तन होता है) I ' ve ने एक दिनचर्या लिखी है जो CodeCompileUnitएक कैनोनिकल ऑर्डर में सामग्री को सॉर्ट करता है ।
जेफरी हेंटिन

0

मैं एक स्रोत के पेड़ से उत्पन्न फ़ाइलों को छोड़ दूंगा, लेकिन इसे एक अलग बिल्ड पेड़ में डाल दूंगा।

जैसे वर्कफ़्लो है

  1. चेकइन / आउट / संशोधित / मर्ज स्रोत सामान्य रूप से (w / o किसी भी उत्पन्न फाइल)
  2. उपयुक्त अवसरों पर, स्रोत के पेड़ को एक साफ बिल्ड ट्री में देखें
  3. एक निर्माण के बाद, सभी "महत्वपूर्ण" फाइलें ("वास्तविक" स्रोत फाइलें, निष्पादनयोग्य + उत्पन्न स्रोत फ़ाइल) चेकइन करें जो ऑडिटिंग / नियामक उद्देश्यों के लिए मौजूद होनी चाहिए। यह आपको सभी उपयुक्त जनरेट किए गए कोड + एक्जीक्यूटिव + का इतिहास देता है, जो भी समय पर वेतन वृद्धि / स्नैपशॉट इत्यादि से संबंधित होते हैं और दिन-प्रतिदिन के विकास से अलग हो जाते हैं।

सबवॉर्शन / मर्क्यूरियल / Git / etc में अच्छे तरीके हैं, वास्तविक स्रोत फ़ाइलों के इतिहास को एक साथ रखने के लिए।


0

ऐसा लगता है कि दोनों पक्षों में बहुत मजबूत और ठोस राय है। मैं सभी शीर्ष मतदान उत्तरों को पढ़ने की सलाह दूंगा, और फिर यह निर्णय लेते हुए कि आपके विशिष्ट मामले में क्या तर्क लागू होते हैं।

अद्यतन: मैंने यह प्रश्न तब से पूछा था जब मुझे वास्तव में विश्वास था कि एक निश्चित उत्तर है। सभी प्रतिक्रियाओं को देखते हुए, मैं उच्च स्तर की निश्चितता के साथ कह सकता हूं, कि ऐसा कोई उत्तर नहीं है। निर्णय एक से अधिक मापदंडों के आधार पर किया जाना चाहिए। अन्य उत्तरों को पढ़ना इस प्रकार के प्रश्नों के बारे में एक बहुत अच्छी दिशानिर्देश प्रदान कर सकता है जिन्हें आपको इस मुद्दे पर निर्णय लेने के लिए स्वयं से पूछना चाहिए।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.