संस्करण नियंत्रण: फीचर विकास

के आस-पास एक बग फिक्स/कोड एन्हांसमेंट को स्थानांतरित करना मेरे पास Mercurial (संभवतः अन्य डीवीसीएस पर लागू) से संबंधित वर्कफ़्लो प्रश्न है।संस्करण नियंत्रण: फीचर विकास

रेपो विशिष्ट डिफ़ॉल्ट/स्थिर सेटअप का उपयोग करके स्थापित किया गया है।

आपको एक नई सुविधा बनाने के साथ काम सौंपा गया है और उम्मीद है कि इसमें कुछ समय लगेगा (माह +)। इस सुविधा पर काम करते समय, आप एक बग में आते हैं जो आपको लगता है कि इसे ठीक से बाद में उत्पादन के लिए तय किया जाना चाहिए। या शायद, आप कुछ कोड देखते हैं जिन्हें बेहतर तरीके से दस्तावेज किया जा सकता है।

मेरी धारणा यह है कि आप डिफ़ॉल्ट रूप से फिक्स करते हैं और फिर स्थिर पर स्विच करते हैं और फिर से ठीक करते हैं (हाथ से या पैच लगाने से)। क्या यह सही है या आप तुरंत स्थिर पर स्विच करना चाहिए, वहां परिवर्तन करें और फिर डिफ़ॉल्ट रूप से स्थिर विलय करें?

पैच का उपयोग करना मुझे और अधिक समझ में आता है। आप विशेष रूप से बग फिक्स के लिए प्रतिबद्ध बना सकते हैं और अपनी सुविधा पर उस पैच को लागू कर सकते हैं। मेरा मतलब है कि अगर बग बहुत बुरा नहीं है, तो तत्काल आवश्यकता और आपके प्रवाह को तोड़ने की कोई आवश्यकता नहीं है। सही?

तो, आप इस स्थिति को कैसे संभालेंगे?

धन्यवाद

स्रोत

2011-01-13 jbarreiros

नोट: विम चेरी-पिकिंग के लिए एक व्यवहार्य विकल्प प्रस्तावित करता है जिसे आप विचार कर सकते हैं। – VonC

आप, शाखा बिंदु (संशोधन B) वापस जा सकते हैं वहाँ (संशोधन X) बग को ठीक और फिर दोनों शाखाओं में ठीक (M1 और M2) विलय:

-----B--o----o---M1----o---> stable 
    |  /
    |---------X bugfix 
    |   \ 
    \--o---o----M2----o-----> feature

इस तरह से आप कर सकते हैं सामान्य hg merge संचालन के साथ प्रत्येक शाखा में अपना फ़िक्स प्राप्त करें; कोई पैचिंग, प्रत्यारोपण या एमक्यूइंग आवश्यक नहीं है।

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

स्रोत

2011-01-13 20:05:06

हूजाह, उस व्यक्ति के लिए जो समझता है कि "कहां" आप परिवर्तन करते हैं, परिवर्तन के रूप में महत्वपूर्ण है। किसी भी इतिहास पुनर्लेखन से बचने के लिए –

+1। – VonC

मैं समझ सकता हूं कि कोई इतिहास को डुप्लिकेट क्यों नहीं करना चाहता, लेकिन सरल सुधारों के लिए, "प्रत्यारोपण" सबसे आसान तरीका प्रतीत होता है, जो समयरेखा को अच्छी और रैखिक रखने के लिए प्रतीत होता है, जहां एक विलय समयरेखा को जटिल बना सकता है। क्या मैं सिर्फ आलसी हूँ? – jbarreiros

एक बार जब आप अपने छोटे ठीक बना दिया है के लिए प्रतिबद्ध हैं, तो आप Hg Transplant Extension का उपयोग करें और किसी अन्य शाखा पर है कि एक ही फिक्स रिपोर्ट कर सकते हैं।

यदि यह उचित नहीं है, तो अन्य चेरी-पिकिंग संभावनाएं SO प्रश्न "Mercurial cherry picking changes for commit" में विस्तृत हैं।

स्रोत

2011-01-13 17:45:08 VonC

धन्यवाद वॉनसी, प्रत्यारोपण विस्तार बस अच्छी तरह से करेगा। लिंक के लिए भी धन्यवाद। – jbarreiros

कोई बेहतर वर्कफ़्लो के साथ इससे बच सकता है। नीचे विम का समाधान बेहतर है क्योंकि आप अलग-अलग हैश-आईडी के साथ अपने रेपो में दो बार एक ही बदलाव के साथ समाप्त नहीं होते हैं। दो स्थानों में एक ही बदलाव करना उन स्थानों की अंतिम स्वचालित रूप से विलय कर देता है। –

@ Ry4an: मैं सहमत हूं। फिर भी, मुझे गिट उपयोगकर्ता की तरह बहुत अधिक कारण है;) – VonC

उत्तर

संबंधित मुद्दे