एक SVN रिपॉजिटरी या कई?

106

यदि आपके पास कई, असंबंधित परियोजनाएं हैं, तो क्या उन्हें एक ही भंडार में रखना एक अच्छा विचार है?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

या आप प्रत्येक के लिए नए रिपॉजिटरी बनाएंगे?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

प्रत्येक का भला - बुरा क्या है? यह सब मैं वर्तमान में सोच सकता हूं कि आपको मिश्रित संशोधन संख्या मिलती है (इसलिए क्या?), और यह कि आप svn:externalsतब तक उपयोग नहीं कर सकते जब तक कि भंडार वास्तव में बाहरी न हो। (मुझे लगता है?)

मेरे पूछने का कारण यह है कि मैं अपने कई रिपोज को एक में समेकित करने पर विचार कर रहा हूं, क्योंकि मेरे एसवीएन होस्ट ने प्रति रेपो चार्ज करना शुरू कर दिया है।

svn

— nickf
स्रोत

3

मैंने कुछ समय पहले भी यही सवाल पूछा था, इसलिए अगर आपको और मदद की ज़रूरत है तो यहाँ कुछ हो सकता है: stackoverflow.com/questions/130447/…

— नाथन डब्ल्यू

1

ओह डेमिटी - इसके बाद डूप के लिए खेद है। मैंने खोज की कोशिश की, मैं कसम खाता हूँ!

— 4

नहीं probs :) मैं ही नहीं, यह इतना उल्लेख चिंतित हूँ अगर तुम नहीं मिला मदद तुम यहाँ की जरूरत तो मेरे क्यू में कुछ और अधिक मदद की वहाँ गया हो सकता है

— नाथन डब्ल्यू

1

nickf, svn: बाहरी एक बड़े भंडार के साथ ठीक काम करते हैं। आप बस उस कोड के साथ रेपो में उपनिर्देशिका को इंगित करते हैं जिसमें आप रुचि रखते हैं।

— बेन गार्टनर

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

— फेटी

77

एकल बनाम एकाधिक समस्या व्यक्तिगत या संगठनात्मक वरीयता के लिए नीचे आती है।

कई बनाम एकल का प्रबंधन मुख्य रूप से नियंत्रण और रखरखाव तक पहुंचने के लिए नीचे आता है।

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

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

मैंने हाल ही में तोड़फोड़ के लिए कई स्रोत कोड नियंत्रण प्रणालियों को स्थानांतरित करने पर एक अपेक्षाकृत बड़ी फर्म के साथ परामर्श किया। उनके पास ~ 50 परियोजनाएं हैं, जो बहुत छोटे से लेकर उद्यम अनुप्रयोगों और उनकी कॉर्पोरेट वेबसाइट तक हैं। उनकी योजना? एकल रिपॉजिटरी से शुरू करें, यदि आवश्यक हो तो कई में माइग्रेट करें। माइग्रेशन लगभग पूरा हो गया है और वे अभी भी एक एकल रिपॉजिटरी पर हैं, कोई भी शिकायत या समस्या एकल रिपॉजिटरी होने के कारण रिपोर्ट नहीं की गई।

यह एक बाइनरी, ब्लैक एंड व्हाइट मुद्दा नहीं है।

आपके लिए क्या काम करता है - क्या मैं आपकी स्थिति में था, मैं परियोजनाओं को एक एकल रिपॉजिटरी में जोड़ देता था जितनी जल्दी मैं कमांड टाइप कर सकता था, क्योंकि लागत मेरी (बहुत, बहुत छोटी) कंपनी में एक प्रमुख विचार होगा।

JFTR:

तोड़फोड़ में संशोधन संख्या वास्तव में भंडार के बाहर कोई मतलब नहीं है। यदि आपको संशोधन के लिए सार्थक नामों की आवश्यकता है, तो एक TAG बनाएं

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

संपादित करें: SVN के लिए एकल प्राधिकरण / प्रमाणीकरण कॉन्फ़िगरेशन का उपयोग करने के विवरण के लिए ब्लेड की प्रतिक्रिया देखें ।

— केन जेंटल
स्रोत

1

"[...] के लिए अभिगम नियंत्रण [कई रिपॉजिटरी के लिए एक से अधिक फ़ाइलों की आवश्यकता होने वाली है" कई रिपोज एक ही एक्सेस प्रतिबंध फ़ाइल को इंगित कर सकते हैं। नीचे मेरा जवाब देखें।

— फ्रेडरिक मोरिन

हाय केन, क्या आप एक-रिपॉजिटरी-मल्टीपल-प्रोजेक्ट सेटअप में जाँच और ब्रांचिंग की प्रक्रिया पर आगे टिप्पणी करना चाहेंगे? अब मैं एक ऐसी कंपनी के साथ काम कर रहा हूं, जिसके पास एक रिपॉजिटरी में कई प्रोजेक्ट्स हैं, जिनमें से प्रत्येक का अपना / प्रोजेक्ट / <ट्रंक> <ब्रांच> <टैग> फोल्डर सिस्टम है। लेकिन इंजीनियरों ने रूट डाइरेक्टरी से एक बार में सभी प्रोजेक्ट्स की जाँच की: ब्रांचिंग और

— रिविजन

25

आपके विशिष्ट मामले के लिए एक (1) रिपॉजिटरी एकदम सही है। आप बहुत सारा पैसा बचा लेंगे। मैं हमेशा लोगों को एक एकल भंडार का उपयोग करने के लिए प्रोत्साहित करता हूं। क्योंकि यह एकल फाइलसिस्टम के समान है: यह आसान है

आपके पास एक ही स्थान होगा जहाँ आप कोड की तलाश करेंगे
आपके पास एक ही प्राधिकरण होगा
आपके पास एक एकल प्रतिबद्ध संख्या होगी (कभी भी एक परियोजना बनाने की कोशिश की जाएगी जो 3 रिपोज में फैली हुई है?)
आप आम पुस्तकालयों का बेहतर उपयोग कर सकते हैं और इन कामों में अपनी प्रगति को ट्रैक कर सकते हैं (svn: बाह्य पीटीए हैं और सभी कुछ नहीं करेंगे)
पूरी तरह से अलग-अलग मदों के रूप में योजना बनाई गई परियोजनाएं एक साथ बढ़ सकती हैं और कार्यों और इंटरफेस को साझा कर सकती हैं। यह कई रिपॉजिट में हासिल करना बहुत मुश्किल होगा।

कई रिपॉजिटरी के लिए एक ही बिंदु है: विशाल रेपो का प्रशासन असुविधाजनक है। विशाल रिपोज को डंपिंग / लोड करने में बहुत समय लगता है। लेकिन जैसा कि आप कोई प्रशासन नहीं करते हैं, मुझे लगता है कि यह आपकी चिंता नहीं होगी;)

एसवीएन बड़े रिपोजिटरी के साथ बहुत अच्छी तरह से स्केल करता है, विशाल (> 100 जीबी) रिपॉजिटरी पर भी कोई मंदी नहीं है।

तो आपको एकल भंडार के साथ कम परेशानी होगी। लेकिन आपको वास्तव में रेपो लेआउट के बारे में सोचना चाहिए!

— पीटर पार्कर
स्रोत

2

कई प्रतिनिधि! = कई प्राधिकरण। यदि आप svn + ssh, और निजी-कुंजी-प्रमाणीकरण का उपयोग करते हैं, तो एक ही होस्ट पर कई रिपोज़ दर्द रहित होते हैं।

— मैथ्यू Schinckel

1

मैंने कहा "सिंगल रिपॉज == सिंगल ऑथराइजेशन" निस्संदेह "मल्टीपल रिपॉज == मल्टीपल ऑथराइजेशन" नहीं है जैसा कि आप सुझाव देते हैं।

— पीटर पार्कर

1

तकनीकी होने के नाते, "मल्टीपल रिपोज! = मल्टीपल ऑथराइजेशन" कहना जरूरी नहीं है कि आपका मतलब वही है। वह अन्य उपयोगकर्ताओं के लाभ के लिए स्पष्ट हो सकता है

— केसबश

ऐसी कुछ समस्याएं हैं जो svn: externals हल नहीं करती हैं?

— क्लिंट पाच

1

@Gusdor, आप सही हैं, लेकिन अधिकांश उपयोगकर्ता इस तथ्य से अनजान हैं और SVN को दोष देते हुए यह गलत संस्करण कर रहा है (जबकि, जैसा कि आपने कहा कि वे विकास को गलत कर रहे हैं)। और हाँ आप सही हैं, आप खूंटी के चक्कर का उपयोग कर सकते हैं, लेकिन वास्तव में: एसवीएन-टीम में कितने लोग खूंटी-संशोधन को समझते हैं?

— पीटर पार्कर

7

मैं कई रिपोजिटरी का उपयोग करूंगा। उपयोगकर्ता पहुँच समस्या के अतिरिक्त, यह बैकअप भी बनाता है और पुनर्स्थापना को आसान बनाता है। और यदि आप अपने आप को उस स्थिति में पाते हैं जहाँ कोई आपको अपने कोड (और उसके इतिहास) के लिए भुगतान करना चाहता है, तो उन्हें सिर्फ एक रिपॉजिटरी डंप देना आसान है।

मेरा सुझाव है कि सिर्फ अपने होस्टिंग प्रदाता की चार्जिंग नीतियों के कारण रिपॉजिटरी को समेकित करना एक बहुत अच्छा कारण नहीं है।

— ग्रेग हेविल
स्रोत

हाँ कई मल्टीपल!

— cfeduke

3

आप अपने रिपॉजिटरी डंप को किसी भी पथ में / बाहर कर सकते हैं और किसी भी पथ आधारित जानकारी को अलग कर सकते हैं। तो यह वास्तव में एक मुद्दा नहीं है।

— पीटर पार्कर

जब आप किसी को कोड के लिए भुगतान करना चाहते हैं तो आप रिपॉजिटरी के एक उप-केंद्र तक पहुंच स्थापित कर सकते हैं।

— सैंडर रिजकेन

7

हम एक एकल भंडार का उपयोग करते हैं। मेरी एकमात्र चिंता पैमाना थी, लेकिन ASF की रिपॉजिटरी (700k रिविजन और काउंटिंग) देखने के बाद मुझे पूरा यकीन था कि प्रदर्शन कोई मुद्दा नहीं होगा।

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

— मार्क रेनॉफ
स्रोत

7

ध्यान रखें कि अपना निर्णय लेते समय , कई एसवीएन रिपॉज़ वही कॉन्फ़िगरेशन फ़ाइल साझा कर सकते हैं।

उदाहरण (ऊपर लिंक से लिया गया):

खोल में:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

फ़ाइल: /var/svn/repos1/conf/svnerve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

फ़ाइल: / var / svn / conf / Cortz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

— फ्रेडरिक मोरिन
स्रोत

जब आप सही हैं कि प्राधिकरण / प्रमाणीकरण फ़ाइलों का एक सेट एकाधिक रिपॉजिटरी के लिए उपयोग किया जा सकता है, तो ऐसा करना प्राथमिकता का विषय है। मैं आपके उत्तर को दर्शाने के लिए अपनी पोस्ट अपडेट करूंगा। मुझे "गलत" थोड़ा भड़काऊ लगता है।

— केन जेंटल

1

मुझे नहीं पता कि अब से पहले यह कैसे करना है। धन्यवाद।

— हार्वे

5

मैं अलग रिपोजिटरी बनाऊंगा ... क्यों? रिवीजन नंबर और कमिट मैसेज का कोई मतलब नहीं होगा अगर आपके पास केवल एक रिपॉजिटरी में बहुत सारे असंबंधित प्रोजेक्ट हैं, तो यह निश्चित रूप से शॉर्ट टर्म में एक बड़ी गड़बड़ी होगी।

— सीएमएस
स्रोत

5

कोई समस्या नहीं है यदि आप उचित परियोजना फ़ोल्डर में देखते हैं तो आपको केवल कमिटमेंट मिलेंगे जो इस परियोजना के लिए प्रतिबद्ध थे

— पीटर पार्कर

हां, आप ऐसा कर सकते हैं, लेकिन व्यक्तिगत रूप से मुझे लगता है कि एक बड़ी रिपॉजिटरी को बनाए रखना अधिक कठिन है, उपयोगकर्ता अधिकारों का प्रबंधन, बैकअप नंबर, इत्यादि का प्रबंधन करना, यह आपकी टीम की जरूरतों पर निर्भर है, एसवीएन तराजू वास्तव में अच्छा है यदि आपने एक बड़े रेपो का उपयोग करना चुना है ...

— सीएमएस

3

एक रिपॉजिटरी का बैकअप लेना मेरे लिए 20 का समर्थन करने से आसान है। एक साइड नोट के रूप में, रिपॉजिटरी का बैकअप लेने का एक अच्छा तरीका यह है कि svnsync का उपयोग करके केवल-पढ़ने के लिए प्रतिलिपि बनाई जाए

— Sander Rijken

5

हम एक छोटी सी सॉफ्टवेयर कंपनी हैं और हम अपने सभी विकास के लिए एक ही रेपो का उपयोग करते हैं। पेड़ इस तरह दिखता है:

/client/<clientname>/<project>/<trunk, branches, tags>

यह विचार था कि हमारे पास एक ही रेपो में ग्राहक और आंतरिक कार्य होंगे, लेकिन हमने अपनी कंपनी को स्वयं के "ग्राहक" के रूप में समाप्त कर दिया।

यह हमारे लिए वास्तव में अच्छी तरह से काम किया है, और हम इसे इंटरफ़ेस करने के लिए Trac का उपयोग करते हैं। संशोधन संख्या पूरे रेपो में हैं और एक परियोजना के लिए विशिष्ट नहीं है, लेकिन यह हमें चरणबद्ध नहीं करता है।

— mlambie
स्रोत

4

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

हालांकि वास्तव में, आपको सिर्फ git का उपयोग करना चाहिए;)

— पॉल विक्स
स्रोत

4

एक अतिरिक्त बात पर विचार करने के लिए तथ्य यह है कि कई रिपॉजिटरी का उपयोग करने से आप एकीकृत लॉगिंग (svn लॉग कमांड) की क्षमता को ढीला कर सकते हैं यह अकेले एकल रिपॉजिटरी चुनने का अच्छा कारण होगा।

मैं TortuiseSvn का उपयोग करता हूं और पाया कि "शो लॉग" विकल्प एक अनिवार्य उपकरण है। यद्यपि आपकी परियोजनाएँ असंबंधित हैं, मुझे यकीन है कि आप पाएंगे कि एक केंद्रीकृत वैश्विक क्रॉस-प्रोजेक्ट जानकारी (पथ, बग आईडी, संदेश और इतने पर ....) हमेशा उपयोगी होती है।

— Ofer
स्रोत

2

यदि आप trac wich जैसे टूल का उपयोग या उपयोग करने की योजना बना रहे हैं, जो SVN के साथ एकीकृत है, तो यह प्रति प्रोजेक्ट एक रेपो का उपयोग करने के लिए अधिक समझ में आता है।

— फ्रेडरिक मोरिन
स्रोत

2

फ़ाइलों को साझा करने के बारे में ब्लेड के सुझाव के समान, यहां थोड़ा आसान है, फिर भी कम लचीला समाधान है। मैंने हमारा सेटअप ऐसा किया:

/ Var / SVN /
/ Var / SVN / bin
/ Var / SVN / repository_files
/ Var / SVN / svnroot
/ Var / SVN / svnroot / repos1
/ Var / SVN / svnroot / repos2
...

"बिन" में, मैं svn-create.sh नामक एक स्क्रिप्ट रखता हूं, जो एक खाली रिपॉजिटरी बनाने के सेटअप के सभी काम करेगा। मैं वहां बैकअप स्क्रिप्ट भी रखता हूं।

"रिपॉजिटरी_फाइल्स" में, मैं सामान्य "कॉन्फिडेंस" और "हुक" डायरेक्टरीज़ रखता हूं, जो सभी रिपॉजिटरी को पसंद हैं। उसके बाद, फ़ाइलों का केवल एक सेट है। यह लिंक को तोड़ने के बिना दानेदार, प्रति-परियोजना पहुंच की क्षमता को समाप्त करता है, हालांकि। यह चिंता का विषय नहीं था कि मैंने इसे कहां स्थापित किया।

अंत में, मैं svnroot में सब कुछ अनदेखा करते हुए मुख्य निर्देशिका / var / svn को स्रोत नियंत्रण में रखता हूं। इस तरह से रिपॉजिटरी फाइलें और स्क्रिप्ट स्रोत नियंत्रण में भी हैं।

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

— हार्वे
स्रोत

2

एक एकल रेपो का उपयोग करने के लिए mlambie के समान है, लेकिन विशेष रूप से विशेष प्रकार की परियोजनाओं को आसानी से ज़ूम करने के लिए फ़ोल्डर संरचना के साथ थोड़ा आगे बढ़ गया - वेब HTML आधारित परियोजनाएं बनाम सीएस (सी #) बनाम एसक्यूएल (एसक्यूएल क्रिएट / स्क्रिप्ट निष्पादित) बनाम xyz ( डोमेन विशिष्ट भाषाएँ जैसे afl (AmiBroker Formula Language) या ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

ध्यान दें, मैंने शाखाओं के भीतर ट्रंक लाइव किया है क्योंकि मैं इसे डिफ़ॉल्ट शाखा के रूप में मानता हूं। एकमात्र दर्द कभी-कभी होता है जब आप जल्दी से एक और प्रोजेक्ट बनाना चाहते हैं जिसे आपको प्रोजेक्टनेम / शाखाएं बनाने की आवश्यकता होती है। टैग संरचना। मैं ऐप-सेटिंग्स का उपयोग उसी स्थान पर करता हूं, जहां विशिष्ट ऐप्स सेटिंग्स फ़ाइलों को रेपो में रखने के लिए इतनी आसानी से दूसरों के लिए साझा किया जा सकता है (और इस फ़ोल्डर संरचना में AppName के लिए VendorName और ProjectName के लिए क्लाइंटनाम का चयन करें; और शाखाएं; टैग्स) विभिन्न प्रमुखों में टैग सेटिंग्स के लिए उपयोगी हो सकती हैं। विक्रेता उत्पादों के संस्करण भी)।

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

— जद
स्रोत

1

मेरा सुझाव एक है। जब तक आपके पास अलग-अलग उपयोगकर्ता एक-दूसरे तक नहीं पहुंचते, तब मैं कहूंगा कि कई का उपयोग करें।

लेकिन फिर से, यहां तक कि कई का उपयोग करने के लिए एक अच्छा कारण नहीं है।

— लेवी रोसोल
स्रोत