Mercurial के साथ समवर्ती विकास का प्रबंधन कैसे करें?

Question

यह एक सर्वोत्तम अभ्यास प्रश्न है, और मुझे उम्मीद है कि इसका जवाब "यह निर्भर करता है"। मैं बस अधिक वास्तविक दुनिया परिदृश्य और वर्कफ़्लो सीखने की उम्मीद करता हूं।

सबसे पहले, मैं एक ही परियोजना के लिए अलग-अलग बदलावों के बारे में बात कर रहा हूं, इसलिए कोई सबप्रो कृपया नहीं।

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

यह अगर बी (के लिए ठीक) ए पर निर्भर करता है आप simlply सीआई एक तो बी

ci

मेरा प्रश्न है, जब वे स्वतंत्र (या कम से कम यह अब लगता है) कर रहे हैं कि क्या करना है है तुच्छ है।

मैं निम्नलिखित तरीके के बारे में सोच सकते हैं:

2. उपयोग अनाम या नामित शाखाओं, या बुकमार्क बी के लिए एक अलग क्लोन का प्रयोग करें, एक ही भंडार में।
3. एमक्यू का उपयोग करें (ए के शीर्ष पर बी पैच के साथ)।
4. ब्रांडेड एमक्यू का उपयोग करें (मैं बाद में समझाऊंगा)।
5. उपयोग कई MQ (1.6 के बाद से)

1 और 2 एक excellent blog द्वारा कवर किया जाता द्वारा @Steve Losh एक slightly related question से जुड़े।

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

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

4 आपको चक्कर आ सकता है लेकिन यह सबसे शक्तिशाली और लचीला और स्केलेबल तरीका है। मैं -c के साथ डिफ़ॉल्ट रूप से काम करता हूं क्योंकि मैं कार्य-प्रगति पैच को चिह्नित करना चाहता हूं और उन्हें पुश/पुल करना चाहता हूं, लेकिन यह समझने के लिए एक वैचारिक छलांग लगाती है कि आप एमक्यू रेपो में भी शाखा बना सकते हैं।यहां दिए गए कदम हैं (mq = hg --mq):

1. hg qnew bugA; ए के लिए परिवर्तन करें; hg qref
2. mq branch branchA; hg qci
3. hg qpop; mq up -rtip^
4. hg qnew bugB; बी के लिए परिवर्तन करें; hg qref
5. mq branch branchB; hg qci
6. एक फिर से इस पर काम करने के लिए: hg qpop; mq up branchA; hg qpush

यह इतने सारे कदम उठाने के लिए पागल लगता है, और जब भी आप काम आप करना चाहिए hg qci; hg qpop; mq up <branch>; hg qpush स्विच करना होगा। लेकिन इस पर विचार करें: आप एक ही भंडार में कई नामित रिहाई शाखाएं हैं, और आप उन सभी के लिए एक ही समय में कई परियोजनाओं और बग फिक्स पर काम करने के (आप बेहतर गारंटी इस तरह का काम के लिए बोनस मिल चाहते हैं) की जरूरत है। आप अन्य दृष्टिकोणों के साथ बहुत जल्द खो देंगे।

अब मेरे साथी एचजी प्रेमियों, वहाँ अन्य/बेहतर विकल्प हैं?

---

(अद्यतन) qqueue लगभग # 4 अप्रचलित बनाता है। स्टीव लोश का सुरुचिपूर्ण वर्णन here देखें।

Answer 1

ऐसा लगता है कि इस प्रश्न में सूचीबद्ध लोगों की तुलना में कोई और बेहतर विकल्प नहीं है। तो यहां वे फिर से हैं।

1. प्रति परियोजना एक क्लोन का उपयोग करें।
   • पेशेवर: कुल अलगाव, इस प्रकार परियोजनाओं को स्विच करते समय कोई पुनर्निर्माण नहीं किया जाता है।
   • विपक्ष: टूलचैन को दो क्लोन के बीच स्विच करने की आवश्यकता है।
2. उसी भंडार में अनाम या नामित शाखाओं या बुकमार्क का उपयोग करें।
   • पेशेवर: मानक एचजी (या कोई भी डीवीसीएस) अभ्यास; साफ और स्पष्ट।
   • विपक्ष: स्विचिंग और उसके बाद पुनर्निर्माण से पहले प्रतिबद्ध होना चाहिए।
3. प्रति परियोजना एक पैच (या लगातार कई पैच) के साथ एमक्यू का उपयोग करें।
   • पेशेवर: सरल और आसान।
   • विपक्ष: स्विचिंग और पुनर्निर्माण से पहले qrefresh होना चाहिए; मुश्किल और जोखिम भरा अगर परियोजनाएं ऑर्थोगोनल नहीं हैं।
4. प्रति परियोजना एक एमक्यू शाखा (या qqueue 1.6+ में) का उपयोग करें।
   • सकारात्मक: अल्ट्रा लचीला और स्केलेबल
   • विपक्ष (समवर्ती परियोजनाओं की संख्या के लिए): qrefresh और qcommit स्विच करने से पहले और बाद पुनर्निर्माण करना चाहिए; जटिल लगता है।

हमेशा की तरह, वहाँ कोई जादुई शब्द है, तो ले सकते हैं और इस काम के लिए एक सही चुनें।

---

(अपडेट) जो कोई MQ के साथ प्यार में है, नियमित रूप से शाखाओं के शीर्ष पर MQ का उपयोग कर (# 2 + # 3) शायद सबसे आम और बेहतर अभ्यास है।

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

hg qnew; {coding}; hg qrefresh; {repeat} 
hg qfinish -a 
hg update -r <branch/bookmark/rev> 
hg qimport -r <rev>; {repeat} 

अंतिम चरण के लिए, qimport एक जोड़ने चाहिए एक बार में परिवर्तनों की एक पंक्ति आयात करने के लिए -a विकल्प। मुझे उम्मीद है कि Meister Geisler यह नोटिस करता है :)

Answer 2

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

1. अपनी परियोजना, एक निर्माण प्रक्रिया की कमी है, इसलिए है कि आप परीक्षण और चीजों को सही से चला सकते हैं स्रोत कोड? तब मैं जब मैं किसी अन्य शाखा पर काम करने की जरूरत सिर्फ एक क्लोन है, और hg up आगे पीछे हो लिए परीक्षा की जाएगी।

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

Answer 3

तो सवाल, बिंदु पर, जब आपने सुविधा एक पर काम करना बंद कर, और स्वतंत्र सुविधा बी शुरू करने के लिए कहा जाता है है, क्या वैकल्पिक विकल्पों वहाँ के लिए, कर रहे हैं?

चलिए समेकन के साथ समस्या को देखते हैं, वैसे ही आप थ्रेडेड कोड लिखते हैं- आपको दी गई किसी भी समस्या को हल करने के लिए एक सरल कार्य प्रवाह को परिभाषित करते हैं, और इसे प्रत्येक समस्या पर लागू करते हैं। एक बार यह हो जाने के बाद, Mercurial काम में शामिल हो जाएगा। तो, प्रोग्रामर ए फीचर ए पर काम करेगा। प्रोग्रामर बी फीचर बी पर काम करेगा। बस आप ही होते हैं। (यदि केवल हम मल्टी कोर दिमाग :)

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

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

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

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

केवल आपका विकल्प 1 मुझे समझ में आता है। सामान्य रूप से:

1. आपको किसी अन्य व्यक्ति को इसे देखने से पहले, अपना कोड काम करना चाहिए।
2. एक शाखा पर सिर का पक्ष लें।
3. शाखा और चेक-इन अगर कोई और समस्या उठा रहा है।
4. शाखा यदि आपके स्वचालित सिस्टम या परीक्षकों को केवल आपके कोड की आवश्यकता है।
5. शाखा यदि आप किसी टीम का हिस्सा हैं, तो समस्या पर काम कर रहे हैं। इसे सिर पर विचार करें, 1-4 देखें।

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