एसवीएन में विक्रेता शाखाओं की शाखाओं को संभालने का सबसे अच्छा तरीका क्या है?

Question

तो, मैं इस के साथ पहले से ही परिचित हूँ:
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html

मेरे सवाल यह है कि आप एक विक्रेता शाखा दोनों एक स्थिर रिलीज और किसी अल्फ़ा/बीटा शाखा है कि आप एकीकृत करना चाहते है कि संभाल करते है?

तो, आप कहते हैं कि आप एसवीएन पुस्तक से मूल उदाहरण का पालन करते हैं। आप होगा:

SVN: // स्थानीय होस्ट/घर/SVN/विक्रेता/libcomplex/वर्तमान
SVN: //localhost/home/svn/vendor/libcomplex/1.0
SVN: // स्थानीय होस्ट/घर /svn/vendor/libcomplex/1.1 (वर्तमान के रूप में ही)

अब, का कहना है कि आप अपने खुद के 'calc' अनुप्रयोग के दो संस्करण हैं:

calc
calc (यह अनिवार्य रूप से ट्रंक == calc 2.0 है) -1.0 (जनता को जारी)

मान लें कि कैल्क-1.0 उपयोग libcomplex 1.0 और कैल्क (ट्रंक में) libcomplex 1.1 का उपयोग किया, जो अभी भी विकसित किया जा रहा है।

libcomplex 1.0 में एक बग है और उस बग को ठीक करने के लिए एक नया संस्करण जारी किया गया है: libcomplex 1.0.1। Libcomplex रखरखावकर्ताओं ने इस बगफिक्स को libcomplex 1.1 में भी शामिल किया है।

आप कैल्क 2.0 जारी करने के लिए तैयार नहीं हैं, इसलिए आपको अपनी विक्रेता शाखा में libcomplex 1.0.1 को एकीकृत करने की आवश्यकता है और फिर बग-फ़िक्स रिलीज़ करने के लिए कैल्क-1.0 अपडेट करें।

यह कहां जाता है?

आप इसे svn: // localhost/home/svn/विक्रेता/libcomplex/current पर नहीं डाल सकते क्योंकि 1.1 वर्तमान में वहां रहता है।

क्या आप svn: //localhost/home/svn/vendor/libcomplex/1.0 को svn: //localhost/home/svn/vendor/libcomplex/1.0.1 पर कॉपी करते हैं और फिर नई रिलीज लाते हैं? इस तरह आप 1.0 और 1.0.1 के बीच कैल्क-1.0 के बीच अंतर को मर्ज करने के लिए svn का उपयोग कर सकते हैं।

Answer 1

अनुशंसित अभ्यास आपकी रिलीज के लिए शाखा बनाना है। इस तरह, इससे कोई फर्क नहीं पड़ता कि आप अपने विक्रेता फ़ोल्डर्स में ट्रंक में क्या परिवर्तन करते हैं। फिर आप 1.0 रिलीज शाखा को libcomplex के 1.0.1 संस्करण के साथ अपडेट कर सकते हैं, और इससे ट्रंक प्रभावित नहीं होगा (कैल्क 2.0)।

यह तब काम नहीं करेगा यदि कैल्क 1.0 और कैल्क 2.0 उसी शाखा में तरफ से रहते हैं।

करने के लिए अगली चीज़ "चालू" नहीं है। बस उस संस्करण को सीधे देखें जिसका आप उपयोग कर रहे हैं। उदाहरण के लिए, अपनी फ़ोल्डर संरचना को इस प्रकार छोड़ दें:

vendor/libcomplex/1.0 
vendor/libcomplex/1.1 
vendor/libcomplex/1.0.1 

और इन फ़ाइलों को कभी ओवरराइट नहीं करें। फिर कैल्क 2.0 libcomplex के संस्करण 1.1 को संदर्भित कर सकता है, और कैल्क 1.0 1.0.1 का संदर्भ दे सकता है।

आपका अंतिम विकल्प, (और वास्तव में अनुशंसित नहीं), svn टैग का उपयोग करना है (complex tags देखें)। वे आपको संस्करणों को मिश्रण और मिलान करने की अनुमति देते हैं, ताकि आप libcplex के पुराने संस्करण के साथ अपने कैल्क 1.0 की पैच रिलीज़ का प्रतिनिधित्व करने के लिए तकनीकी रूप से एक टैग बना सकें।

Answer 2

विक्रेता शाखाओं के पीछे विचार यह प्रतीत होता है कि उन्हें प्रतिबिंबित करना चाहिए कि विक्रेता का अपना भंडार कैसा दिख सकता है।इसलिए, current विक्रेता के ट्रंक का प्रतिनिधित्व करता है, और टैग किए गए संस्करण विक्रेता के अपने टैग का प्रतिनिधित्व करते हैं, जब प्रत्येक संस्करण जारी किया जाता है।

यह देखते हुए, प्रश्न का उत्तर काफी स्पष्ट हो जाता है। 1.0, 1.1 और उसके बाद 1.0.1 जारी करने के लिए, विक्रेता के पास 1.0.x बगफिक्स्ड संस्करणों के लिए एक शाखा है, जबकि 1.1 और बाद में उनके ट्रंक पर संस्करणों पर काम करना जारी है। हमारी विक्रेता शाखा को इस सेटअप को दर्पण करना चाहिए।

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

Answer 3

मैं बाहरी पुस्तकालयों के साथ इस तरह काम करते हैं:

project/myProject/{branches,trunk} 
vendor/libcomplex/1.0 
vendor/libcomplex/1.0.1 
vendor/libcomplex/2.0.0 
mypatched-vendor/libcomplex/1.0 
mypatched-vendor/libcomplex/1.0.1 
mypatched-vendor/libcomplex/2.0.0 

कहाँ vendor/<lib>/<version> कभी नहीं के बाद आयात और mypatched-विक्रेता svn cp vendor/<lib>/<version> mypatched-vendor/<lib>/<version> के साथ शुरू किया गया है बदल जाता है।

अब vendor/libcomplex/1.0 mypatched-vendor/libcomplex/1.0 diffing आपको पैच को केवल आयातित 1.0.1 संस्करण में विलय करने के लिए देना चाहिए।

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

checkout project/myProject/trunk to myprj-trunk आपके द्वारा रन आउट की जांच करें।

svn propedit svn:externals . 
# with 
libcomplex URLTO/mypatched-vendor/libcomplex/1.0 

मैं एक नया lib संस्करण मैं बस एक और जगह और चलाने के अद्यतन करने के लिए है कि संपत्ति को संपादित का परीक्षण करना चाहते हैं। इसका यह भी प्रभाव है कि मैं पेड़ के libcomplex भाग में गलती से कुछ भी नहीं करता है भले ही मैंने डब्ल्यूसी पर कुछ फाइलें बदल दी हों। मुझे उस निर्देशिका के तहत होना चाहिए या विशेष रूप से वहां परिवर्तन करना होगा।

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

बाहरी लोगों के बारे में आखिरी अच्छी बात यह है कि जब एक नई परियोजना शुरू करना और अपस्ट्रीम भी बहुत विकसित होता है और एसवीएन का उपयोग करता है तो आप उस पुस्तकालय को पैच करने की आवश्यकता नहीं होने पर अपस्ट्रीम को बाहरी के रूप में संदर्भित कर सकते हैं। और जब नदी के ऊपर टूट जाता है अपनी परियोजना आप की तरह -rNUM विकल्पों के साथ थोड़ी देर के लिए नदी के ऊपर संस्करण पकड़ कर सकते हैं:

libcomplex -r21 UPSTREAMURLTO/mypatched-vendor/libcomplex/trunk 

एक SVN करने के लिए निश्चित दोष यह है: बाहरी कि बाहरी यूआरएल सभी चेकआउट से एक ही यूआरआई के साथ सुलभ हो गया है है आपकी परियोजना के रूप।

लेकिन बाहरी का उपयोग कर अपने अपने परियोजना रेपो से विक्रेता रखने के लिए रेपो अलग अनुमति देता है।