एक मॉड्यूलर प्रणाली पर संस्करण नियंत्रण का उपयोग करने की रणनीति

Question

चलो मान लेते हैं (सरलता के लिए) कि हमारे पास क्लाइंट और सर्वर की विशेषता वाला एप्लिकेशन है; क्या दोनों के लिए एक रिपॉजिटरी या अलग रिपॉजिटरी की एक जोड़ी का उपयोग करना बेहतर विचार है?

उनका मिश्रण संभवतः सम्बद्ध परिवर्तनों को ट्रैक करने और सहसंबद्ध शाखाओं (यानी प्रोटोकॉल विकास) को बनाए रखने के लिए आसान बना देगा, लेकिन दूसरी ओर व्यक्तिगत विकास को और अधिक अव्यवस्थित बना देगा ...

Comments

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

— स्पेंसर रथबुन

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

— मार्क बूथ

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

— स्पेंसर रथबुन

Answer 1

आप उपयोग कर रहे हैं Git या अस्थिर है, तो आप को देखने के लिए चाहते हो सकता है submodules या subrepositories ।

क्लाइंट, सर्वर और उनकी इंटरफ़ेस फाइलें अपने स्वयं के रिपॉजिटरी में होंगी, लेकिन सुपर रिपॉजिटरी स्तर पर एक साथ बंधी होंगी । यह आपको शीर्ष स्तर पर एक चेकआउट करने की अनुमति देगा और gitया hgप्रत्येक सबमॉड्यूल्स / सबप्रॉपिटरीज़ की उपयुक्त प्रतिबद्धताओं की जांच करेगा।

केवल सुपर-रिपॉजिटरी के लिए प्रतिबद्ध होने से जब क्लाइंट और सर्वर दोनों एक-दूसरे के लिए उपयुक्त थे, सुपर-रिपॉजिटरी केवल आपको कभी भी एक कार्य प्रणाली की जांच करने का विकल्प देगा - इसलिए आप पुराने के खिलाफ नए क्लाइंट को चलाने की कोशिश नहीं करेंगे सर्वर या इसके विपरीत।

सबमॉड्यूल्स / सबप्रॉपिटरीज़ आपको एक छोटे से अतिरिक्त जटिलता की कीमत पर एकल मोनोलिथिक रिपॉजिटरी के फायदे के साथ-साथ अलग-अलग रिपॉजिटरी का उपयोग करने के सभी फायदे प्रदान करते हैं।

_{यह उत्तर अन्य SCM की वकालत करने gitया करने के लिए अभिप्रेत नहीं है hg, यह सिर्फ इसलिए होता है कि मैं केवल इन SCM को अच्छी तरह से जानता हूं कि यह विकल्प मौजूद है। मुझे समझ नहीं आता कि svnउदाहरण के लिए बाह्य काम कैसे करते हैं।}

Comments

अब यह एक दिलचस्प विशेषता है। मुझे इसके उपयोग के कुछ उचित केस स्टडी देखने में दिलचस्पी होगी, मैंने इसके बारे में पहले नहीं सुना था!

— एड जेम्स

तोड़फोड़ में एक समान बात बाहरी परिभाषाएँ हैं: svnbook.red-bean.com/en/1.0/ch07sn3.html । हालाँकि यह थोड़े अलग तरीके से काम करता है।

— लियोरी

@MarkBooth: हाँ, आप कर सकते हैं। उस पृष्ठ पर आप -123123 जैसे दिखने वाले पैरामीटर देख सकते हैं - वे परिभाषित करते हैं कि आप कौन सा संशोधन प्राप्त करना चाहते हैं। और svn के बाद से: बाह्य संपत्ति को किसी भी पाठ फ़ाइल की तरह संस्करणित किया जाता है, आपके पास प्रत्येक संशोधन के लिए -r के लिए अलग-अलग मान हो सकते हैं। इसके अलावा, आप प्राचीन 1.0 दस्तावेज़ ब्राउज़ कर रहे हैं। बाहरी परिभाषाओं को 1.5 में बदल दिया गया था, और वर्तमान संस्करण 1.7 है। देखें: svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

— liori

Answer 2

अलग!

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

जाहिर है, यह हमेशा संभव नहीं होता है, आपके द्वारा उपयोग किए जा रहे विशेष संचार ढांचे के आधार पर, लेकिन साझा कोड होने की संभावना है जो डेटा-ट्रांसफर ऑब्जेक्ट्स या आपके कस्टम प्रोटोकॉल (या किसी अन्य उदाहरण) में हैंडशेक चरणों के प्रारूप को निर्धारित करता है। ।

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

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

Answer 3

में मर्क्युरियल , इस योजना के लिए इस्तेमाल किया जा सकता है, का उपयोग कर ->निरूपित subrepo रिश्ते के लिए:

product -> client -|-> (many components)
                   |->  shared component A

        -> server -|-> (many components)
                   |->  shared component A

उत्पाद में सबप्रॉप्ट क्लाइंट, सर्वर है। उनमें से प्रत्येक के पास सबप्रॉप्स के रूप में उनके घटक हैं, संभवतः दोनों के बीच कम से कम एक सब्रेपो साझा किया गया है।

टैगिंग संभवतः पहले दो स्तरों पर की जानी चाहिए, इसके नीचे नहीं।

घटक स्तर पर कमिट किया जाता है, सुपरप्रॉप प्रभावी रूप से नामित शाखाओं और उत्पाद के संस्करणों को ट्रैक करता है। नामांकित शाखाएं / बुकमार्क आमतौर पर प्रयोज्य के लिए क्लोन शाखाओं (यानी प्रशिक्षण क्षमता) और सबप्रॉप के साथ संगतता से बेहतर होते हैं।

एचजी धारणा की ओर जाता है कि superrepos हैं उत्पाद, और प्रतिबद्ध शीर्ष स्तर पर किया जाता है, लेकिन वह विशेष रूप में अच्छी तरह से काम नहीं करता है जब एक से अधिक उत्पादों समान घटकों का उपयोग। :-)

मुझे नहीं लगता कि इस योजना को बदलने के लिए बहुत कुछ बदल जाएगा, लेकिन मैंने इसे अभी तक बाहर निकालने की कोशिश नहीं की है।

Answer 4

यह एक कॉन्फ़िगरेशन प्रबंधन समस्या है, एक संशोधन नियंत्रण समस्या नहीं। हमेशा की तरह, एक प्रोग्रामर एक नाखून में हथौड़ा करने के लिए एक पेचकश का उपयोग करता है। वर्क आउट करें कि आप कैसे कॉन्फ़िगरेशन का प्रबंधन करेंगे, संशोधन नियंत्रण स्वयं का ध्यान रखेगा।

Answer 5

सबसे सरल दृष्टिकोण एक एकल रिपॉजिटरी का उपयोग करना है, इसलिए जब तक आप जटिलता की खातिर जटिलता पसंद नहीं करते हैं, तब अन्यथा सम्मोहक तर्कों के अभाव में डिफ़ॉल्ट विकल्प होना चाहिए।

क्या क्लाइंट और सर्वर डेवलपमेंट विभिन्न संगठनों द्वारा किया जा रहा है? क्या क्लाइंट (या सर्वर) के कई कार्यान्वयन होंगे? क्या क्लाइंट खुला स्रोत और सर्वर कार्यान्वयन गुप्त है? यदि इन सभी सवालों का जवाब "नहीं" है, तो एकल रिपॉजिटरी की तुलना में अधिक जटिल कुछ भी लाभ के लिए केवल असुविधा लाने की संभावना है।

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

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

एक से अधिक अवसरों पर, मैंने अपनी टीम के लिए मौजूदा गिट रिपॉजिटरी को मर्ज करने की वकालत (सफलतापूर्वक) की है, क्योंकि इससे विकास और तैनाती आसान हुई है।

Answer 6

एक पल के लिए भंडार के बारे में भूल जाओ। यदि आप किसी के साथ साझा नहीं कर रहे हैं तो आप अपनी मशीन पर दो परियोजनाओं को कैसे व्यवस्थित करेंगे? बाकी टीम ऐसा कैसे करेगी? क्या तुम...

• क्लाइंट और सर्वर दोनों के लिए एक ही डायरेक्टरी में सभी सोर्स फाइल्स रखें?

• क्लाइंट और सर्वर के लिए उपनिर्देशिका वाली एक मुख्य परियोजना निर्देशिका बनाएं?

• दो परियोजनाओं को पूरी तरह से अलग रखें?

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

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