प्रोमोशनल मॉडल

Question

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

मुझे लगता है कि निम्नलिखित चित्र हमारे वांछित वर्कफ़्लो को सर्वोत्तम रूप से दिखाते हैं, जब भी नई रिलीज पर काम शुरू होता है, और शाखाओं को पहले की शाखाओं से बाद में बदलते हुए बदलते हैं।

 
| 
1 
| 
|\ 
| \ 
| 2 
3 | 
|\| 
4 | 
| |\ 
5 | \ 
| 6 | 
| | 7 
|\|\| 
| |\| 
8 9 |\ 
| | | \ 
|\| | 10 
x |\| | 
    | |\| 
    | | | 

a b c d 

• इस मॉडल काम सुचारू रूप से एक सार्थक ट्रंक की कमी के बावजूद सबवर्सन का उपयोग कर सकते हैं?
• क्या पूर्व शाखाओं के बाद के संस्करणों के अपडेट के लिए स्वचालित मर्ज ट्रैकिंग कार्य स्वचालित होगा?
• क्या किसी शाखा को बंद/हटा/अनदेखा करना ठीक है (इस उदाहरण में पुनर्निर्मित किए बिना शाखा 'ए' रिलीज करना ठीक है?
• क्या प्रत्येक रिलीज शाखा से फीचर शाखाएं बनाना ठीक होगा, और इनके लिए ट्रैकिंग कार्य मर्ज करना होगा? (वे अनुशंसित निर्माण/विलय/पुन: वर्गीकृत मॉडल का पालन करेंगे।)

संपादित करें - अधिक जानकारी जोड़ें।

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

 
    a 
    | 
    1 
    | 
    b|\ a 
    | \ 
    | 2 
    3 | 
    | | 
    4 | 
    b/|c | 
/5 | 
| | 6 
7 | | 
b c a 

इस मामले में, हम सुविधा 2 शाखा ख में (शाखा एक में पूरा) चाहते हैं, लेकिन इस के रूप में एक बच्चे के लिए माता पिता के मर्ज, और इसलिए सबवर्सन द्वारा समर्थित नहीं है, यह किया जाना होगा मैन्युअल रूप से। इसी प्रकार, फीचर 6 को दो बार मैन्युअल रूप से विलय करना होगा। मैं स्वचालित रूप से ट्रैक किए गए विलय की तुलना में अपेक्षाकृत धीमी और त्रुटि-प्रवण प्रक्रिया होने का अनुमान लगाता हूं।

Answer 1

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

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

आवश्यकता है कि आप केवल आगे बढ़ते हैं जैसे कि आपको मुख्य पंक्ति से सबसेट संशोधन को मर्ज करने की आवश्यकता है, किसी दिए गए शाखा संशोधन के बाद संशोधन। इस तरह से विलय करने से आप मनमाने ढंग से शाखाओं से जितनी बार चाहें उतनी बार मुख्य लाइन तक परिवर्तनों को विलय कर सकते हैं (जैसा कि उन्हें आपके ग्राहकों के साथ पुष्टि है) और आत्मविश्वास के साथ आगे लागू किया जा सकता है कि केवल मान्य परिवर्तन लागू हो रहे हैं। आप उस प्रतिलिपि को देखने के लिए स्वचालित विलय स्थापित कर सकते हैं (देखें - स्टॉप-ऑन-कॉपी और रेंज-आधारित विलय)। रिलीज शाखाएं तब दिए गए बिंदु से हुई पुष्टि किए गए परिवर्तनों के सेट उठाती हैं।

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

अपने समक्ष सवालों के जवाब देने के लिए:

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

• निश्चित रूप से। यह आपके द्वारा चुनी गई संरचना से काफी स्वतंत्र होना चाहिए। आपको अपने संशोधन बिंदुओं का ट्रैक रखने की आवश्यकता होगी/चाहे (शायद कुछ सरल पटकथाओं के माध्यम से बदतर)।

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

• यह "शाखाकरण" संगठनात्मक संरचना के स्थान पर ध्यान दिए बिना काम करना चाहिए। ऐसा लगता है कि एसवीएन में "शाखा" होने का क्या अर्थ है, इस पर कुछ गलतफहमी है। आप जो चाहते हैं उसे स्थापित करने में सक्षम होना चाहिए और 'मैनुअल' को सापेक्ष आसानी से विलय करना चाहिए और बाद में कुछ ग्राहक अपडेट के बाद स्वचालित विलय स्थापित करना चाहिए ताकि आप अपने विलय चरणों को थोड़ा बेहतर समझ सकें।

चीयर्स!

Answer 2

आप कहते हैं:

पहले शाखाओं से सभी काम बाद में लोगों में यह करना चाहिए। पर काम बाद में शाखाओं पहले लोगों में यह नहीं चाहिए (इसमें हमारे अनुबंधों में है)

यहाँ, अगर हम रिलीज के साथ शाखाओं की जगह (मुझे शक है अपने ग्राहकों को पता है या "शाखाओं" के बारे में परवाह) पर हम पाते हैं :

पहले रिलीज़ से सभी काम बाद में इसे बनाना चाहिए। पर काम बाद में विज्ञप्ति पहले लोगों में यह नहीं चाहिए (इसमें हमारे अनुबंधों में है)

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