मुझे बताया गया है कि सबसे अधिक विकास की दुकानों निम्नलिखित संरचना या कम से कम पास इस के लिए है:एसवीएन रिपोजिटरी संरचना - यह बेहतर क्यों है?
तो:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
तो यह बेहतर या सर्वोत्तम क्यों है? क्या होता है या यदि आप इसे एक और तरीके से करते हैं तो आप किस दिल में आते हैं?
भंडार के आयोजन का इस तरह से:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
सबसे अच्छा है जब अपनी परियोजनाओं को एक दूसरे पर उस जुड़े/निर्भर नहीं हैं। दूसरी तरफ आपके पूरे प्रोजेक्ट सूट को संस्करण बनाना आसान बनाता है। इसलिए यदि आप अक्सर प्रोजेक्ट 1 और प्रोजेक्ट 2 को एक साथ रिलीज़/पैकेज करते हैं, तो उन्हें एक ही शाखा साझा करना सबसे अच्छा होता है।
यदि दूसरी तरफ, आपकी परियोजना बहुत ही कम हो गई है और उन पर काम करने वाली पूरी तरह से अलग टीम हैं, तो आपको अधिकतर समय में उन्हें सभी को जांचने की आवश्यकता नहीं होगी, और इसलिए आप उपर्युक्त विधि का उपयोग कर सकते हैं ।
हमारे पास यही है। यह काम करता है और यह अभी के लिए काफी अच्छा है (क्योंकि हम कभी नहीं जानते कि भविष्य क्या लाएगा) हमारे पास संभावित रूप से अधिक अनुकूल संरचना खोजने के लिए कुछ मूल्यवान समय (और धन) खर्च करने के लिए कोई अनिवार्य कारण नहीं है।
एम
मैं संरचना पर बहस नहीं कर रहा हूं कि यह क्यों सोच रहा है कि इसकी सिफारिश क्यों की जाती है और यदि आप इसे इस तरह से नहीं करते हैं तो आपको क्या नुकसान हो सकता है। – PositiveGuy
ज्यादातर लोग ऐसा करते हैं, क्योंकि यह Subversion book द्वारा अनुशंसा की जाती है।
यहाँ CollabNet सबवर्सन परियोजना के निदेशक से एक अच्छी व्याख्या दी गई है:
अच्छा लिंक, बहुत बहुत धन्यवाद। यह भी बहुत उपयोगी है। – PositiveGuy
हम प्रत्येक परियोजना के लिए एक अलग भंडार रखने के लिए।
हालांकि यह आपको एक परियोजना से दूसरी परियोजना में संस्करण इतिहास फ़ाइलों को प्रतिलिपि बनाने और रखने की अनुमति नहीं देता है, यह प्रोजेक्ट खत्म होने पर आपको एक संपूर्ण भंडार संग्रहित करने में सक्षम बनाता है।
आप इसे क्यों संग्रहित करना चाहते हैं? क्या यह एक सबवर्सन कमांड है? – PositiveGuy
बस स्थान बचाने के लिए, और इसे हर दिन बैक अप लेने के बजाय इसे एक सुरक्षित स्थान पर रखें। – pgb
ट्रंक शाखाएं और टैग सभी एक ही तरीके से कार्य करते हैं। आप उनका उपयोग कैसे करते हैं आप पर निर्भर है।
मैं इस संरचना का उपयोग वर्षों से कर रहा हूं और अभी तक एक ऐसा समय नहीं ढूंढ पाया है जिसकी संरचना मुझे करने के लिए आवश्यक नहीं है।
भंडार संरचना आपकी आवश्यकताओं पर निर्भर करती है। यदि आपकी परियोजनाएं पूरी तरह अलग हैं (उनके बीच कोई निर्भरता नहीं है) तो यह "सरल" भंडार संरचना ठीक है। आप अपने प्रोजेक्ट में निर्भरता है, तो (उदाहरण के लिए कुछ वैश्विक "उपकरण-पुस्तकालयों", साझा कोड) आप एक अलग संरचना की तरह उपयोग करना चाहिए:
trunk
prj_a
prj_b
tags
<YOUR_TAGNAME>
prj_a
prj_b
branches
<YOUR_BRANCHNAME>
prj_a
prj_b
या कुछ और जो अपनी प्रक्रिया के लिए और अधिक समझ में आता है।
स्थानीय ट्रंक/टैग/शाखाओं के साथ सरल संरचना में एकाधिक परियोजनाओं को टैग करने के लिए यह संभव नहीं है (कम से कम एक साफ तरीके से), यदि आपके बीच निर्भरता है।
इसके अलावा अक्सर प्रस्तावित "बहु-भंडार" दृष्टिकोण इस अंतर को भर नहीं पाएगा, तब आप कई रिपॉजिटरीज़ में एकाधिक संशोधन या टैग के साथ बर्बाद हो जाते हैं।
मुख्य समस्या यह है कि एसवीएन में साझा संसाधनों के लिए कोई समर्थन नहीं है और उन्हें टैगिंग/ब्रांचिंग।
यदि आप अपनी रिपोजिटरी संरचना के बारे में सोचते हैं, तो आपको खुद से पूछना चाहिए कि आप अपनी कोड पुस्तकालयों को किस प्रक्रिया में साझा करना चाहते हैं।
जब आप साझा संसाधनों के लिए कोई समर्थन नहीं कहते हैं। मेरे पहले उदाहरण में क्या होगा यदि कोई परियोजना 3 है कि प्रोजेक्ट 1 और प्रोजेक्ट 2 दोनों का अर्थ है कि प्रोजेक्ट 3 में केवल एक समाधान है। – PositiveGuy
वह जगह है जहां सिरदर्द शुरू होता है: आप बाहरी का उपयोग कर सकते हैं, लेकिन टैगिंग या ब्रांचिंग पर सावधान रहना चाहिए, या आप विशेष चेकआउटस्क्रिप्ट का उपयोग कर सकते हैं, हालांकि उन्हें अपने भंडार में कहां स्टोर करना है? मुझे कभी भी एसवीएन में साझा संसाधनों के लिए एक आदर्श समाधान नहीं मिला। हालांकि आप उन्हें तुरंत निपटने का एक तरीका खोज लेंगे। –
ठीक है, मैं थोड़ा और प्रचार करने वाला हूं और एक ट्रंक रखने के पक्ष में मजबूती से नीचे आ गया हूं, प्रत्येक परियोजना के लिए टैग & शाखाएं।
मुख्य विकल्प एक ट्रंक, टैग & शाखाओं के नीचे सभी परियोजनाओं के साथ है। हालांकि, इससे कई समस्याएं होती हैं, जिनमें से एक महत्वपूर्ण है और मैं यहां विस्तार से विवरण दूंगा:
मुख्य रूप से यह अस्पृश्य लाइब्रेरी के रास्ते को आगे बढ़ाता है, जहां हर कोई किसी विशेष पुस्तकालय को छूने के लिए डरता है क्योंकि कोई भी परिवर्तन टूट सकता है कुछ यादृच्छिक परियोजना में कुछ सूक्ष्म। इसका कारण यह है कि परियोजनाओं के बीच कोई अलगाव नहीं है, कोई भी आपके प्रोजेक्ट में कोड को प्रभावी ढंग से बदल सकता है, इसके बिना आप इसे पहचानने या नियंत्रित करने में सक्षम होते हैं।
क्या होता है कि एक दिन आप अपने प्रोजेक्ट की जाँच है और यह, बनाता है अगले दिन आप इसे बाहर की जाँच करें और यह विफल रहता है, लेकिन आप कोई अपनी परियोजना में परिवर्तन कर दिया है। क्या हुआ है कि किसी ने उस लाइब्रेरी को बदल दिया है जिस पर आप निर्भर थे। कई निर्भरताओं के साथ एक बड़ी संरचना में, डेवलपर के लिए प्रत्येक परियोजना के खिलाफ अपने पुस्तकालय परिवर्तनों का परीक्षण करने के लिए अवास्तविक है, खासकर अगर उन्हें तोड़ने में बदलाव करना पड़ता है। आपको अपनी परियोजना में क्या चाहिए पुस्तकालय के एक विशिष्ट संस्करण का संदर्भ है। इस तरह, लाइब्रेरी केवल तब अपडेट हो जाती है जब आप नवीनतम संस्करण में संदर्भ बदलते हैं।
इस प्रकार के संदर्भ में 3 प्रभाव हैं: 1 आपकी परियोजना लाइब्रेरी में यादृच्छिक मध्यवर्ती विकास परिवर्तन से अलग है। 2 आपको अपनी परियोजना में एक संशोधन मिलता है जो आपको बताता है कि "अब मैं लाइब्रेरी के इस संस्करण का उपयोग कर रहा हूं"। 3. लाइब्रेरी में किसी भी ब्रेकिंग बदलाव के लिए जब आप अपनी परियोजना में बदलाव करते हैं तो आप नियंत्रण में आ जाते हैं।
ऐसे अन्य मुद्दे हैं जिन्हें मैं पर्याप्त नहीं कर सकता हूं।
सीवीएस जैसे सिस्टम में, आपने अलग "निर्देशिका" नहीं रखी। आपने अभी टैग किया है और ब्रांच किया है।
हालांकि, एसवीएन स्नैपशॉट के विचार पर अधिक मॉडलिंग किया गया है, और इसलिए सामानों की "प्रतियां" बहुत कुशलता से की जाती हैं। एक परियोजना के विशेष (या वैकल्पिक) संस्करणों को टैगिंग या अन्यथा चिह्नित करने के बजाय, इसकी एक नामित प्रति बनाने के लिए यह आसान (और अधिक कुशल) है।
मेरी दुकान में, हम कुछ इस तरह है:
RepositoryMain
Trunk
proj 1
proj 2
..
Dev
Team1
proj 1
proj 2
Team2
proj 1
proj 2
...
मैं नहीं जानता कि यह कैसे सबसे अधिक स्थानों के लिए को पीछे छोड़ देता है, लेकिन यह बहुत अच्छी
सभी विकास टीमें काम कर सकते हैं काम करने के लिए लगता है अलग-अलग अपनी परियोजनाओं पर, ट्रंक से उनके प्रोजेक्ट में विलय कर रहे हैं जब वे विकास/वृद्धि शुरू कर रहे हैं, और फिर समाप्त होने के बाद ट्रंक में विलय कर रहे हैं।
यह एक दिलचस्प विचार है; यह लगभग एक वितरित स्रोत नियंत्रण प्रणाली की तरह है। –
चर्चा यहाँ के लिए धन्यवाद, मैं इस और project-structure-for-product-with-different-versions
मैं शब्दावलियों भ्रमित कर रहे हैं देख सकते हैं के माध्यम से चला गया। परियोजनाओं, अनुप्रयोग, सही ढंग से
सहसंबंधी कुछ हद तक स्पष्ट exp कहते हैं कि हम एक ग्राहक के लिए समाधान कर एबीसी समाधान एबीसी ग्राहकों के लिए टिकट/HelpDesk आवेदन है क्वेरीज़
कहना चलें चलें साथ ऊपर बातें दोहराने के लिए पसंद करेंगे applicationName OneDesk अनुप्रयोग है। इस आवेदन WebUI, साझा पुस्तकालय के होते हैं, उपकरण
बिल्ड हम इस
XSoftware.com/ABC तरह SVN डिज़ाइन कर सकते हैं - भंडार / ट्रंक/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp शाखाओं/ Branch_Product_Support_1_0_0_0/ OneDeskWebUI OneDeskService OneDeskDBScript OneDeskBatchApp टैग/ OneDeskDocs OneDeskMasterBuild
आपको यहां कुछ अच्छी सामग्री दिखाई देती है, लेकिन यह एक झटके का थोड़ा सा है। – thecoshman
यह सबसे अच्छा अभ्यास है, जो अधिकांश लोगों के लिए काम करने के लिए निकला है। हमारी कंपनी में हम थोड़ा संशोधित संस्करण का उपयोग करते हैं और इससे खुश हैं और इसलिए आपको करना चाहिए। अगर यह आपकी जरूरतों को फिट करता है, ठीक है! यदि नहीं, तो अपनी पसंद की निर्देशिका संरचना करें। – Boldewyn
आप "बेहतर" कहते हैं, लेकिन इससे बेहतर क्या है? –
धन्यवाद सब! अत्यधिक सराहनीय। – PositiveGuy