बल: कई शाखाओं में कैसे एकीकृत किया जाए?

Question

मेरे पास एक पर्सफोर्स रिपोजिटरी में शाखाओं की निम्न स्थिति है: एक मुख्य लाइन "ट्रंक" और दो रिलीज शाखाएं "1.0" और "1.1" हैं। ग्राहक विशिष्ट परिवर्तनों के साथ एक शाखा "ग्राहक" को 1.0 शाखा से बाहर कर दिया गया है। अब ग्राहक संस्करण 1.1 में जाना चाहता है। मैं 1.1 शाखा को ग्राहक शाखा में कैसे विलय कर सकता हूं? ग्राहक विशिष्ट परिवर्तन 1.1 के शीर्ष पर "शीर्ष पर" रहना चाहिए।

1.1      -(1)---(2)---(3) 
         /   \  \ 
        /   \  \ 
trunk 100--(101)-(102)--103---104---105---106---107 
      \ 
      \ 
1.0   ---1-----2--... 
       \ 
        \ 
customer   ---1-----2----*3* 

फ़ाइल मैं देख रहा हूँ के वर्तमान संस्करण ग्राहक शाखा पर संशोधन 3 है:

यहाँ एक प्रभावित फ़ाइल के लिए एक चित्र है।

यदि मैं लक्ष्य "ग्राहक" के साथ शाखा "1.1" को एकीकृत करना चुनता हूं तो मुझे उम्मीद होगी कि दोनों के आम पूर्वज (मुख्य रेखा पर संशोधन 100) पाए जाते हैं और वहां से सभी संशोधन 1.1 शाखा की नोक तक पहुंचते हैं विलय (कोष्ठक में वाले)।

इसके बजाय लाज़िमी केवल 1.1 शाखा है, जो विफल रहता है, क्योंकि यह आवश्यक परिवर्तन करने से पहले मुख्य लाइन पर हुआ याद करते हैं के 3 में संशोधन 1 विलय करने के लिए प्रदान करता है।

मैं लाज़िमी कैसे राजी मैन्युअल रूप से प्रत्येक फ़ाइल को देखने के लिए होने और संशोधन विलय करने के लिए चयनित किए बिना यह करने के लिए कर सकते हैं? शायद शाखा रणनीति रणनीति अनुपयुक्त है? मुझे और क्या करना चाहिए?

Answer 1

एकीकरण आसान बनाने के लिए, मैं एक विशिष्ट शाखाओं trunk_to_custer और 1.1_to_customer और फिर मुद्दा बन जाएगा: शायद

cd customer-workspace 
p4 integ -b trunk_to_customer @change-number-at-which-1.1-was-branched 
p4 resolve 

एक के बीच यहां सबमिट करें, और उसके बाद

p4 integ -b 1.1_to_customer 
p4 resolve 
p4 submit 

Answer 2

जब आप कोशिश अपनी 1.1 शाखा से संशोधन 3 को एकीकृत करने के लिए, बलफोर्स केवल आपको बताएगा कि यह उस विशेष शाखा में परिवर्तनों को एकीकृत कर रहा है - लेकिन संशोधन 1 में पहले से ही ट्रंक संशोधन 101 और 102 शामिल हैं। विलय करते समय, पर्सफोर्स ट्रंक संशोधन 100 को सामान्य पूर्वजों के रूप में पहचानने के लिए पहचान करेगा ict संकल्प।

यह मेरा अनुभव है कि एकीकरण तुम क्या करने की कोशिश कर रहे बस काम करना चाहिए हो गया है। क्या आप अपने एकीकृत स्रोत में अनुपलब्ध परिवर्तन देख रहे हैं (जिसे अनुचित संघर्ष समाधान द्वारा समझाया नहीं जा सकता है), या आप केवल p4 interchanges के आउटपुट को देख रहे हैं?

Answer 3

मैं दृढ़ता से ट्रंक में ग्राहक के परिवर्तन मर्ज करने का प्रयास सुझाव देना चाहेंगे। यह एक रखरखाव दुःस्वप्न जारी रहेगा जब लाइन के कुछ महीनों के नीचे ग्राहक 2.0 + उनके कस्टम परिवर्तनों में अपग्रेड करना चाहता है।

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