मैं संस्करण 1.1 और संस्करण 2.0 पर एक साथ कैसे काम करूं?

Question

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

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

Answer 1

एक अच्छा तरीका स्थिर बग में प्रत्येक बग को ठीक करना और स्थिर शाखा को विकास शाखा में विलय करना है। यह Parallel Maintenance/Development Lines पैटर्न है, और कुंजी जल्दी और अक्सर मर्ज करने के लिए है। निरंतर और देर से विलय करना मतलब है कि विकास शाखा स्थिर की तुलना में अपरिचित है, या बग को उसी तरह दोहराया नहीं जा सकता है।

Subversion में संस्करण 1.5 के बाद मर्ज ट्रैकिंग शामिल है ताकि आप सुनिश्चित कर सकें कि वही परिवर्तन सेट दो बार विलय नहीं हुआ है, जिससे मूर्ख संघर्ष हो रहा है। अन्य सिस्टम मौजूद हैं (उदा। Git, Mercurial, Accurev, Perforce) जो आपको इस प्रकार के प्रश्न पूछने देते हैं कि "शाखा ए में कौन से परिवर्तन शाखा बी में विलय नहीं किए गए हैं?" और चेरी-फिक्स चुनें जो आपको देव शाखा में चाहिए।

Answer 2

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

Answer 3

आलेख here (सबवर्सन के साथ दिन-प्रतिदिन) का उल्लेख है कि एक विधि संस्करण 1.1 निर्माण से डेटा के साथ संस्करण 2 को लगातार अद्यतन करना है। लेख में, लड़का हर दिन ऐसा करने के लिए कहता है।

जो भाग आप पढ़ना चाहते हैं वह शीर्षक है "वेटर, मेरे ट्रंक में एक बग है!"। लेख के बावजूद यह आधा रास्ते है।

Answer 4

जल्दी मर्ज करें, अक्सर मर्ज करें, और सुनिश्चित करें कि मुख्य रेखा पर क्यूए रखरखाव रिलीज के प्रत्येक पैच में तय दोषों को जानता है और सत्यापित करता है/सत्यापित करता है।

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

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

मुझे यह भी विश्वास है कि लगातार एक विलय करने के लिए ज़िम्मेदार एक व्यक्ति होने से यह सुनिश्चित करने में मदद मिलती है कि वे नियमित रूप से होते हैं। यह आमतौर पर मुझे या हमारी टीम के वरिष्ठ लोगों में से एक रहा है।

Answer 5

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

मैं तब जोर देकर कहूंगा कि 1.x डेवलपर 1.x प्रतिबद्धता के लिए संशोधन संख्या और उस बग के लिए टिकट में 2.0 विलय के लिए संशोधन संख्या दोनों का ध्यान दें। इस तरह, यह ध्यान रखना आसान होगा कि कोई भी अपने परिवर्तनों को मर्ज करना भूल जाता है, और तथ्य यह है कि उन्हें इसका ट्रैक रखना होगा, उन्हें याद रखने में मदद मिलेगी।

Answer 6

सुंदर ज्यादा क्या हर किसी ने कहा है, लेकिन मैं समझ मैं SVN

हमारे मुख्य उत्पाद के साथ

का उपयोग कर कई शाखाओं में विकास से निपटने के साथ मेरा अनुभव में टॉस हैं, हम एक साथ पर 2 + संस्करणों में विकसित करने के लिए की जरूरत है उसी समय।

मैंने मूल रूप से "मुख्य विकास" संस्करण के रूप में मुख्य ट्रंक का उपयोग किया, प्रत्येक वास्तविक रिलीज के लिए टैग किए गए टैग के साथ। शाखाओं का इस्तेमाल एक नए फीचर सेट के लिए पर्याप्त विकास प्रयासों के लिए किया गया था। फिर बाद में, जब हमने 2, 3 और 4 रिलीज पर काम करना शुरू किया, तब मैंने प्रत्येक संशोधन के लिए शाखा का उपयोग शुरू किया। परिवर्तन विलय पेड़ सबसे कम वर्तमान में सक्रिय शाखा के साथ शुरू होते हैं जो -

जब से मैं भंडार को बनाए रखने और भी जोर दे क्यूए बनाता है संभाल, मैं "रोलअप्स" हर सुबह करना सुनिश्चित करें। इसलिए मैं 1.2, जो पिछले मर्ज के बाद से 1.2 से किसी भी अन्य परिवर्तन के साथ 1.3 में विलय कर दिया गया है, आदि में 1.1 से परिवर्तन विलय अंत

जब मैं प्रतिबद्ध, मैं हमेशा

की तरह कुछ के साथ प्रतिबद्ध टिप्पणी करने के लिए सुनिश्चित करें

1.1 राजस्व 5656-5690

यह एक दर्द का एक सा हो सकता है विलय कर दिया है, लेकिन यह काम करता है :)

Answer 7

एक प्रमुख मुद्दा डॉक्टर बिल्ड से this picture में कब्जा कर लिया है: केवल एक ही दिशा विलय ।

Answer 8

उस विशिष्ट प्रश्न का उत्तर देने के लिए कई डेवलपर्स ने सबवर्सन से गिट में स्विच किया है। चेकआउट github.com।