एचजी पुल/पुश/विलय/भ्रष्टाचार के साथ पहले ही विलय या जानबूझकर अनदेखा किए गए परिवर्तनों को चिह्नित करें?

Question

मैं सबवर्सन, जहां मैं परिवर्तन है कि पहले से ही विलय कर दिया गया है, या जो अवरुद्ध किया गया है विलय कर दिया जा रहा से ट्रैक करने के लिए svnmerge.py का उपयोग करने के लिए प्रयोग किया जाता रहा हूँ से मर्क्युरियल में संक्रमण कर रहा हूँ:

# Mark change 123 as having already been merged; it will not be merged again, even if a range 
# that contains it is subsequently specified. 
svnmerge.py merge -M -r123 
# 
# Block change 326 from being considered for merges. 
svnmerge.py merge -X -r326 
# 
# Show changes that are available for merging from the source branch. 
svnmerge.py avail 
# 
# Do a catchall merge of the remaining changes. Neither change 123 nor change 326 will be 
# considered for merging. 
svnmerge.py merge 

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

यहां तक ​​कि अभी तक तैयार किए गए परिवर्तनों की सूची देखने का कोई तरीका नहीं है।

जैसा कि मैं अक्सर अन्य डेवलपर्स के बाद चिढ़ा रहा हूं और उन्हें अपने विलय के साथ मदद कर रहा हूं, यह इस तरह की चीजों को करने में सक्षम होने के लिए बेहद सहायक है, जो किसी को "व्यस्त चेरी-पिकिंग" पर विचार कर सकता है; यानी, उन परिवर्तनों को चिह्नित करना जिन्हें आप मर्ज करना नहीं चाहते हैं, और फिर शेष का एक बड़ा विलय कर रहे हैं।

Answer 1

मरगुरियल ans Git जैसे डीएजी-आधारित सिस्टम सभी या कुछ भी नहीं हैं: जब आप दो शाखाओं को विलय करते हैं, तो आप आम पूर्वजों और दो शाखाओं के तीन-तरफा विलय करते हैं।

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

इसका मतलब है मर्ज से पहले इसे बाहर वापस करने के लिए है कि एक changeset की अनदेखी करने के लिए एक ही रास्ता:

$ hg backout BAD 

कि शाखा पर changeset रद्द हो जाएगा, ऐसा प्रतीत कि यह नजरिए से बनाया कभी नहीं था बनाने तीन तरह के विलय के।

आप एक पूरे शाखा है, जो आप मर्ज करना है, लेकिन उपेक्षा चाहते हैं, तो आप एक डमी मर्ज कर सकते हैं:

$ hg merge --tool internal:local --non-interactive 
$ hg revert --all --rev . 

कि पहले पुरानी स्थिति में मर्ज माध्यम से चला जाता है, लेकिन reverts वापस करने से।

---

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

$ hg update 2.1 
$ hg merge 2.0 
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123" 

$ hg update 2.2 
$ hg merge 2.1 
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123" 

तो आप चाहिए:

$ hg update 2.0 
# fix bug 
$ hg commit -m "Fixed issue-123" 

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

$ hg update 3.0 
$ hg merge 2.2 --tool internal:local --non-interactive 
$ hg revert --all --rev . 
$ hg commit -m "Dummy merge with 2.2" 

सुनिश्चित करता है कि आप हमेशा उपयोग कर सकते हैं

$ hg log -r "::2.2 - ::3.0" 

2.2 शाखा में परिवर्तन देखने के लिए जो अभी तक 3.0 में विलय नहीं हुआ है।