ट्रंक से फीचर शाखा को सही तरीके से कैसे अपडेट करें?

Question

SVN book says:

...Another way of thinking about this pattern is that your weekly sync of trunk to branch is analogous to running svn update in a working copy, while the final merge step is analogous to running svn commit from a working copy

मैं इस दृष्टिकोण बड़ी घटनाओं में बहुत अव्यावहारिक, कई कारणों से, ज्यादातर एकीकरण कदम से संबंधित के लिए लगता है।

1. एसवीएन v1.5 से, विलय rev-by-rev किया जाता है। चेरी-मर्ज किए जाने वाले क्षेत्रों को चुनने से हम ट्रंक-शाखा संघर्षों को दो बार हल कर सकते हैं (एक जब एफबी में ट्रंक संशोधन विलय करते हैं, और एक बार फिर विलय करते समय)।
2. रिपोजिटरी का आकार: ट्रंक परिवर्तन बड़े कोड बेस के लिए महत्वपूर्ण हो सकता है, और अन्यत्र ट्रंक से अंतर फ़ाइलों (एसवीएन प्रतिलिपि के विपरीत) की प्रतिलिपि बनाना एक महत्वपूर्ण ओवरहेड हो सकता है।

इसके बजाए, हम वही करते हैं जिसे हम "पुनः-शाखा" कहते हैं। इस मामले में, जब ट्रंक परिवर्तनों का एक महत्वपूर्ण हिस्सा आवश्यक होता है, तो वर्तमान ट्रंक से एक नई सुविधा शाखा खोली जाती है, और विलय हमेशा नीचे होता है (फ़ीचर शाखाएं -> ट्रंक -> स्थिर शाखाएं)। यह एसवीएन पुस्तक दिशानिर्देशों के साथ नहीं जाता है और डेवलपर्स इसे अतिरिक्त दर्द के रूप में देखते हैं।

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

Answer 1

अनुसंधान के बाद:

, Artyom सहित F2F चर्चा, एक SVN पुस्तक मामले खोलने, आदि visionmap पर कई बुद्धिशीलता सत्र के बाद - ऐसा लगता है कि ऐसा करना संभव नहीं है। एक फीचर शाखा पूरी तरह से काम करने की प्रतिलिपि की तरह नहीं है। जैसा कि ऊपर वर्णित है, इसे अपडेट करने का एकमात्र कामकाजी तरीका एक नई शाखा को फिर से बनाना है।

Answer 2

हम एक छोटी कंपनी हैं, इसलिए मुझे नहीं पता कि हमारा समाधान आपकी स्थिति पर लागू होगा या नहीं। हम क्या करते हैं ट्रंक से स्थिर शाखा तक विलय-पुन-संशोधन होता है। हम इसे 2 अलग-अलग तरीकों से कर सकते हैं: - वास्तव में आवश्यक फ़िक्स, हम ट्रंक करने के बाद बस विलय करते हैं - खतरनाक फिक्स/चेंज। हम जब तक परिवर्तन ट्रंक में प्रूफ है कुछ दिनों के इंतजार और फिर हम विलय

इस निरंतर विलय हम संघर्ष की टन से बचने के साथ।

मेरे 2 सेंट।

Answer 3

SVN v1.5 से, विलय रेव-दर-राजस्व किया जाता है। चेरी-उठा क्षेत्रों मर्ज करने ट्रंक शाखा विवादों को सुलझाने के लिए हमें का कारण होगा दो बार (एक जब अमेरिकन प्लान करने के लिए ट्रंक संशोधन विलय, और एक बार फिर जब वापस विलय)

तो फिर तुम कुछ गलत कर रहे हैं ! यदि आप 11-20 में किया है, तो सबसे अच्छा अभ्यास 1-20 विलय करने के लिए FB और वहाँ सब कुछ पाने के लिए है परिवर्तन चाहते

trunk fb 
---------\ 
r1-10 | 
r11-20 | 
r20-30 | 

आम तौर पर:

चलो देखते हैं।

फिर जब एफबी किया जाता है, तो 20-30 मर्ज करें और फिर प्रतिलिपि प्रतिलिपि करने के लिए एफबी (कोई विलय नहीं!)।

आप केवल r11 विलय करने का निर्णय लेते हैं तो प्रतिलिपि अमेरिकन प्लान ट्रंक करने के लिए 30 और: 20, ठीक है, अंत में आप r1 मर्ज करने के लिए की आवश्यकता होगी: 10 और R20।

कोई जिस तरह से आप दो बार परिवर्तन मर्ज है!

copy trunk->fb 
merge 11:20 -> fb. 
merge fb-1:30 -> trunk !!!!! WRONG 

आप ऐसा नहीं कर सकते क्योंकि आप 11:20 दो बार विलय होगा:

मुझे लगता है कि आप शायद निम्न उपाय अपनाते हैं मान। आपको हमेशा में केवल एक दिशा में कोड मर्ज करना चाहिए।

सही तरीका:

copy trunk->fb 
merge 1:20 -> fb. 
merge 21:30 -> fb (now fb=trunk+feature) 
copy fb -> trunk 

संपादित

तो सही कदम हैं:

1. ट्रंक (कॉपी ट्रंक से सुविधा शाखा (अमेरिकन प्लान) बनाएं SVN के साथ शाखा सुविधा के लिए -कोपी)

   FB_0=trunk_0 
   

2. एफबी पर काम करें।

   FB_1=FB_0 + change_a 
   

3. ट्रंक से एफबी तक आने वाले सभी परिवर्तनों को मर्ज करें।

   trunk_1=trunk_0 + tr_change_a; 
   FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a 
   

4. ट्रंक से सभी आगामी मर्ज ना किए गए परिवर्तन अमेरिकन प्लान के लिए अमेरिकन प्लान पर

   FB_3 = FB_2 + change_b 
   

5. मर्ज कार्य करें।

   trunk_2=trunk_1 + tr_change_n; 
   FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b 
   

6. इस बिंदु पर हम एक ऐसी सुविधा शाखा है, जो सभी नई सुविधाओं और ट्रंक में सभी परिवर्तन के होते है। तो हम सिर्फ दो शाखाओं के बीच अंतर की प्रतिलिपि बनाते हैं।

   trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b 
   

   अब एफबी हटा दिया गया है क्योंकि ट्रंक में हमारे सभी बदलाव हैं।

   अंतिम चरण द्वारा निष्पादित किया जाता है:

   svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev . 
   svn ci 
   

   या ट्रंक और शाखा के बीच साधारण अंतर भाषा ले में और उन्हें बराबर बनाने ट्रंक करने के लिए उन्हें डाल दिया।

यह पैटर्न http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature

में वर्णन किया गया अब अगर यह आपके लिए काम नहीं करता है, तो मैं सवाल समझ में नहीं आता।

EDIT2: लिए SVN-1,5

जब SVN-1 के साथ काम कर रहे।5 आप बहुत सरल मर्ज कर सकते हैं:

आप इस सुविधा का शाखा पर काम जब आप बस समय के लिए ट्रंक-समय पर परिवर्तन मर्ज:

$ svn merge /path/to/trunk 
Solve conflicts 
$ svn ci 

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

$ svn merge --reintegrate /path/to/fb 
$ svn ci 

आखिरी में यदि आप दिखाए गए काम करते हैं तो कोई संघर्ष नहीं होना चाहिए।

Answer 4

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

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

यह दृष्टिकोण एसवीएन के नीचे के सभी पक्षों के आसपास काम करता है। इसी तरह की परिस्थितियों के कारण मुझे इस दृष्टिकोण पर स्विच करना पड़ा था। भले ही आप इस दृष्टिकोण का तुरंत उपयोग नहीं करते हैं, आपको कम से कम इसे ASAP का प्रयास करना चाहिए।

Answer 5

मुझे लगता है कि मुझे यहां @Artyom के लिए cudgels लेना है। मुझे लगता है कि बहुत है कि यदि आप

संकल्प करने के लिए ट्रंक शाखा संघर्ष है दो बार

कुछ गलत है। और मुझे लगता है कि @ आर्टिम्स तर्क/समाधान काफी ठोस है।

मैं मामूली बातों @Artyom साफ लिखा हो सकता था मानना ​​है कि अंत में जहां "कॉपी" fbtrunk करने के लिए आप का उपयोग नहीं करते svn copy लेकिन svn merge (या svn merge --reintegrate) है। यह कारण हो सकता है कि आपको Common Branching Patterns में "कॉपी-मर्ज" पैटर्न नहीं मिला है।

जैसा कि मैं समझ रहा हूं कि अब तक आप क्या कर रहे हैं, मुझे यकीन है कि और क्या कहना है।

इसके बजाय, हम क्या हम "फिर से शाखाओं में" कॉल करें:

यहाँ मैं क्या सुनना है। इस मामले में, है जब ट्रंक परिवर्तन का एक महत्वपूर्ण हिस्सा की जरूरत में, एक नई सुविधा शाखा, वर्तमान ट्रंक से खोला है ...

अब आप एक नई शाखा है (हमें यह कॉल b2) कि ट्रंक के बराबर है, है ना? और जहां "आवश्यक ट्रंक परिवर्तनों का महत्वपूर्ण हिस्सा" है? मैं एफबी में मानता हूँ?

...और विलय हमेशा नीचे की ओर है (फ़ीचर शाखाएं -> ट्रंक -> स्थिर शाखाएं)।

लेकिन जैसा कि आपने अभी ट्रंक से बी 2 बनाया है, ट्रंक में विलय करने के लिए कुछ भी नहीं है, नहीं? और आप बी 2 से एफबी में परिवर्तन विलय नहीं कर रहे हैं (क्योंकि यह ट्रंक में विलय विलय के समान होगा ...)। तो "परिवर्तन के महत्वपूर्ण भाग" कैसे एफबी में मिलता है? और एक बार जब वे वहां हों, तो आप उन्हें वापस ट्रंक में क्यों विलय करना चाहते हैं (क्योंकि यह वह जगह है जहां से वे पहले स्थान पर आए थे)?

असल में निम्न लिंक the section called “Tracking Merges Manually" और/या the section called “Merging a Whole Branch to Another"Common Branching Patterns तहत SVN 1.4 प्रलेखन (मुझे पता है, आप SVN 1.4 का उपयोग नहीं करते लेकिन मेरा मानना ​​है कि यह वैसे भी लागू होता है) में उपलब्ध कराई गई कुछ चीजें स्पष्ट करने के लिए मदद कर सकता है। ये लिंक 1.5 प्रलेखन में "गायब" हैं (शायद में नए --reintegrate विकल्प के कारण)।

आप वास्तव में दो बार एक ही बदलाव विलय कर रहे हैं और मुझे लगता है कि आपको ऐसा करने की आवश्यकता नहीं है (ऐसा करने की आवश्यकता है)।