आइए एक उदाहरण देखें कि svn: बाह्य क्या हैं। मान लीजिए कि हमारे पास एक परियोजना है जो तीसरे पक्ष के ओपन-सोर्स कोड का उपयोग करती है, उदाहरण के लिए, प्रसिद्ध पीडीएफ लाइब्रेरी iText। आमतौर पर हम इस लाइब्रेरी के सभी आवश्यक कोड को पूरी तरह से अपने रिपॉजिटरी में कॉपी कर लेते हैं। इसके बाद, जब iText अद्यतन जारी किए जाते हैं, हम मैन्युअल रूप से पुरानी फ़ाइलों को नए के साथ बदलते हैं।
svn: बाहरी अधिक सुविधाजनक तरीका प्रदान करते हैं। हम अपनी रिपॉजिटरी के कुछ फोल्डर का चयन करते हैं और svn: externals property को इसके लिए इस रूप में सेट करते हैं ( TortoiseSVN का उपयोग करके यह कैसे करें ):
iText https://itext.svn.sourceforge.net/svnroot/itext/trunk
पहला पैरामीटर निर्धारित करता है कि परिवर्तनों को कहां से डाउनलोड किया जाए, दूसरा - जहां। अब, जब भी हम रिपॉजिटरी से नवीनतम अपडेट लेते हैं, तो iText का वर्तमान संस्करण स्वचालित रूप से डाउनलोड हो जाता है। सुविधाजनक।
पेशेवरों के बारे में
Svn का उपयोग करने के लाभों पर विचार करें: बाहरी।
दोहराव से बचें
DRY का सिद्धांत (खुद को दोहराएं नहीं) - गुणवत्ता सॉफ्टवेयर के विकास में आधारशिला - स्रोत कोड प्रबंधन तक फैली हुई है। यदि एक ही फाइल को कई रिपॉजिटरी में डुप्लिकेट किया जाता है - तो यह बहुत अच्छा नहीं है।
उदाहरण के लिए, स्थापित टीमों में, एक नियम के रूप में, सामान्य कोड का एक आधार बनता है, जिसका उपयोग लगातार विभिन्न परियोजनाओं में किया जाता है। सभी परियोजनाएं आवश्यक रूप से एक बड़े भंडार में नहीं होंगी। सबसे अधिक संभावना - अलग में। इस मामले में, बिना svn: externals, हम अलग-अलग रिपॉजिटरी के बीच एक ही फाइल को कॉपी करने के लिए बर्बाद होते हैं, साथ ही परिवर्तनों के मामले में उन्हें हर जगह मैन्युअल रूप से अपडेट करते हैं।
रिपॉजिटरी में जगह न लें
पिछले पैराग्राफ का एक सीधा परिणाम यह है कि स्रोत कोड केवल मूल रिपॉजिटरी में संग्रहीत किया जाता है, हम केवल इसे वहां से हमारी वर्किंग कॉपी में डाउनलोड करते हैं। रिपॉजिटरी का आकार बहुत महत्वपूर्ण हो सकता है यदि आप भुगतान किए गए एसवीएन होस्टिंग का उपयोग रिपॉजिटरी (एस) के कुल आकार पर एक सीमा के साथ करते हैं।
संरचना परियोजनाओं और मॉड्यूल के लिए आसान
नियम "1 परियोजना <-> 1 भंडार" के अनुसार परियोजनाओं को विभाजित करना उचित प्रतीत होता है। इस दृष्टिकोण के साथ, svn: externals का उपयोग निर्भर परियोजनाओं के पृथक्करण को आसान बनाने में मदद करता है।
बेशक, हम एक ही भंडार के भीतर सभी परियोजनाओं / मॉड्यूल पर काम कर सकते हैं, लेकिन यह दृष्टिकोण कमियों के बिना नहीं है। उदाहरण के लिए, सभी डेवलपर अपनी कार्यशील प्रतियों में कई अनावश्यक परिवर्तन अपलोड कर सकते हैं। यह उन परियोजनाओं तक डेवलपर्स की पहुंच को प्रतिबंधित करने के लिए काम नहीं करेगा, जिनके पास उनकी पहुंच नहीं होनी चाहिए। आसपास असंबंधित परियोजनाएं हैं। वैसे भी, ढेर पर सब कुछ रखना सही दृष्टिकोण की तरह नहीं दिखता है।
हालांकि, अगर हम अभी भी एक बड़े भंडार में काम करते हैं, तो svn: बाहरी भी उपयोगी हो सकते हैं। उदाहरण: मान लीजिए कि हमारी रिपॉजिटरी (ट्रंक में) निम्नलिखित फ़ोल्डर संरचना है: / सामान्य / C # और / OurCustomer / Windows / HelloCSharp /। यदि HelloCSharp परियोजना में हम कॉमन / C # से कोड का उपयोग करना चाहते हैं, तो हमारे पास तीन तरीके हैं:
- HelloCSharp को वांछित कोड कॉपी करें
- रिश्तेदार रास्तों का उपयोग करें
- उदाहरण के लिए, हमारे_सेप्ट्री / ट्रंक / कॉमन / सी # से कोड को लोड करने के लिए एक्सन का उपयोग करें।
दूसरा सामान्य है, लेकिन मामूली खामियों के साथ। उदाहरण के लिए, कॉमन / सी # फोल्डर को ट्रांसफर करते समय, हम HelloCSharp में सभी संबंधित रास्तों को बदलने के लिए बाध्य होंगे। या - साझा फ़ाइलों को देखने के लिए आपको रिपॉजिटरी में फ़ोल्डर्स के चारों ओर जाना होगा।
Svn के माध्यम से तीसरा तरीका: बाहरी सबसे वैचारिक रूप से सही लगता है। हम केवल सामान्य कोड को निर्दिष्ट स्थान पर लोड करते हैं, वास्तव में - बस इसे देखें। एसवीएन के भीतर एक प्रकार का प्रतीकात्मक लिंक।
हमारे रिपॉजिटरी में ओपन-सोर्स कोड का उपयोग करना आसान है।
पहले उदाहरण में क्या वर्णन किया गया था। अगर हम अपने भंडार को पूरा बढ़ावा देना चाहते हैं - तो इसके लायक नहीं। Svn का उपयोग करना: इस उद्देश्य के लिए बाहरी अधिक उपयुक्त होगा।
विपक्ष के बारे में
पेशेवरों को बहुत समझाने के लिए, लेकिन svn के व्यापक परिचय के लिए जल्दी मत करो: अपने खजाने में बाहरी। आइए उन समस्याओं का मूल्यांकन करें जो svn: externals लाता है:
धीमा अपडेट (svn अपडेट)
यदि हम बाहरी निर्भरता का उपयोग करते हैं, तो हम पिछले तेज़ अपडेट के बारे में भूल सकते हैं। प्रत्येक निर्भरता उन्नयन के दौरान कम से कम एक अतिरिक्त HTTP कनेक्शन है। यहां तक कि अगर बाहरी भंडार में कुछ भी नहीं बदला है, तो भी हम इंतजार करेंगे। असली काम के साथ, किसी को यह महसूस होता है कि मामला केवल अतिरिक्त कनेक्शन तक सीमित नहीं है, क्योंकि अपडेट का समय बहुत अधिक बढ़ रहा है।
svn: बाहरी वास्तव में धीमी है। कम से कम तोड़फोड़ के वर्तमान कार्यान्वयन में।
कोड अपने आप काम करना बंद कर सकता है
यदि आप इस रूप में svn: externals का उपयोग करते हैं:
iText https://itext.svn.sourceforge.net/svnroot/itext/trunk
आप कभी भी इस बात की गारंटी नहीं दे सकते हैं कि हमारा पूर्व में चलाया गया कोड अभी भी काम कर रहा है। बाहरी भंडार में कोई भी बदलाव इसे तोड़ सकता है। कोड संकलन करना बंद कर सकता है, या अव्यक्त त्रुटियां दिखाई देंगी, और हमारी किसी भी भागीदारी के बिना।
इस दृष्टिकोण का उपयोग करने के लिए शायद ही सिफारिश की जा सकती है। भले ही बाहरी समान भंडार के भीतर हों। भले ही बाहरी भंडार पर हमारा पूरा नियंत्रण हो। इस दृष्टिकोण के साथ, रिपॉजिटरी का इतिहास अपरिवर्तित रहता है। कुछ संशोधन में वापस आने के बाद, हमें एक अप्रत्याशित परिणाम मिलता है, क्योंकि svn के माध्यम से डाउनलोड किए गए कोड: संशोधन के निर्माण के बाद से बाह्य समय में परिवर्तन हो सकता है। यह बहुत संभावना है कि पहले परेशानी मुक्त कोड बस संकलन नहीं करता है।
हालाँकि, svn: externals को अभी समाप्त न करें, इस समस्या का एक समाधान है - आपको एक बाहरी रिपॉजिटरी में एक विशिष्ट संशोधन को संदर्भित करने की आवश्यकता है, जैसे:
iText –r 247 https://itext.svn.sourceforge.net/svnroot/itext/trunk
अब हमें हमेशा इस संशोधन के लिए कोड का एक विशिष्ट संस्करण मिलेगा। जब हम अपडेट प्राप्त करना चाहते हैं, हम संशोधन नंबर को एक उपयुक्त अपडेट करते हैं और अपडेट डाउनलोड करते हैं। हम जाँचते हैं कि हमारा कोड पहले की तरह संकलित है और काम करता है (हम परीक्षण चलाते हैं)। यदि सब कुछ ठीक है, तो svn: externals में बदलाव करें।
यदि हम जिस सर्वर का उल्लेख कर रहे हैं वह अनुपलब्ध है, तो हम अपग्रेड नहीं कर पाएंगे
यदि कोई बाहरी सर्वर (उदाहरण के लिए, itext.svn.sourceforge.net) अनुपलब्ध है, तो हम या तो नए या पिछले संशोधनों (यदि वहाँ भी बाहरी उपयोग किए जाते हैं) में अपग्रेड नहीं कर पाएंगे।
यदि हम जिस सर्वर का उल्लेख कर रहे हैं, वह स्थानांतरित हो गया है - आपको रिपॉजिटरी को पूरी तरह से संशोधित करने की आवश्यकता है
यदि, निश्चित रूप से, हम चाहते हैं कि सभी पुराने संशोधन चालू रहें, अन्यथा हम वर्तमान संशोधन के लिए केवल परिवर्तनों के लिए खुद को प्रतिबंधित कर सकते हैं। लेकिन यह, एक विनाशकारी रास्ता है।
इस मामले में, भंडार को पूरी तरह से संशोधित करना बहुत मुश्किल नहीं है, आपको यह करना होगा:
- "Svnadmin डंप" का उपयोग करके भंडार को डंप करें
- परिणामी डंप में, समान प्रकार की सभी पंक्तियों को खोजें:
वी 66 iText –r 247 https://itext.svn.sourceforge.net/svnroot/itext/trunk सहारा-छोर
- उनमें रिपॉजिटरी के लिए पथ बदलें और पहली पंक्ति में संख्या को अपडेट करें - यह संपत्ति विवरण में बाइट्स की संख्या है, उदाहरण के लिए:
V 123 iText -r 155 http://new_server.com/svnroot/itext/trunk/ iTextSharp -r 155 http://new_server.com/svnroot/itextsharp/trunk/ सहारा-छोर
यहाँ, स्पष्टता के लिए, मैंने यह स्पष्ट करने के लिए एक दूसरी पंक्ति जोड़ी कि संख्या V की गणना कैसे की जाती है। - हमारे पुराने भंडार को हटा दें और "svadadmin लोड" का उपयोग करके एक नया डंप रोल करें
यदि हम जिस सर्वर से लिंक कर रहे हैं, वह सब कुछ के लिए तोड़फोड़ को बदल दिया है या बस काम करना बंद कर दिया है - सब कुछ चला गया है
दोनों ही मामले बेहद नकारात्मक परिणाम देते हैं - हमारा भंडार पूरी तरह से निष्क्रिय हो जाएगा।
संशोधन के लिए अद्यतन काम करना बंद कर सकता है
उदाहरण: हमारे भंडार में iText फ़ोल्डर पूरी तरह से निहित है। फिर, एक चतुर लेख पढ़ने के बाद, हम svn: externals को लागू करने का निर्णय लेते हैं। हम इसे सफलतापूर्वक लागू करते हैं, यह काम करता है, हर कोई खुश है। हालाँकि, अगर अब हम वर्तमान संशोधन से कुछ पहले वाले रोल को वापस लेना चाहते हैं, तो यह काम नहीं करेगा।
यह इस तथ्य के कारण है कि जब svn: externals स्थापना को वापस रोल किया जाता है, तो लक्ष्य फ़ोल्डर (iText) को भौतिक रूप से हटाया नहीं जाता है। और जब आपको रिपॉजिटरी में एक नियमित ट्रैक किए गए फ़ोल्डर के साथ इसे बदलने की आवश्यकता होती है, तो आपको एक संघर्ष मिलता है जो एसवीएन का वर्तमान संस्करण हल नहीं कर सकता है।
इस मामले में, केवल एक समाधान है - शून्य पुनरीक्षण से दाईं ओर पूर्ण चेकआउट करने के लिए।
किसी अन्य संस्करण नियंत्रण प्रणाली में सही ढंग से माइग्रेट करने में असमर्थता
यदि हम SVN रिपॉजिटरी से रिपॉजिटरी में कोड ट्रांसफर करने का निर्णय लेते हैं, उदाहरण के लिए, Git या Mercurial के लिए, तो svn: externals एक गंभीर बाधा है। तीन समाधान हैं: या तो बिल्कुल खत्म न हों, या इस समस्या को अनदेखा करें और इसे स्थानांतरित करें क्योंकि ऐसा होता है (इस मामले में, पुराने संशोधन काम नहीं करेंगे), या पूरी तरह से svn से छुटकारा पाएं: हाथ से बाह्य।
आखिरी रास्ता कांटेदार है, लेकिन परिणाम इसके लायक है - हमें पूरी तरह से स्वतंत्र भंडार मिलता है जिसे हम कहीं भी आयात कर सकते हैं। Svn से कैसे छुटकारा पाएं: बाहरी रूप से विशेष रूप से भविष्य के लेख के लिए एक विषय है।
निष्कर्ष
Svn का उपयोग करने के लिए: बाहरी या नहीं - हर कोई खुद के लिए फैसला करता है। हमने शुरू में बाहरी निर्भरता के बिना काम किया, फिर जब कई रिपॉजिटरी में परियोजनाओं को विघटित किया, तो हमने सक्रिय रूप से svn: externals का उपयोग करना शुरू कर दिया, लेकिन समय के साथ, हमने महसूस किया कि नुकसान ने फायदे को पछाड़ दिया। अंत में, हमने आम तौर पर मर्क्यूरियल में प्रवास करने का निर्णय लिया, और इसके लिए हमें पूरी तरह से svn: externals से छुटकारा पाना पड़ा।
और अंत में, svn का उपयोग करने के लिए कुछ सुझाव: बाहरी:
- बाहरी रिपॉजिटरी में केवल विशिष्ट संशोधनों के लिंक का उपयोग करें;
- बहुत अधिक बाहरी निर्भरता का उपयोग न करने की कोशिश करें, अन्यथा अपडेट बहुत लंबे समय तक चलेगा;
- Svn का उपयोग करें: केवल एक रूट फ़ोल्डर (उदाहरण के लिए, ट्रंक) के लिए बाहरी, और रिपॉजिटरी में बिखरे हुए कई फ़ोल्डरों के लिए इस संपत्ति को सेट न करें। चूंकि लक्ष्य फ़ोल्डर को रिश्तेदार पथ (उदाहरण के लिए, कॉमन / जावा / iText) का उपयोग करके सेट किया जा सकता है, यह एक जगह में सभी आश्रितों को कई की तुलना में परिभाषित करने के लिए अधिक सुविधाजनक है;
- यदि आप svn स्थापित करते हैं / अपडेट करते हैं: एक फ़ोल्डर के लिए बाह्य - कोड परिवर्तन, चलती फ़ाइलों और अन्य कार्यों के साथ इन परिवर्तनों को न मिलाएं। यह बेहतर है कि सिर्फ svn: एक्सटर्नल प्रॉपर्टी को बदलने के लिए एक अलग कमिट करें। यदि आप किसी दिन पूरी तरह से svn से छुटकारा पाने का फैसला करते हैं तो यह जीवन को बहुत सरल करेगा: बाह्य;
- Svn को बदलने की कोशिश न करें: बाहरी अक्सर, यह बाहरी निर्भरता से छुटकारा पाने पर जीवन को भी सरल करेगा।