एकाधिक परियोजनाओं में सबवर्जन संशोधन संख्या

Question

कई परियोजनाओं के साथ स्रोत नियंत्रण के लिए सबवर्जन (svn) का उपयोग करते समय मैंने देखा है कि मेरी सभी परियोजनाओं की निर्देशिका में संशोधन संख्या बढ़ जाती है। मेरी SVN लेआउट उदाहरण देकर स्पष्ट करने (काल्पनिक परियोजना नाम का उपयोग):

 
    /NinjaProg/branches 
       /tags 
       /trunk 
    /StealthApp/branches 
       /tags 
       /trunk 
    /SnailApp/branches 
      /tags 
      /trunk 

जब मैं प्रदर्शन एक निंजा कार्यक्रम के ट्रंक के लिए प्रतिबद्ध, मान लें कि मुझे लगता है कि यह संशोधन 7. करने के लिए अद्यतन किया गया है प्राप्त अगले दिन मान लें कि चलो कि मैं चुपके आवेदन में एक छोटा सा परिवर्तन करता हूं और यह संशोधन 8 के रूप में वापस आता है।

प्रश्न यह है: क्या यह एक सामान्य स्वीकार्य अभ्यास है, जब एक सबवर्जन सर्वर के साथ कई परियोजनाओं को बनाए रखने के लिए, असंबंधित परियोजनाओं के संशोधन के लिए सभी परियोजनाओं में संख्या में वृद्धि? या क्या मैं इसे गलत कर रहा हूं और प्रत्येक परियोजना के लिए व्यक्तिगत भंडार बनाना चाहिए? या यह पूरी तरह से कुछ और है?

संपादित करें: मैं एक जवाब पर चिह्नित करने में देरी हो रही है क्योंकि यह स्पष्ट हो गया था वहाँ दोनों दृष्टिकोण के लिए कारण हैं, और फिर भी यह सवाल पहले आया था, मैं कुछ अन्य प्रश्न है कि अंततः पूछ रहे हैं को इंगित करना चाहते हैं कि एक ही प्रश्न:

Should I store all projects in one repository or mulitiple?

One SVN Repository or many?

Answer 1

मुझे आश्चर्य है कि कोई भी उल्लेख नहीं किया गया है कि इस पर सबवर्सन के साथ संस्करण नियंत्रण में चर्चा की गई है, जो मुफ्त ऑनलाइन, here उपलब्ध है।

मैं थोड़ी देर पहले इस मुद्दे पर पढ़ता हूं और यह वास्तव में व्यक्तिगत पसंद के मामले की तरह लगता है, इस विषय पर here विषय पर एक अच्छा ब्लॉग पोस्ट है। संपादित करें: चूंकि ब्लॉग नीचे दिखाई देता है, (archived version here), यहां कुछ विषय है जो मार्क फिपार्ड को इस विषय पर कहना था।

ये एकल भंडार दृष्टिकोण के कुछ फायदे हैं।

1. सरलीकृत प्रशासन। तैनात करने के लिए हुक का एक सेट। बैकअप के लिए एक भंडार। आदि
2. शाखा/टैग लचीलापन। सभी एक संग्रह में कोड के साथ यह कई परियोजनाओं को शामिल करने वाली शाखा या टैग बनाना आसान बनाता है।
3. आसानी से कोड ले जाएं। शायद आप एक प्रोजेक्ट से कोड का एक सेक्शन लेना चाहते हैं और इसे दूसरे में इस्तेमाल करना चाहते हैं, या इसे कई परियोजनाओं के लिए लाइब्रेरी में बदलना चाहते हैं। कोड को उसी भंडार में स्थानांतरित करना और प्रक्रिया में कोड का इतिहास बनाए रखना आसान है।

यहां एक ही भंडार दृष्टिकोण के कुछ दोष हैं, एकाधिक भंडार दृष्टिकोण के फायदे हैं।

1. आकार। एक बड़े से अधिक छोटी भंडारों से निपटना आसान हो सकता है। उदाहरण के लिए, यदि आप किसी प्रोजेक्ट को सेवानिवृत्त करते हैं तो आप केवल मीडिया को रिपोजिटरी संग्रहित कर सकते हैं और डिस्क से इसे हटा सकते हैं और स्टोरेज को खाली कर सकते हैं। हो सकता है कि आपको कुछ कारणों से एक संग्रह को डंप/लोड करना होगा, जैसे कि एक नई सबवर्जन सुविधा का लाभ उठाना। यह करना आसान है और कम प्रभाव के साथ यदि यह एक छोटा भंडार है। यहां तक ​​कि यदि आप अंततः अपने सभी भंडारों में ऐसा करना चाहते हैं, तो एक समय में उन्हें एक-एक करके करने के लिए इसका असर कम होगा, मान लीजिए कि उन्हें एक साथ करने की कोई दिक्कत नहीं है।
2. वैश्विक संशोधन संख्या। हालांकि यह कोई मुद्दा नहीं होना चाहिए, कुछ लोग इसे एक मानते हैं और भंडार पर संशोधन संख्या अग्रिम और निष्क्रिय परियोजनाओं के लिए उनके संशोधन इतिहास में बड़े अंतर को देखना पसंद नहीं करते हैं।
3. एक्सेस नियंत्रण। जबकि सबवर्जन की ऑथज़ तंत्र आपको भंडार के कुछ हिस्सों में आवश्यक पहुंच को प्रतिबंधित करने की अनुमति देता है, फिर भी इसे भंडार स्तर पर करना आसान है। यदि आपके पास एक प्रोजेक्ट है जो केवल कुछ चुनिंदा व्यक्तियों तक पहुंच लेना चाहिए, तो उस परियोजना के लिए एक ही भंडार के साथ करना आसान है।
4. प्रशासनिक लचीलापन। यदि आपके पास एकाधिक भंडार हैं, तो भंडार/परियोजनाओं की आवश्यकताओं के आधार पर विभिन्न हुक स्क्रिप्ट को कार्यान्वित करना आसान है। आप वर्दी हुक लिपियों चाहते हैं, तो एक भी रिपोजिटरी बेहतर हो सकता है, लेकिन अगर प्रत्येक परियोजना तो अपने स्वयं के लिए प्रतिबद्ध ईमेल शैली चाहता है यह अलग खजाने

तुम सच के बारे में सोचना जब में उन परियोजनाओं के लिए आसान है, एक से अधिक परियोजना भंडार में संशोधन संख्या अधिक हो रही है, लेकिन आप बाहर नहीं जा रहे हैं। ध्यान रखें कि आप एक उप निर्देशिका पर एक इतिहास देख सकते हैं और एक परियोजना से संबंधित सभी संशोधन संख्याओं को तुरंत देख सकते हैं।

Answer 2

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

Answer 3

मैं प्रति परियोजना एक प्रोजेक्ट स्टोर करता हूं, और पिछले commenter की तरह इस subversion question पर, मैं साझा परियोजनाओं को बाहरी के रूप में चिह्नित करता हूं, ताकि वे केवल एक बार स्रोत नियंत्रण में हों।

मैं बस एक सीआई बिल्ड सर्वर (क्रूज़ कंट्रोल.नेट) जोड़ना शुरू कर रहा हूं, इसलिए मुझे यह देखना होगा कि यह सब कैसे काम करता है, लेकिन अगर मेरी बिल्ड स्क्रिप्ट सही हैं तो यह कोई समस्या नहीं होनी चाहिए।

हालांकि उपस्थिति के अलावा, यह वास्तव में वरीयता का विषय है (मेरी राय में)।

Answer 4

संशोधन संख्या वास्तव में केवल एक विशेष संस्करण के लिए पहचानकर्ता होना चाहिए। चाहे यह किसी परियोजना के लिए अनुक्रमिक हो या इससे कोई फर्क नहीं पड़ता। कहा जा रहा है, मैं समझ सकता हूं कि यह आदर्श से कम है।

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

Answer 5

मुझे लगता है कि यह अत्यधिक अनुशंसा की जाती है कि आप प्रत्येक परियोजना के लिए अलग-अलग भंडार तैयार करें। यदि परिदृश्य से बचने के अलावा आप कुछ भी नहीं कर रहे हैं तो आप इसके बारे में बात कर रहे हैं।

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

इसके अलावा, यदि आप चिंतित हैं कि प्रत्येक रिपोजिटरी को अपाचे कॉन्फ़िगरेशन फ़ाइल के लिए SVNParentPath चर में सेट करने में काफी समय लगेगा। (फिर से, मुझे लगता है कि आप अपाचे का उपयोग कर रहे हैं।)

Answer 6

प्रति परियोजना अलग भंडार का उपयोग करने के लिए अनुशंसित।

<Location /svn> 
    DAV svn 
    SVNParentPath /var/www/svn 

    AuthType Basic 
    AuthName "Subversion Repository" 
    AuthUserFile /var/www/svn/password 
    Require valid-user 
</Location> 

इसके बाद जब भी मैं मैं सिर्फ चलाने एक नई परियोजना शुरू: परियोजना प्रति

svnadmin create /var/www/svn/myproject 

Answer 7

एक भंडार मेरी अपाचे conf.d निर्देशिका में मैं subversion.conf कि शामिल है।

सीसी.NET के बारे में स्टीवन मुरावस्की की टिप्पणी एक दिलचस्प है। अगर आपको कई स्रोत नियंत्रण भंडार निर्दिष्ट करने की आवश्यकता है तो मुझे यह जानने में दिलचस्पी होगी कि यह कैसे काम करता है।

Answer 8

यदि अन्य परियोजनाओं के आधार पर संशोधन संख्या परिवर्तन आपको परेशान करते हैं, तो परियोजनाओं को अलग-अलग भंडारों में रखें। संशोधन संख्या स्वतंत्र बनाने का यही एकमात्र तरीका है।

मेरे लिए, विभिन्न भंडारों का उपयोग करने का बड़ा कारण उपयोगकर्ताओं के लिए अलग-अलग पहुंच नियंत्रण प्रदान करना है और/या विभिन्न हुक स्क्रिप्ट का उपयोग करना है।

Answer 9

एचएम, जहां मैं काम करता हूं, हमारे पास हमारी सभी परियोजनाएं एक ही भंडार में हैं। मुझे वास्तव में उन्हें अलग करने का लाभ नहीं दिखता है, क्या यह सिर्फ बहुत अधिक काम नहीं करता है- नए भंडार तैयार करना, लोगों तक पहुंच प्रदान करना आदि? मुझे लगता है कि परियोजनाओं को पूरी तरह से असंबंधित होने पर अलग-अलग भंडारों को समझ में आता है, और आपके पास, बाहरी ग्राहकों को रेपो तक पहुंच की आवश्यकता है।

Answer 10

मेरे कार्यस्थल पर, हमारे पास दो भंडार हैं। एक सार्वजनिक पढ़ने के उपयोग के साथ, और सब कुछ के लिए एक। मैं सब कुछ के लिए सिर्फ एक का उपयोग करता हूं, लेकिन हमें सार्वजनिक/निजी परियोजनाओं के लिए अलग-अलग पहुंच अधिकारों की आवश्यकता है।

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

Answer 11

@ डैनियल फोन: एसवीएन दस्तावेज़ प्रति प्रोजेक्टरी की एक परियोजना की सिफारिश करते हैं, इसलिए निश्चित रूप से रचनाकारों ने इसे जाने का इरादा किया है। चूंकि आपके पास एक सर्वर (अपाचे या svnserve) एकाधिक रिपॉजिटरीज बनाए रख सकता है, इसलिए मैंने कभी भी बहुत अधिक ओवरहेड की समस्या में भाग नहीं लिया है। VisualSVN Server के साथ, एक अपाचे सर्वर स्थापित करना और एकाधिक भंडारों को कॉन्फ़िगर करना एक स्नैप है।

Answer 12

मुझे यकीन नहीं है कि एसवीएन दस्तावेज़ वास्तव में एक प्रति प्रोजेक्टरी की एक परियोजना की अनुशंसा करते हैं। ज्यादातर वे प्रत्येक पथ के upsides और downsides के बारे में बात करते हैं। मैं तीन अलग-अलग रिपॉजिटरीज का उपयोग करता हूं, जो कि 7 या 8 परियोजनाओं में से एक है, जो सभी संबंधित हैं, जिससे सभी परियोजनाओं की संगत प्रतियां केवल एक संशोधन से बनाकर (या सत्यापित कर रहे हैं कि वे देखकर संगत हैं प्रत्येक पर संशोधन संख्या पर)। दूसरे भंडार में संबंधित परियोजनाओं और दस्तावेजों का एक और समूह है, जबकि तीसरा एक छोटा सा है। इससे हमें इस तथ्य का लाभ उठाने की सुविधा मिलती है कि संबंधित परियोजनाओं को एक संशोधन संख्या द्वारा प्रबंधित किया जा सकता है, लेकिन असंबंधित परियोजनाएं उनके भंडार को प्रभावित नहीं करती हैं।

Answer 13

हमारे पास बस इसमें सब कुछ के साथ एक भंडार है, बिल्कुल आपके उदाहरण की तरह।

मैं कुछ भी इस के साथ गलत नहीं देख सकते हैं - संशोधन संख्या के लिए केवल आवश्यकता है कि यह

• अनोखा
• परमाणु
• बड़ा की तुलना में यह पिछले चेकइन पर था है

इससे कोई फर्क नहीं पड़ता कि यह प्रत्येक प्रतिबद्धता के साथ 1 या 50 तक बढ़ता है, जहां तक ​​मेरा संबंध है।

@grom:

इसके बाद जब भी मैं एक नई परियोजना शुरू मैं सिर्फ चलाएँ:

svnadmin create /var/www/svn/myproject

मैं इस ठीक काम कर रहा देख सकते हैं अगर आप केवल मिल गया है 1 या 2 देवता, लेकिन क्या होता है यदि नई परियोजनाएं बनाने वाले लोग एसवीएन सर्वर पर/var/www के अंतर्गत निर्देशिका बनाने में सक्षम होने के लिए खोल पहुंच नहीं रखते हैं?

Answer 14

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

Answer 15

मेरी पिछली कंपनी में एक ही समस्या थी, तो वे एक रिपोजिटरी में चल रही 50 परियोजनाओं का उपयोग करते थे और यह उसी परियोजनाओं पर काम करने का दुःस्वप्न था क्योंकि एसवीएन अपडेट करते समय दूसरों को शाप दिया जाएगा .... lol। ..

एक बात मैंने सीखा है कि हमेशा बेहतरीन काम करता है, एक प्रोजेक्ट वन रेपो .... आप इसे कभी पछतावा नहीं करेंगे।

Answer 16

शायद यह "प्रोजेक्ट" प्रति एक रेपो बनाने के लिए सबसे अच्छा नहीं है, बल्कि "समाधान" प्रति एक रेपो (विजुअल स्टूडियो शर्तों का उपयोग करने के लिए)। यदि आपके पास अलग-अलग फ़ोल्डर्स में "प्रोजेक्ट्स" का समूह है लेकिन वे एक दूसरे से संबंधित हैं, तो उन्हें एक ही रेपो में रखें।

Answer 17

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

असल में यदि आपका माइक्रोसॉफ्ट कोड बिल्डिंग है, और आप अपने संस्करण स्ट्रिंग के हिस्से के रूप में svn संशोधन संख्या का उपयोग करते हैं तो आप बाहर निकल सकते हैं। यदि संस्करण स्ट्रिंग का कोई भी हिस्सा 65535 से अधिक है तो माइक्रोसॉफ्ट कंपाइलर एक त्रुटि फेंक देगा .... हमारे मामले में हमारे पास संशोधन 68876 पर भारी भंडार है और हमने अभी इस दीवार को मारा है।