अलग कोड के मैनुअल विलय के लिए टिप्स

Question

मुझे शाखाओं और विलय के लिए svn का उपयोग करने के लिए काफी उपयोग किया जाता है, आमतौर पर यह ठीक काम करता है। हालांकि दो शाखाओं में एक घटक पर काम किया गया था और मूल रूप से घटक को विभिन्न दिशाओं में ले लिया गया था, इसलिए स्वत: विलय काम नहीं करेगा और तुलना से परे उपयोग फाइलों को अधिकतर अलग दिखाता है।

मैंने कुछ फाइलों को एक साथ जोड़ने की कोशिश की है, लेकिन परिणाम, भले ही वे काम करते हैं, काफी भयानक हैं।

मैं इस व्यवसाय से कहने के लिए प्रेरित हूं कि यह अभी नहीं किया जा सकता है। मैं उन्हें निराशाजनक देख सकता हूं क्योंकि उनके पास मॉड्यूल + फीचर है एक वर्किंग और मॉड्यूल + फीचर बी काम कर रहा है लेकिन मॉड्यूल + फीचर ए + फीचर बी सिर्फ यह समझ में नहीं आता है। उदाहरण के लिए सुविधा ए कुछ ऐसी चीज को हटा सकता है जो फीचर बी में एक महत्वपूर्ण घटक था।

क्या इस तरह के कोड को मर्ज करने का प्रयास करने का कोई तरीका है? या मॉड्यूल + ए + बी वास्तव में मॉड्यूल + सी है?

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

Answer 1

आप जो बात कर रहे हैं वह अनिवार्य रूप से शाखाओं में से किसी एक को पुनर्जीवित करने का प्रयास कर रहा है। some DVCSs में इसके लिए समर्थन है लेकिन मुझे एसवीएन में इस तरह की चीज़ के लिए किसी भी समर्थन के बारे में जानकारी नहीं है।

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

भविष्य में आप इससे कैसे बचते हैं? Frequent integration।

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

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

Answer 2

एक फ़ाइल ले लो, src1.c. कहें आप एक हीरे आरेख मर्ज इस तरह का वर्णन का निर्माण कर सकते हैं:

Original src1.c 
     /  \ 
    /  \ 
    /   \ 
    b1 src1.c  b2 src1.c 
     \   /
     \  /
     \  /
     \ /
     merged src1.c 

कहाँ B1 पहली शाखा संस्करण का मतलब है और बी 2 दूसरा शाखा संस्करण का मतलब है। आप समांतर diffs की तुलना कर सकते हैं (विलय स्रोत और बी 2 संस्करण, और बी 1 और मूल के बीच एक कहें)। यह मदद कर सकता है।