नेस्टेड संस्करण नियंत्रण योजना?

Question

कैसे सबसे अच्छा संस्करण नियंत्रण के कुछ प्रकार में इस परियोजना संरचना ट्रैक करने के लिए पर सुझाव के लिए देख रहे हैं (Git या SVN, अधिमानतः):

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

तो ऐसे कई "कोर" मौजूद हैं, और संस्करण नियंत्रण में अलग-अलग रिलीज/टैग/शाखाएं होंगी। लेकिन फिर उन अत्यधिक वेब इंटरफ़ेस हैं जो उन्हें एक साथ जोड़ते हैं, जिन्हें उन वेब फ़ाइलों के लिए अपनी अतिरिक्त संस्करण नियंत्रण प्रोजेक्ट की आवश्यकता होती है।

एक संरचना दृष्टिकोण से

, यह कुछ ऐसा दिखाई देगा:

/-+ 
    | 
    +--index.php 
    +--engine/ 
    | | 
    | +--1.0-stable/ 
    | | | 
    | | +--feature.php 
    | +--2.0-beta/ 
    |  | 
    |  +--feature.php 
    +--main.css 
    +--main.js 

तो, index.php, main.css और main.js अपने स्वयं के "परियोजना" जो वेब इंटरफेस है का हिस्सा हैं, जबकि 2.0-beta एक अलग विकास है शाखा, जिनके अपडेट अंततः 2.0-stable शाखा में विलय हो जाएंगे, और 1.0 शाखाओं में feature.php पर किसी हॉटफिक्सेस को 2.0 feature.php फ़ाइल में भी विलय करने की आवश्यकता होगी।

क्या मैं रिपोज़ के अंदर रेपो बना सकता हूं? यह सबसे अच्छा कैसे प्रबंधित किया जाएगा?

Answer 1

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

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

Answer 2

शायद submodules उस उपयोग के मामले के लिए काम करेगा।

Answer 3

आपको रिपोज़ के अंदर रेपो बनाने की आवश्यकता नहीं है। वास्तव में, यदि आप उपversण का उपयोग करते हैं, उदाहरण के लिए (गिट में यह समान है), जब आप एक शाखा बनाना चाहते हैं तो आप इसे कॉपी करके (svn cp) कर सकते हैं। सबवर्सन कॉपी-ऑन-राइट (या संशोधन पर प्रतिलिपि) करता है, ताकि आप अलग-अलग निर्देशिकाओं में काम कर सकें जिन्हें अलग रखा जाएगा। फिर आप प्रत्येक शाखा (subdir) में परिवर्तन विलय कर सकते हैं।

Answer 4

मिट्टी^एच^एच^हकोड की बड़ी गेंद से बचें। प्रत्येक कोड लाइन के लिए अलग शाखा का उपयोग करें जिसे आप तैनात करना चाहते हैं। यदि आप शाखाओं के बीच परिवर्तनों को माइग्रेट करने की योजना बना रहे हैं, तो यह सबसे अच्छा तरीका है, क्योंकि आप प्रत्येक शाखा के लिए अलग-अलग कार्यों के बीच परिवर्तनों का प्रबंधन करने में सक्षम होंगे।

सामान्य कोड डिफ़ॉल्ट शाखा में रखा जा सकता है (मास्टर या ट्रंक, आपकी पसंद के एसएमएम के आधार पर)।

आपको स्किम से स्वत: परिनियोजन का उपयोग करना चाहिए, तो आप इसे कॉन्फ़िगर कर सकते हैं, ताकि यह केवल चयनित शाखाओं को तैनात कर सके।

Answer 5

मेरा झुकाव यह है कि अलग-अलग संस्करणों के साथ बहुत ही सामान्य ढांचे को जोड़ना सिरदर्द का कारण बनता है। शायद यह बेहतर काम करेगा:

/-+ 
    | 
    +--discovery/ 
    | | 
    | +--index.php 
    | +--main.css 
    | +--main.js 
    +--engine/ 
    | 
    +--1.0-stable/ 
    | | 
    | +--feature.php 
    +--2.0-beta/ 
     | 
     +--feature.php 

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

संस्करण नियंत्रण से तैनाती प्रत्येक इंजन संस्करण की निर्देशिका के लिए काफी मानक होगी।