मैं एक वितरित टीम के साथ कुछ कक्षा पुस्तकालयों का विकास कर रहा हूं। हम अपने स्रोत नियंत्रण के लिए सबवर्जन का उपयोग करते हैं। डेवलपर्स में से एक अपने बिन और obj रिपोजिटरी में निर्देशिका करना चाहता है, जो मेरे लिए मानक अभ्यास कभी नहीं रहा है। सबसे अच्छा अभ्यास क्या है? पक्ष और विपक्ष क्या होते हैं?क्या मुझे अपने सबवर्जन रिपोजिटरी में संकलित बाइनरी जोड़नी चाहिए?
आपको निश्चित रूप से किसी भी संकलित फाइल को मुख्य शाखा में नहीं जोड़ना चाहिए। आप उन्हें सामान्य उपकरणों से तुलना नहीं कर सकते हैं और वे सबकुछ धीमा कर देंगे।
रिलीज की संस्करण शाखाओं में, आप उन्हें मूल संकलित फाइलें रखने के लिए शामिल कर सकते हैं, इसलिए कोई फर्क नहीं पड़ता क्योंकि संकलक बदल गया या ऐसा कुछ।लेकिन आप शायद कहीं और सभी बाइनरी रिलीज संग्रहीत करेंगे और सबवर्सन वास्तव में सही जगह नहीं है।
हम उन फ़ाइलों को भी छोड़ रहे हैं क्योंकि वे समय के साथ आपके परिवर्तनों के तरीके में "प्रदूषित" होते हैं। इसलिए प्रत्येक प्रतिबद्धता में आपके पास अन्य फाइलों का एक गुच्छा बदल जाएगा, लेकिन आपको केवल आपके स्रोत कोड में दिलचस्पी होगी जो संकलित फाइलों में बदल गया है और नहीं।
तो कल्पना करें कि आप क्या XYZ संशोधन में गलत हो गया था की जांच करने की कोशिश कर रहे हैं और आप परिवर्तन निम्नलिखित में देखते हैं ...
a.dll
b.dll
c.dll
d.cs
e.dll
... ... ...
लेकिन आप केवल शायद स्रोत में रुचि रखते हैं, तो उन प्रदूषण फैलाने के अलावा अन्य फ़ाइलों वर्ज़निंग खास मतलब भी जब से तुम नहीं के बाद से क्या बाइनरी अंदर वैसे भी बदल सकते हैं नहीं है ..
हम बिन और ओबीजे फाइलें नहीं करते हैं क्योंकि जब आप संकलित करते हैं तो उन्हें बनाया जाता है इसलिए कोई वास्तविक आवश्यकता नहीं होती है। पता नहीं है कि यह एक सर्वोत्तम अभ्यास है, और अधिक व्यक्तिगत राय।
मुझे लगता है कि आपके पास "पूर्ण डीएलएस" या कुछ डीएल के एक पूर्ण संस्करण के लिए एक अलग फ़ोल्डर हो सकता है ??
मैं देख सकता हूं कि आप डिब्बे क्यों करना चाहते हैं, उदाहरण के लिए यदि आपके पास एक ऐप के विभिन्न संस्करण हैं जिन्हें आपको बनाए रखने की आवश्यकता है जिसके लिए डीएलएल के विशिष्ट संस्करणों की आवश्यकता है। लेकिन यहां तक कि उस मामले में, आप हमेशा एक टैग/शाखा से नए डिब्बे बना सकते हैं।
obj फ़ाइलें करने के लिए के रूप में, मुझे लगता है कि करने के लिए कोई अच्छा कारण के बारे में सोच नहीं कर सकते ..
मेरा नियम है कि सभी उत्पन्न फ़ाइलों बाहर रखा गया है है।
मेरे लिए भी देखें। चूंकि कुछ डीएलएल आपका कोड नहीं हो सकता है और साइट सीधे स्रोत से काम नहीं करेगी। वेब प्रोजेक्ट्स में एक रेफरेंसिंग तंत्र नहीं है जो प्रोजेक्ट को ताजा सेट कर रहा है वह गधे में निर्भरता को शिकार करने में दर्द है। –
वेब परियोजनाओं के बारे में, .refresh फ़ाइलों का उपयोग नहीं कर सका? वे वास्तविक डीएलएल को इंगित करते हैं, इसलिए यदि आपको रिपोजिटरी से स्रोत की ताजा प्रति मिलती है और इसमें शामिल हैं। ताज़ा फ़ाइलें, यह ठीक से निर्माण करेगी। –
जब तक आपके पास स्रोत कोड नहीं है तब तक मैं स्रोत नियंत्रण में संकलित libaries नहीं जोड़ूंगा।
उदाहरण के लिए:
3 पार्टी पुस्तकालय/नियंत्रण है जिसके लिए मैं स्रोत नहीं है = "निर्भरता" फ़ोल्डर के कुछ प्रकार के तहत स्रोत नियंत्रण में जाओ।
हमारे द्वारा लिखे गए किसी भी पुस्तकालय = केवल स्रोत भंडार में है, कभी द्विआधारी नहीं।
जब तक कोई अच्छा कारण नहीं है जिसे आपने उल्लेख करने के लिए छोड़ा है, तो नहीं, स्रोत नियंत्रण में अपनी बिन निर्देशिकाएं न जोड़ें। मैं आपकी obj निर्देशिकाओं को प्रतिबद्ध करने के लिए कोई अच्छा कारण नहीं देख सकता।
आमतौर पर मैं कभी भी स्रोत नियंत्रण प्रणाली में बिन निर्देशिका को बाध्य नहीं करता हूं। कारण यह है कि इसे स्वचालित रूप से पुन: उत्पन्न करना होगा और इसलिए स्रोत नियंत्रण में जेनरेट किए गए डीएल को जोड़ने का कोई मूल्य नहीं है।
वही बात जेनरेट की गई स्रोत फ़ाइलों के साथ है, लेकिन एक अपवाद है: यदि इसमें समय लगता है या आपको स्रोत फ़ाइलों को उत्पन्न करने के लिए बुनियादी ढांचा होना है, तो मैं उन्हें स्रोत नियंत्रण में जोड़ता हूं।
जब आप विभिन्न संस्करणों को प्रबंधित करना चाहते हैं, तो शाखा दृष्टिकोण मेरा पसंदीदा होगा।
मैं अपने स्रोत नियंत्रण प्रणाली में किसी भी बाइनरी को स्टोर करने की कोशिश नहीं करता - यहां तक कि पुस्तकालयों में भी जहां हमारे पास स्रोत नहीं है। भंडार में बाइनरी रखने से भंडार ब्लाउट होता है और चेकआउट धीमा हो जाता है।
हम अपनी सबवर्जन परियोजनाओं के निर्माण के लिए Maven का उपयोग करते हैं। मेवेन में, आपके आवेदन द्वारा आवश्यक सभी बाइनरी (लेकिन आपके ऐप द्वारा नहीं बनाई गई) को मैवेन रिपोजिटरी कहा जाता है। मेवेन अनुप्रयोगों द्वारा उपयोग की जाने वाली बाइनरी फ़ाइलों को "संस्करण" संलग्न करने के लिए सम्मेलनों का उपयोग करता है। इन फ़ाइलों को आसानी से एप्लिकेशन और डेवलपर्स द्वारा साझा किया जाता है (सभी के लिए 1 प्रति)।
एकमात्र मामला जहां मैंने देखा है कि मूल्य है एन-स्तरीय एप्लिकेशन में है जहां कुछ बाइनरी एक स्तर से दूसरे में वितरित की जाती हैं।
उदाहरण के लिए, कोड का हिस्सा सभी स्तरों द्वारा उपयोग की जाने वाली सामान्य वस्तुओं का प्रतिनिधित्व करता है। फिर प्रत्येक स्तर वास्तव में अपनी उप-प्रोजेक्ट है जो द्विआधारी के रूप में संदर्भित सामान्य वस्तुओं का उपयोग करता है, लेकिन अकेले उस स्तर पर काम करना बाइनरी पर निर्भर करता है। उस स्थिति में, भले ही प्रोजेक्ट में पूरी तरह से स्रोत कोड है, वास्तव में एक बाइनरी परियोजना का एक हिस्सा है, जैसे किसी तीसरे पक्ष की लाइब्रेरी एक तरह से।
उस स्थिति में यह सुनिश्चित करने के लिए यह समझ में आ सकता है कि टायर स्रोत नियंत्रण में बाइनरी के सही संस्करण को जमा करके सफलतापूर्वक संकलित करना जारी रखता है, और हमेशा स्रोत से नहीं बना रहता है।
कहा जा रहा है कि यदि आप उस प्रतिमान को रद्द कर सकते हैं, और प्रत्येक स्तर के निर्माण में सभी निर्भरताओं को शामिल कर सकते हैं तो जीवन बहुत आसान होगा। किसी अन्य स्रोत के पीछे परियोजना के एक हिस्से की बाइनरी होने से सुंदर नहीं है और आपदा हो सकती है।
हम बिन या ओबीजे फ़ोल्डर्स नहीं करते हैं, और हम लाइब्रेरी नामक रिपोजिटरी रूट पर एक नया फ़ोल्डर बनाते थे और हमने वहां सभी महत्वपूर्ण डीएलएल फाइलें रखीं, जैसे कि इस्तेमाल किए गए तीसरे पक्ष के उपकरण, उदाहरण के लिए AJAXtoolkit, fckeditor , .... और अन्य डीएलएल फाइलें हम इस परियोजना के लिए महत्वपूर्ण देखते हैं।
ठीक है, आइए शैतान के वकील को खेलते हैं ... यहां एक संग्रह में डीएलएल को स्टोर करने का मामला है।
कंपनी ए में किसी भी समय दिए गए 6+ टीमें हैं। इनमें से अधिकतर टीम सी # में अपने उत्पाद का कम से कम कुछ हिस्सा विकसित करती हैं। कंपनी ए की विशिष्ट प्रकृति को देखते हुए, मानक डेटटाइम कक्षाओं में पर्याप्त कार्यक्षमता नहीं है, इसलिए उन्होंने डेटटाइम से प्राप्त अपनी कक्षाएं विकसित की हैं जिन्हें वे एक डीएलएल में उपलब्ध कराते हैं।
प्रत्येक 6+ समूहों में रिपोजिटरी में अपनी निर्देशिका है और अधिकांश को डेटटाइम डीएलएल की आवश्यकता होती है, इसलिए उनके पास प्रत्येक उत्पाद निर्देशिका में संकलित डीएलएल की एक प्रति होती है, और नई प्रतियां केवल निर्देशिका में ही होती हैं कार्यक्षमता उपलब्ध है कि उस निर्देशिका में परियोजना की आवश्यकता है।
क्या कोई और समाधान है जो निम्नलिखित लाभ देता है ?: 1) डेवलपर्स को एक ही प्रोजेक्ट पर काम करने के लिए दो निर्देशिकाओं को चेक करने से रोकता है। (वास्तविक जीवन में दो से अधिक हैं, लेकिन इस उदाहरण के लिए चलिए इसे दो कहते हैं।) 2) क्यूए को सभी उत्पादों को दोबारा रखने से रोकता है जब केवल एक उत्पाद को डेटटाइम कक्षाओं को बदलने की आवश्यकता होती है।
प्रोजेक्ट द्वारा संदर्भित कस्टम लाइब्रेरी को शामिल किया जाना चाहिए, लेकिन यह बिन/ओबीजे फ़ोल्डर्स से जेनरेट की गई फ़ाइलों से अलग हैं। आदर्श रूप से आपको परियोजना के साथ शामिल "libs" फ़ोल्डर में कस्टम लाइब्रेरी रखना चाहिए। –
वह अपनी बिन और ओबीजे निर्देशिका क्यों प्रतिबद्ध करना चाहता है? क्या उसके पास एक अच्छा कारण है? – Grant
वेब प्रोजेक्ट के एक अपवाद के साथ, http://stackoverflow.com/questions/709372/alternative-to-binaries-in-subversion –