एक और दृष्टिकोण जो आप ले सकते हैं, सबवर्सन externals प्रॉपर्टी का उपयोग कर अपने कोड को प्रबंधित करने में सक्षम होने के लिए अलग-अलग भंडारों में या एक ही भंडार में उपयोग करने में सक्षम है। लाभ यह है कि जब आप अपने समाधान में साझा कोड की एक नई रिलीज की आवश्यकता होती है तो आप केवल यूआरएल को प्रश्न में अपडेट कर सकते हैं।
नोट: मुझे विजुअल स्टूडियो समाधान और परियोजना संगठन के बारे में जैक याद नहीं है; यह कम से कम 5 साल हो गया है क्योंकि मैंने कोई विंडोज़ विकास किया है। कहा जा रहा है, यह चर्चा लागू है चाहे कोई भी फ़ाइल/निर्देशिका लेआउट क्या हो। मैं एक बनाने जा रहा हूं और कृपया इसे अपनी वास्तविक स्थिति में समायोजित करें।
मान लें कि आपके पास एक बड़ी भंडार है जिसमें आपकी सभी संबंधित परियोजनाएं हैं। यदि आपको लगता है कि यह आवश्यक स्केलेबल नहीं है, तो मैं Apache projects SVN setup पर एक नज़र डालने का सुझाव दूंगा; उनके पास एक ही भंडार में सभी परियोजनाएं हैं। ASF से एक पृष्ठ पर ले रहा है, इस प्रकार के भंडार संरचना बाहर प्रारंभ करते हैं:
/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches
/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches
/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches
/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches
अभी तक यह सिर्फ एक मानक SVN लेआउट है; प्रत्येक कम या कम स्वतंत्र इकाई के पास खेलने के लिए भंडार का अपना क्षेत्र होता है। अब, मान लीजिए कि आप SharedClassLib पर विकास कर रहे हैं और आप संस्करण 2.0.0 तक हैं, और साझा वेब सेवा पर आप संस्करण 1.2.5 पर हैं।
/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0
/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5
अन्य टैग सिर्फ तथ्य यह है कि अपने विकास के समय के साथ पर अग्रसर कर दिया गया है की व्याख्या के लिए हैं और आपके पास कई विज्ञप्ति लिया है: निर्देशिका लेआउट कुछ ऐसी दिखाई देगी।
अब, SolutionA में वापस आ गया है, तो आप एक LocalClassLibrary परियोजना और एक LocalWebApp परियोजना है।इन परियोजनाओं का सख्ती से इस समाधान का हिस्सा इस समाधान के बाहर साझा नहीं किया गया है।
तो, हमारी समस्या है, हम कैसे SharedClassLib और SharedWebService हमारे SolutionA में मिलता है: एक निर्देशिका लेआउट पर एक चाकू ले रहा है, अपने ट्रंक की तरह कुछ लग सकता है? सबवर्जन बाहरी का उपयोग करके। externals वेब पेज पहले पढ़ें, फिर यहां वापस आएं।
अपनी ज़िंदगी को थोड़ा आसान बनाने के लिए, मैं आपके समाधान निर्देशिका में svn.externals फ़ाइल बनाने का सुझाव देता हूं ताकि svn: externals property को सेट किया जा सके यदि आप कमांड लाइन से ऐसा कर रहे हैं। यदि आप किसी अन्य टूल का उपयोग कर रहे हैं, तो बस ध्यान रखें कि इस मामले में, आपको कई लाइनें जोड़ने की आवश्यकता होगी।
SharedClassLib http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService http://your.svn.server/SharedWebService/tags/1.2.5
संपादित करें 1: फ़ाइल की तरह दिखाई देगा इस बिंदु पर, आप देख सकते हैं कि यूआरएल आप बात कर रहे हैं पूरी तरह से योग्य हैं। इसका मतलब है कि वे अलग-अलग भंडार हो सकते हैं, और आपको यहां वर्णित लेआउट का उपयोग करने की आवश्यकता नहीं है। इसके अतिरिक्त, यदि आप अपने विकास में मध्यवर्ती चरण में हैं और आपको अपने साझा कोड के नवीनतम, खून बहने वाले किनारे, विकास संस्करण की आवश्यकता है, तो http://your.svn.server/SharedClassLib/trunk जैसे यूआरएल का उपयोग करें। कुछ बिंदु पर, हालांकि, आप अपने समाधान को टैग करने और रिलीज़ करने से पहले बाहरी कोड के एकबल संस्करण पर बसना चाहते हैं।
संपादित करें 2: ध्यान दें कि यह प्री-1.5 एसवीएन वाक्यविन्यास है। यह 1.5
में अपनी स्थिति निर्देशिका में svn propset svn:externals -F svn.externals . करें, तो svn commit && svn update में थोड़ा सा बदल गया है। इस बिंदु पर svn आपकी कार्यशील प्रति को उन यूआरएल की सामग्री के साथ पॉप्युलेट करेगा। आपका काम कर प्रति कुछ ऐसा दिखाई देगा: उचित रूप से बाहरी संपत्ति:
./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>
जब आप साझा परियोजनाओं के नए संस्करण में, लाने SVN अपडेट करना होगा। कृपया ध्यान दें, इस दृष्टिकोण के लिए कुछ चेतावनी हैं, और एसवीएन बाहरी दस्तावेज में विस्तृत हैं। मुख्य रूप से, ./olution_/SharedClassLibrary में परिवर्तन करने में सक्षम होने की योजना न बनाएं और जब आप समाधान ए में प्रतिबद्ध करते हैं तो परिवर्तनों को जादुई रूप से उठाया जाना चाहिए।
अब आप दुनिया में समाधान ए रिलीज़ करने के लिए तैयार हैं। बस उपयुक्त टैग ट्रंक की (SVN प्रतिलिपि) टैग निर्देशिका बनाएं:
/SolutionA/tags/1.0.0
अब आप अपने SolutionA यह सही टैग/संस्करण में अपने कोड है होगा, और आप साझा परियोजनाओं का सही संस्करण का उपयोग कर रहे उस रिलीज के लिए।
जाहिर है, वही चर्चा SolutionB पर लागू होती है।
मैंने थोड़ी देर में एसवीएन के साथ काम नहीं किया है, इसलिए माफी माँगती है अगर मुझे ऊपर से कोई भी गलत गलती मिल गई है।
लेकिन जब मैं अपनी साझा डीएल परियोजनाओं में नई विशेषताएं जोड़ता हूं, जो अन्य परियोजना आवश्यकताओं को विकसित करते समय समाधान से अलग होते हैं (इसकी खुद की भंडार है), बाकी मुख्य परियोजनाओं में नई विशेषताएं नहीं होंगी। मैं प्रत्येक परियोजना को अद्यतन करना चाहता हूं लेकिन मुख्य परियोजनाओं के साथ संगत हूं। – uzay95
दरअसल, यह एक मुद्दा है यदि निर्भर परियोजनाएं एक और भंडार में हैं। क्या इन परियोजनाओं को एक ही रेपो में आप उन्हें एक साथ टैग कर सकते थे। मेरा उत्तर इस सिफारिश पर आधारित है कि आपकी सभी संबंधित परियोजनाएं एक ही भंडार के भीतर होंगी। यदि यह संभव नहीं है, तो ऐसा करने का एक स्वीकार्य तरीका हो सकता है, जैसे svn: extern (देखें: http://svnbook.red-bean.com/en/1.0/ch07s03 का उपयोग करना।एचटीएमएल) लेकिन हालांकि मैं इसके साथ सीधे अनुभव नहीं कर रहा हूं, यह मेरी धारणा है कि यह ऐसा कुछ है जिसे केवल आवश्यकता के अनुसार उपयोग किया जाना चाहिए। – Derrick