संस्करण नियंत्रण में तृतीय पक्ष पुस्तकालयों के लिए और इसके खिलाफ तर्क?

Question

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

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

क्या "ग्रेनटेड-टू-वर्क" पुस्तकालयों के संदर्भ में आप वहां एक libs फ़ोल्डर रखना इतना बुरा है?

Answer 1

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

Answer 2

हां आपको (जब संभव हो) चाहिए।

आपको एक ताजा मशीन लेने और संभवतः कुछ चरणों के साथ अपनी परियोजना का निर्माण करने में सक्षम होना चाहिए। मेरे लिए, यह है:

1. स्थापित आईडीई (जैसे दृश्य स्टूडियो)
2. स्थापित VCS (जैसे SVN)
3. चेकआउट
4. बिल्ड

कुछ भी अधिक है बहुत अच्छा औचित्य है।

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

Answer 3

तृतीय पक्ष सॉफ़्टवेयर का स्रोत संबंधित नहीं है (शायद स्थिर संदर्भ के रूप में), लेकिन संकलित बाइनरी करते हैं।

यदि आपकी बिल्ड प्रक्रिया एक असेंबली/डीएलएल/जार/मॉड्यूल संकलित करेगी, तो केवल तीसरे पक्ष के स्रोत कोड को स्रोत नियंत्रण में रखें।

यदि आप इसे संकलित नहीं करेंगे, तो बाइनरी असेंबली/डीएलएल/जार/मॉड्यूल को स्रोत नियंत्रण में रखें।

Answer 4

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

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

Answer 5

मुझे तृतीय पक्ष की बाइनरी को "lib" निर्देशिका में देखना पसंद है जिसमें बाहरी निर्भरताएं हैं। आखिरकार, आप उन पुस्तकालयों के विशिष्ट संस्करणों का सही ट्रैक रखना चाहते हैं?

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

Answer 6

यह आपके पास भाषा और/या पर्यावरण पर निर्भर हो सकता है, लेकिन परियोजनाओं के लिए मैं स्रोत नियंत्रण में कोई पुस्तकालय (जार फाइल) नहीं रखता हूं। यह मैवेन जैसे टूल का उपयोग करने में मदद करता है जो आपके लिए आवश्यक पुस्तकालय लाता है। (प्रत्येक परियोजना के लिए आवश्यक जार की एक सूची, Maven उन्हें स्वचालित रूप से एक आम रिपोजिटरी से हासिल करेगा रखता है - http://repo1.maven.org/maven2/)

कहा जा रहा है, तो आप Maven या प्रबंधन और स्वचालित रूप से प्राप्त करने में कठिनाई आवश्यक पुस्तकालयों के कुछ अन्य साधनों, उपयोग नहीं कर रहे है, तो द्वारा सभी साधनों को उन्हें अपने संस्करण नियंत्रण प्रणाली में जांचें। संदेह में, इसके बारे में व्यावहारिक रहें।

Answer 7

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

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

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

Answer 8

नहीं - मुझे नहीं लगता कि आपको तीसरे पक्ष के पुस्तकालयों को स्रोत नियंत्रण में रखना चाहिए। सुराग 'स्रोत नियंत्रण' नाम पर है।

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

अतिरिक्त कोड पुस्तकालय समान हैं। तैनाती के आसान के लिए उन्हें स्रोत नियंत्रण में शामिल करने के बजाय, एक तैनाती/वितरण तंत्र बनाएं जो सभी निर्भरताओं को आसानी से प्राप्त और स्थापित करने की अनुमति देता है।यह बाहर की जाँच और की तरह अपने सॉफ्टवेयर कुछ चलाने के लिए चरणों बनाता है:

• स्थापित VCS
• सिंक कोड
• भागो सेटअप स्क्रिप्ट (जो डाउनलोड और सभी निर्भरता का सही संस्करण को स्थापित करता है)

एक विशिष्ट उदाहरण देने के लिए (और मुझे एहसास है कि यह काफी वेब केंद्रित है), एक पायथन वेब एप्लिकेशन में एक आवश्यकता.txt फ़ाइल हो सकती है जो पढ़ता है:

simplejson == 1 .2
Django == 1.0
otherlibrary == 0.9

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

Answer 9

एक अन्य कारण अपने स्रोत नियंत्रण जो मैं यहाँ उल्लेख किया है कि यह आप एक विशिष्ट स्नैपशॉट या संस्करण से आपके आवेदन के पुनर्निर्माण करने की क्षमता देता है नहीं देखा है के लिए पुस्तकालयों में जांच करने के लिए। यह आपको सटीक संस्करण को फिर से बनाने की अनुमति देता है कि कोई भी बग की रिपोर्ट कर सकता है। यदि आप उस सटीक संस्करण का पुनर्निर्माण नहीं कर सकते हैं जिसे आप समस्याएं पुन: उत्पन्न/डिबग करने में सक्षम नहीं हैं।

Answer 10

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

1. आप नए डेवलपर्स उठकर
2. हर कोई विभिन्न पुस्तकालयों
3. हम वास्तव में पता कर सकते हैं का एक ही संस्करण का उपयोग करता चल कर सकते हैं की जरूरत है तीसरे पक्ष के पुस्तकालयों सहित समय पर दिए गए बिंदु पर कौन सा कोड चालू था।

Answer 11

यदि मैं इससे दूर हो सकता हूं, तो मैं उन्हें अपने संस्करण नियंत्रण से बाहर रखता हूं और अपनी फाइल सिस्टम से बाहर रखता हूं।

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script> 

मेरा अगला चुनाव Git Submodules की तरह कुछ का उपयोग करने के होगा: इस का सबसे अच्छा मामले jQuery जहां मैं गूगल के AJAX लाइब्रेरी का उपयोग और वहाँ से इसे लोड होगा। और उन पर्याप्त न हो, वे संस्करण नियंत्रण में समाप्त कर देंगे, लेकिन उस बिंदु पर, अपने ही तारीख आप कर रहे हैं के रूप में करने के लिए के रूप में ...

Answer 12

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

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