2008-09-25 6 views
7

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

अब मैं रिपो को व्यवस्थित करने का तरीका समझने की कोशिश कर रहा हूं, परियोजनाओं की संख्या छोटी (~ 5) है। क्या प्रत्येक प्रोजेक्ट के लिए उप-उपफोल्डर्स के साथ, मॉड्यूल-बाय-मॉड्यूल आधार पर शीर्ष स्तर के उपफोल्डर्स को रखने के लिए यह समझ में आता है? या शीर्ष स्तर प्रत्येक परियोजना के लिए किया जाना चाहिए, प्रत्येक परियोजना के लिए अपने स्वयं के मॉड्यूल सबफ़ोल्डर होने के साथ:

रेपो:

module 1 
    Project 1 
    Project 2 
    ... 

    Project 5 
module 2 
    Project 1 
    .... 
    Project 5 
.... 
module 20 
    Project 1 
    ... 
    Project 5 

-या-

रेपो:

Project 1 
    module 1 
    module 2 
    ... 
    module 20 
Project 2 
    module 1 
    module 2 
    ... 
    module 20 
... 
Project 5 
    module 1 
    module 2 
    ... 
    module 20 

उत्तर

0

मुझे लगता है कि कि एक परियोजना का वर्णन करने के लिए "उच्च स्तरीय" का उपयोग यह सुझाव देता है कि आपके पास प्रोजेक्ट/मॉड्यूल सेटअप होना चाहिए।

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

1

मैं प्रोजेक्ट द्वारा मॉड्यूल द्वारा आयोजित किया जाएगा (आपका दूसरा उदाहरण)। इसका मुख्य कारण यह है कि मॉड्यूल के प्रबंधन से कम से कम मेरे लिए एक परियोजना के प्रबंधन में अधिक ओवरहेड है।

प्रत्येक अलग परियोजना के लिए अपने स्वयं के निर्माण स्क्रिप्ट सेटअप, गुण फ़ाइल, आदि की जरूरत है और यह की तुलना में 20.

1

आपके कंप्यूटर पर 5 कार्य प्रतियां का ट्रैक रखने के मैं 1 एक पसंद करते हैं एक बहुत आसान है।

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

यानी हमारे प्रमुख उत्पाद में 48123 का संशोधन है, हमारी नई परियोजना में 31 का संशोधन है। यदि आपके पास अंतर-भंडार निर्भरता है, तो आप svn बाहरी का उपयोग कर सकते हैं।

+0

+1 उन बिल्ड संख्या निरंतर निर्माण वातावरण में उपयोगी हैं। – JMP

3

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

यह मतलब हो सकता है दोनों परियोजनाओं और मॉड्यूल रखने के लिए अलग, उदाहरण के लिए:

Projects 
    Project 1 
    Project 2 
    ... 
Modules 
    Module 1 
    Module 2 
    ... 

आप उपयोग करते हैं कि SVN externals और/या vendor branches के साथ संयोजन में, आप अपनी परियोजनाओं है कि विभिन्न जरूरत के लिए विभिन्न शाखाओं का समर्थन कर सकता है मॉड्यूल संस्करण, लेकिन मॉड्यूल के समान संस्करण को साझा करने के लिए प्रोजेक्ट होने पर एक मॉड्यूल स्रोत होने से अभी भी लाभ होता है।

0

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

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