आप अपने वर्जन कंट्रोल रिपोजिटरी को कैसे व्यवस्थित करते हैं?

Question

सबसे पहले, मुझे इसके बारे में पता है: How would you organize a Subversion repository for in house software projects? अगला, वास्तविक प्रश्न: मेरी टीम हमारे भंडार का पुनर्गठन कर रही है और मैं इसे व्यवस्थित करने के संकेतों की तलाश में हूं। (इस मामले में एसवीएन)। यहां हम क्या आए हैं। बाहरी पार संदर्भ

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/ 
    \NUnit.v2.4.8 
    \NCover.v.1.5.8 
    \<other similar tools> 
\commonFiles /*settings strong name keys etc.*/ 
    \ReSharper.settings 
    \VisualStudio.settings 
\trash /*each member of the team has trash for samples, experiments etc*/ 
    \user1 
    \user2 
\projects 
    \Solution1 /*Single actual project (Visual Studio Solution)*/ 
     \trunk 
     \src 
      \Project1 /*Each sub-project resulting in single .dll or .exe*/ 
      \Project2 
     \lib 
     \tools 
     \tests 
     \Solution1.sln 
     \tags 
     \branches 
    \Solution2 
     \trunk 
     \src 
      \Project3 /*Each sub-project resulting in single .dll or .exe*/ 
      \Project1 /*Project1 from Solution1 references with svn:externals*/ 
     \lib 
     \tools 
     \tests 
     \Solution2.sln 
     \tags 
     \branches 

शब्दावली साफ़ करने के लिए: हम एक भंडार, कई परियोजनाओं और कई SVN है समाधान एकल उत्पाद का मतलब है, परियोजना एक दृश्य स्टूडियो परियोजना (है कि एक ही .dll या एकल .exe में परिणाम)

इस प्रकार हम रिपोजिटरी को बाहर रखने की योजना बना रहे हैं। मुख्य मुद्दा यह है कि हमारे पास कई समाधान हैं, लेकिन हम समाधानों के बीच परियोजनाओं को साझा करना चाहते हैं। हमने सोचा कि वास्तव में उन साझा परियोजनाओं को अपने स्वयं के समाधानों में स्थानांतरित करने में कोई बात नहीं है, और इसके बजाय हमने समाधानों के बीच परियोजनाओं को साझा करने के लिए svn: externals का उपयोग करने का निर्णय लिया। हम भंडार में एक ही स्थान पर औजारों और तृतीय पक्ष पुस्तकालयों के सामान्य सेट को भी रखना चाहते हैं, और वे उन्हें प्रत्येक समाधान में svn: externals के साथ संदर्भित करते हैं।

इस लेआउट के बारे में आप क्या सोचते हैं? विशेष रूप से svn: बाहरी के उपयोग के बारे में। यह एक आदर्श समाधान नहीं है, लेकिन सभी पेशेवरों और विपक्षों पर विचार करते हुए, यह सबसे अच्छा है जिसे हम सोच सकते हैं। आपको इसे कैसे करना होगा?

Answer 1

आप नीचे मेरी सिफारिशों का पालन करें, तो (मैं साल के लिए हैं) तो आप में सक्षम हो जाएगा करने के लिए:

- स्रोत नियंत्रण में कहीं भी प्रत्येक परियोजना के शब्दों में कहें, जब तक आप पर परियोजना रूट निर्देशिका से संरचना की रक्षा नीचे

-, किसी भी मशीन पर कहीं भी प्रत्येक परियोजना का निर्माण कम से कम जोखिम और कम से कम तैयारी

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

- निर्माण और परियोजनाओं के किसी भी संयोजन के साथ काम करते हैं, क्योंकि वे स्वतंत्र हैं

- निर्माण और एक ही परियोजना की कई प्रतियां/संस्करणों के साथ काम है, क्योंकि वे स्वतंत्र हैं

- अपने स्रोत को अव्यवस्थित से बचने उत्पन्न फ़ाइलों या पुस्तकालयों

मेरा सुझाव के साथ नियंत्रण भंडार (यहाँ बीफ है):

1. प्रत्येक परियोजना के इस तरह के एक .dll, .EXE के रूप में एक प्राथमिक प्रदेय, उत्पादन करने के लिए परिभाषित करें, या। जेएआर (विजुअल स्टूडियो के साथ डिफ़ॉल्ट)।

2. प्रत्येक प्रोजेक्ट को एक रूट के साथ एक निर्देशिका पेड़ के रूप में संरचना करें।

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

4. विंडोज, या ऐसा ही कुछ पर नेट परियोजनाओं अपने ओएस, लक्ष्य मंच, आदि

5. हर परियोजना का निर्माण स्क्रिप्ट एक भी स्थानीय से उसके बाहरी (3 पक्ष) निर्भरता संदर्भ बनाने के आधार पर के लिए Nant पर विचार करें साझा की गई "लाइब्रेरी" निर्देशिका, इस तरह की बाइनरी के साथ पूरी तरह से संस्करण द्वारा पहचाना गया: %DirLibraryRoot%\ComponentA-1.2.3.4.dll, %DirLibraryRoot%\ComponentB-5.6.7.8.dll।

6. प्रत्येक प्रोजेक्ट बिल्ड स्क्रिप्ट को एक स्थानीय साझा "आउटपुट" निर्देशिका में प्राथमिक वितरित करने योग्य बनाएं: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe।

7. प्रत्येक प्रोजेक्ट बिल्ड स्क्रिप्ट को "लाइब्रेरी" और "आउटपुट" निर्देशिकाओं में कॉन्फ़िगर करने योग्य और पूर्ण-संस्करण वाले पूर्ण पथ (ऊपर देखें) के माध्यम से अपनी निर्भरता संदर्भित करें, और जहां कहीं भी नहीं।

8. किसी प्रोजेक्ट को किसी अन्य प्रोजेक्ट या इसकी किसी भी सामग्री को सीधे संदर्भित करने दें - केवल "आउटपुट" निर्देशिका (ऊपर देखें) में प्राथमिक डिलिवरेबल्स के संदर्भों की अनुमति दें।

9. प्रत्येक प्रोजेक्ट बिल्ड स्क्रिप्ट को कॉन्फ़िगर करने योग्य और पूर्ण-संस्करण वाले पूर्ण पथ द्वारा 0:, %DirToolRoot%\ToolB\5.6.7.8 द्वारा अपने आवश्यक निर्माण टूल को संदर्भित करें।

10. मेक परियोजना रूट निर्देशिका में एक निरपेक्ष पथ रिश्तेदार द्वारा हर परियोजना का निर्माण स्क्रिप्ट संदर्भ स्रोत सामग्री: ${project.base.dir}/src, ${project.base.dir}/tst (वाक्य रचना का निर्माण उपकरण से भिन्न होता है)। ${project.base.dir}/some/dirs या ${env.Variable}/other/dir:

11. हमेशा हर फ़ाइल या निर्देशिका को संदर्भित करने के लिए एक परियोजना का निर्माण स्क्रिप्ट एक पूर्ण, विन्यास पथ (एक निर्देशिका एक विन्यास चर द्वारा निर्दिष्ट में निहित) के माध्यम से की आवश्यकता है।

12. किसी परियोजना निर्माण स्क्रिप्ट को .\some\dirs\here या ..\some\more\dirs जैसे किसी सापेक्ष पथ के साथ संदर्भित करने की अनुमति न दें, हमेशा पूर्ण पथ का उपयोग करें।

13. किसी प्रोजेक्ट बिल्ड स्क्रिप्ट को किसी पूर्ण पथ का उपयोग करने के लिए किसी भी संदर्भ का संदर्भ देने की अनुमति न दें, जिसमें C:\some\dirs\here या \\server\share\more\stuff\there जैसी कॉन्फ़िगर करने योग्य रूट निर्देशिका नहीं है।

14. प्रोजेक्ट बिल्ड स्क्रिप्ट द्वारा संदर्भित प्रत्येक कॉन्फ़िगर करने योग्य रूट निर्देशिका के लिए, उन परिवेशों के लिए उपयोग किए जाने वाले पर्यावरण चर को परिभाषित करें।

15. प्रत्येक मशीन को कॉन्फ़िगर करने के लिए आपको बनाए गए पर्यावरण चर की संख्या को कम करने का प्रयास करें।

16. प्रत्येक मशीन पर, एक शेल स्क्रिप्ट बनाएं जो आवश्यक पर्यावरण चर को परिभाषित करती है, जो उस मशीन के लिए विशिष्ट है (और संभवतः उस उपयोगकर्ता के लिए विशिष्ट, यदि प्रासंगिक हो)।

17. मशीन-विशिष्ट कॉन्फ़िगरेशन खोल स्क्रिप्ट को स्रोत नियंत्रण में न रखें; इसके बजाय, प्रत्येक प्रोजेक्ट के लिए, प्रोजेक्ट रूट निर्देशिका में स्क्रिप्ट की प्रतिलिपि टेम्पलेट के रूप में करें।

18. इसके वातावरण चर में से प्रत्येक की जांच करने के लिए, और एक सार्थक संदेश के साथ गर्भपात अगर वे परिभाषित नहीं कर रहे हैं प्रत्येक परियोजना के निर्माण स्क्रिप्ट की आवश्यकता है।

19. प्रत्येक प्रोजेक्ट बिल्ड स्क्रिप्ट को अपने प्रत्येक निर्भर बिल्ड टूल एक्जिक्यूटिव, बाहरी लाइब्रेरी फाइलें, और निर्भर प्रोजेक्ट डिलिवरेबल फाइलों की जांच करने के लिए, और उन फ़ाइलों को मौजूद नहीं होने पर एक सार्थक संदेश के साथ निरस्त करने की आवश्यकता है।

20. प्रलोभन स्रोत नियंत्रण में किसी भी उत्पन्न फ़ाइलों प्रतिबद्ध करने के लिए विरोध - कोई परियोजना डिलिवरेबल्स, कोई उत्पन्न स्रोत, कोई उत्पन्न डॉक्स, आदि

21. आप एक IDE का उपयोग करते हैं, जो कुछ भी परियोजना नियंत्रण फ़ाइलों आप कर सकते हैं उत्पन्न , और उन्हें स्रोत नियंत्रण में प्रतिबद्ध न करें (इसमें विजुअल स्टूडियो प्रोजेक्ट फाइलें शामिल हैं)।

22. डेवलपर वर्कस्टेशन और मशीन बनाने के लिए सभी बाहरी पुस्तकालयों और उपकरणों की आधिकारिक प्रति के साथ एक सर्वर स्थापित करें। अपने स्रोत नियंत्रण भंडार के साथ, इसे वापस चलाएं।

23. एक सतत एकीकरण सर्वर (मशीन का निर्माण) जो भी कोई विकास उपकरण के साथ स्थापित करना।

24. ऐसे आइवी के रूप में अपने बाहरी पुस्तकालयों और डिलिवरेबल्स, (चींटी के साथ प्रयुक्त) के प्रबंधन के लिए एक उपकरण पर विचार करें।

25. Maven का उपयोग न करें - यह शुरू में आप खुश कर देगा, और अंततः आप रो सकते हैं।

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

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

सबवर्सन बाहरी (या अन्य उपकरणों में समान) कृपया का उपयोग नहीं करते, वे एक विरोधी पैटर्न हैं और इसलिए, अनावश्यक।

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

@VonC: जब आप अपनी बिल्ड स्क्रिप्ट तोड़ते हैं तो आप जलाए जाने के बाद "ant-abcdjar" के बजाय "ant.jar" के साथ हर समय काम नहीं करना चाहते हैं क्योंकि आप अनजाने में चींटी के असंगत संस्करण के साथ भाग गए हैं ।यह चींटी 1.6.5 और 1.7.0 के बीच विशेष रूप से आम है। सामान्यीकरण, आप हमेशा जानना चाहते हैं कि प्रत्येक प्लेटफ़ॉर्म (जावा एबीसीडी) और आपके बिल्ड टूल (एंटी ई.एफ.जी.एच) सहित प्रत्येक घटक का विशिष्ट संस्करण उपयोग किया जा रहा है। अन्यथा, आपको अंततः एक बग का सामना करना पड़ेगा और आपकी पहली बड़ी समस्या यह पता लगाएगी कि आपके विभिन्न घटकों के कौन से संस्करण शामिल हैं। सामने की समस्या को हल करना बेहतर है।

Answer 2

मुझे विश्वास है कि Pragmatic Version Control using Subversion में आपके भंडार को व्यवस्थित करने के लिए आवश्यक सब कुछ है।

Answer 3

हमने आपके द्वारा पोस्ट किए गए लगभग सटीक मिलान करने के लिए सेट अप किया है।

\Project1 
    \Development (for active dev - what you've called "Trunk", containing everything about a project) 
    \Branches (For older, still-evolving supported branches of the code) 
     \Version1 
     \Version1.1 
     \Version2 
    \Documentation (For any accompanying documents that aren't version-specific 

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

Answer 4

मेरे पास एक समान लेआउट है, लेकिन मेरे ट्रंक, शाखाएं, शीर्ष पर सभी तरह से टैग करती हैं। तो:/ट्रंक/मुख्य,/ट्रंक/utils,/शाखाओं/रिलीज /, आदि

यह वास्तव में आसान हो गया जब हम अन्य संस्करण नियंत्रण प्रणाली को आजमाने की कोशिश की क्योंकि कई अनुवाद उपकरण सबसे अच्छे काम करते थे मूल पाठ्यपुस्तक एसवीएन लेआउट।

Answer 5

मुझे लगता है कि प्रस्तावित संरचना का मुख्य नुकसान यह है कि साझा परियोजनाओं को केवल पहले समाधान के साथ संस्करणित किया जाएगा (जब तक svn: बाहरी कल्पना करने की तुलना में फैनसीयर नहीं है)। उदाहरण के लिए, जब आप समाधान 2 की पहली रिलीज के लिए शाखा बनाते हैं, तो प्रोजेक्ट 1 को ब्रांच नहीं किया जाएगा क्योंकि यह समाधान 1 में रहता है। यदि आपको बाद में उस शाखा से (QFE रिलीज) में निर्माण करने की आवश्यकता है, तो यह शाखा के समय प्रोजेक्ट 1 के संस्करण की बजाय Project1 के नवीनतम संस्करण का उपयोग करेगा।

इस कारण से, यह (अपने ढांचे में और इस तरह उच्च-स्तरीय निर्देशिका) एक या एक से अधिक शेयर किए गए समाधान में साझा प्रोजेक्ट के रख दिया और फिर उन्हें किसी भी समाधान के प्रत्येक रिलीज के साथ शाखा लाभप्रद हो सकता है।

Answer 6

यह सब एक भंडार में क्यों है? क्यों न सिर्फ प्रत्येक परियोजना के लिए एक अलग भंडार है (मेरा मतलब है "समाधान")?

ठीक है, कम से कम मैंने एक-प्रोजेक्ट-प्रति-रिपोजिटरी-दृष्टिकोण पर उपयोग किया है। आपकी रिपोजिटरी संरचना मेरे लिए जटिल लगती है।

और आप इस बड़े भंडार में कितने प्रोजेक्ट को लगाने की योजना बना रहे हैं? 2? 3? 10? 100?

और जब आप एक परियोजना के विकास को रद्द करते हैं तो आप क्या करते हैं? इसे रिपोजिटरी पेड़ से हटा दें ताकि भविष्य में इसे खोजना मुश्किल हो जाए। या इसे हमेशा के लिए झूठ बोल छोड़ दो? या जब आप एक प्रोजेक्ट को दूसरे सर्वर पर ले जाना चाहते हैं?

और उन सभी संस्करण संख्याओं की गड़बड़ी के बारे में क्या? एक परियोजना की संस्करण संख्या 2, 10, 11 की तरह चल रही है, जबकि दूसरा 1, 3, 4, 5, 6, 7, 8, 9, 12 ...

शायद मैं मूर्ख हूं, लेकिन मुझे प्रति प्रोजेक्ट एक प्रोजेक्ट पसंद है।

Answer 7

रिश्तेदार पथ मुद्दे को जोड़ने के लिए:
बस चेकआउट solution1/निर्देशिका नाम "solution1" के तहत ट्रंक, Solution2 के लिए डिट्टो:: 'निर्देशिका' के लक्ष्य

मैं यह एक समस्या है यकीन नहीं है वास्तव में शाखाओं का प्रतिनिधित्व एक कार्यक्षेत्र में आयात किए जाने पर दिखाई नहीं दे रहा है। इसलिए 'समाधान 1' (वास्तव में 'समाधान 1/ट्रंक') और 'समाधान 2' (समाधान 2/ट्रंक) के बीच सापेक्ष पथ संभव हैं।

Answer 8

उत्तर: रिश्तेदार पथ और साझा फ़ाइल मुद्दा -

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

हम अभी भी यह काम कर रहे हैं और मेरे पास 3 अलग-अलग प्रयास हैं (अलग-अलग क्लाइंट) जिन्हें मुझे अभी हल करना है क्योंकि मैंने या तो मौजूद नहीं है या खराब संस्करण नियंत्रण स्थापित किया है।