एक मर्कुरियल विलय ने गलत परिवर्तनों का चयन किया, इसे ठीक करने का सही तरीका क्या है?

Question

बिल्ड मशीन (चेंजसेट 1700) पर किसी समस्या को ठीक करने के लिए हमारे .vcproj में परिवर्तन किए गए थे। बाद में, एक डेवलपर ने अपने परिवर्तनों (1710 से 1715 में परिवर्तन) को ट्रंक में विलय कर दिया, लेकिन मर्कुरियल ऑटो-मर्ज 1700 से परिवर्तनों को ओवरराइट कर दिया। मुझे लगता है कि ऐसा हुआ क्योंकि उन्होंने गलत शाखा को मर्ज के "पैरेंट" के रूप में चुना है (भाग देखें प्रश्न के 2)।

1) क्या "सही" अस्थिर इस समस्या को हल करने के लिए, सभी मर्ज किए गए फ़ाइलें, केवल एक फ़ाइल को गलत तरीके से विलय हो गया से बाहर पर विचार तरीका है, और

2) क्या डेवलपर क्रम में अलग ढंग से किया जाना चाहिए यह सुनिश्चित करने के लिए कि यह नहीं हुआ? क्या ऐसे तरीके हैं जिन्हें हम "सही" तरीके से लागू कर सकते हैं?

संपादित करें: मैं शायद जो हुआ उसके बारे में पर्याप्त स्पष्ट नहीं था। डेवलपर ए ने हमारी .vcproj फ़ाइल में एक पंक्ति को संशोधित किया जिसने कंपाइलर के लिए एक विकल्प हटा दिया। उनका चेक-इन 1700 में बदल गया। डेवलपर बी, पिछले माता-पिता से काम करता है (चलिए 16 9 0 में बदलाव करते हैं), परियोजना के पूरी तरह से अलग हिस्सों में कुछ बदलाव किए, लेकिन .vcproj फ़ाइल को स्पर्श करें (बस कहीं भी नहीं डेवलपर ए द्वारा किए गए परिवर्तन)। जब डेवलपर बी ने अपने परिवर्तनों को विलय कर दिया (1715 से 1715 में परिवर्तन हो रहा है), विलय प्रक्रिया 1700 से परिवर्तनों को ओवरराइट करती है।

इसे ठीक करने के लिए, मैंने फिर से बदलाव को शामिल करने के लिए .vcproj फ़ाइल को फिर से संशोधित किया, और इसे चेक इन किया मैं सिर्फ क्यों जानना चाहता था Mercurial ने सोचा कि इसे 1700 में परिवर्तन नहीं रखना चाहिए, और यह तय करने के लिए "आधिकारिक" तरीका था या नहीं।

दूसरा संपादित करें: डेवलपर बी ऊपर और नीचे कसम खाता है कि Mercurial ने विवाद समाधान के लिए उसे संकेत दिए बिना .vcproj फ़ाइल विलय कर दिया है, लेकिन यह निश्चित रूप से संभव है कि वह सिर्फ गलत समझा जा रहा है, इस मामले में यह पूरा अभ्यास अकादमिक है।

Answer 1

मैं 2 भाग संबोधित करेंगे की आप पहली बार सवाल ...

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

मर्ज टूल का सामान्य मामला हमेशा सही ढंग से विलय करना बहुत मुश्किल है, और वास्तव में वर्तमान तकनीक के साथ नहीं हो सकता है। यहां मेरा उदाहरण है: सी:

int i; // Someone replaces this with 'short i' in one changeset stating 
     // that a short is more efficient. 

// ... lots of code; 

// Someone else replaces all the 65000s with 100000s in another changeset, 
// saying that more precision is needed. 
for (i = 0; i < 65000; ++i) { 
    integral_approximation_piece(start + i/65000.0, end + (i + 1)/65000.0); 
} 

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

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

इसे विकास प्रथाओं द्वारा भी तय किया जा सकता है जो इलाके को प्रोत्साहित करते हैं। उदाहरण के लिए एक कोडिंग मानक जो कहता है "वैरिएबल को घोषित किया जाना चाहिए जहां उनका उपयोग किया जाता है।"।

मुझे लगता है कि .vcproj फाइलें विशेष रूप से इस समस्या से ग्रस्त हैं क्योंकि वे डेवलपर्स द्वारा अच्छी तरह से समझ में नहीं आती हैं और यदि संघर्ष प्रकट होते हैं तो वे सुनिश्चित नहीं होंगे कि उनके साथ क्या किया जाए। मेरा अनुमान है कि यह हुआ और अपने डेवलपर बस संशोधन (रों) वह में जाँच की।

भाग 1 के रूप में करने के लिए वापस एक पूर्ववत किया है ...

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

आप एक नए बदलाव की जांच भी कर सकते हैं जो विलय के साथ समस्या को हल करता है।

वे मूल रूप से आपके दो विकल्प हैं।

आपकी पोस्ट का स्वर मुझे यह इंगित करने के लिए प्रतीत होता है कि आपके संगठन में इस मुद्दे के आसपास कुछ राजनीति हो सकती है, और लोग इस त्रुटि को Mercurial के लगातार विलय पर दोष दे रहे हैं। तो मैं बताऊंगा कि किसी भी परिवर्तन नियंत्रण प्रणाली में यह समस्या हो सकती है। सबवर्सन के मामले में, उदाहरण के लिए, जब भी डेवलपर अपनी कार्यशील निर्देशिका में उत्कृष्ट परिवर्तन करता है, तो वे एक अद्यतन करते हैं, वे विलय कर रहे हैं, और इस तरह की समस्या किसी भी विलय के साथ उत्पन्न हो सकती है।

Answer 2

Mercurial में एक विलय में एक अकेला माता पिता नहीं होता है, इसकी परिभाषा के अनुसार दो और केवल दो माता-पिता होते हैं। जब कोई विलय है वे दो विकल्प बना रहे हैं:

1. क्या दो changesets दो परिवर्तन का गठन करेंगे
2. उन changesets में से कौन सा बाएं माता पिता हो जाएगा और जो सही माता पिता

हो जाएगा

उन दो प्रश्नों में से पहला बहुत महत्वपूर्ण है, और दूसरा मुश्किल से बिल्कुल मायने रखता है, हालांकि मुझे समझने के लिए कुछ समय लगा।

आप hg update X का उपयोग कर बाएं-पैरेंट का चयन करें। इससे hg parents (या नए संस्करण hg summary) के आउटपुट में परिवर्तन होता है और अनिवार्य रूप से यह निर्धारित करता है कि विलय से पहले आपकी कार्यशील निर्देशिका में क्या है।

आप hg merge Y का उपयोग करके दाएं-पैरेंट का चयन करें। यह कहते हैं कि परिवर्तनशील वाई के साथ एक्स (कामकाजी निर्देशिका के माता-पिता) को विलय करें। एक विशेष मामले के रूप में, यदि आपके भंडार में केवल दो सिर हैं और आपके माता-पिता पहले से ही उनमें से एक हैं तो वाई दूसरे के लिए डिफ़ॉल्ट होगा।

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

यदि आपके डेवलपर ने विलय के लिए सही माता-पिता को चुना है तो बाएं बनाम दाएं कोई फर्क नहीं पड़ता - केवल वास्तविक अंतर यह है कि जब कोई hg diff या hg log -p या किसी अन्य कमांड का उपयोग करता है जो एक विलय के लिए पैच दिखाता है परिवर्तन, यह बाएं पैरेंट के सापेक्ष प्रदर्शित होता है। हालांकि, यह केवल प्रदर्शन में एक कारक है। कार्यात्मक रूप से वे बहुत समान हैं।

मान लें कि आपके डेवलपर ने सही परिवर्तन किए हैं, तो उसे क्या करना चाहिए था इससे पहले कि वह इसे करने से पहले विलय के परिणाम का परीक्षण कर सके।विलय सॉफ़्टवेयर विकास है, न कि एक परेशान वीसीएस साइड इफेक्ट, और त्रुटि करने से पहले परीक्षण नहीं है।

फिक्सिंग

इसे ठीक करने के लिए, बस मर्ज सही ढंग से फिर से करते हैं। एक पैरेंट सेट करने के लिए hg update का उपयोग करें, दूसरे को चुनने के लिए hg merge का उपयोग करें। सुनिश्चित करें कि आपकी वर्तमान कार्यशील निर्देशिका सही है और फिर प्रतिबद्ध है। hg strip या बेहतर कुछ का उपयोग करके आप अपने खराब विलय से छुटकारा पा सकते हैं, इसे अपडेट करने के बाद hg commit --close-branch के साथ बस अपनी शाखा बंद करें।

बचना

आप कहते हैं कि "तेज ऑटो मर्ज", लेकिन तेज वास्तव में ऑटो-मर्ज नहीं करता है। यह premerge करता है जो स्पष्ट परिवर्तनों का एक बेहद सतर्क संयोजन है, लेकिन यह बहुत सावधान है कि यह आपके लिए भी विलय नहीं करेगा यदि प्रत्येक विलय माता-पिता एक ही क्षेत्र में कोड जोड़ता है क्योंकि यह नहीं पता कि आप कौन सा ब्लॉक कोड चाहते हैं पहले है

आप मर्ज उपकरण विन्यास विकल्प का उपयोग कर एक फ़ाइल-दर-फ़ाइल के आधार पर पूरी तरह से या इस premerge निष्क्रिय कर सकते हैं:

https://www.mercurial-scm.org/wiki/MergeToolConfiguration?highlight=premerge