एसवीएन: प्रत्येक डेवलपर के लिए व्यक्तिगत शाखाएं?

Question

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

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

क्या यह प्रतिमान वास्तव में अच्छा है, और मुझे यह नहीं मिला क्योंकि मुझे कमांड लाइन एसवीएन उपयोग के लिए उपयोग नहीं किया जाता है? या यह एक भयानक प्रणाली थी?

Answer 1

ईमानदार होने के लिए, शायद आप गिट की तरह कुछ और करना चाहते हैं।

http://git-scm.com/

Answer 2

मैं शाखा-प्रति-डेवलपर इस्तेमाल नहीं किया है। विचार मुझे समझ में नहीं आता है।

आरंभ करने के लिए, आपको अपनी विकास टीम को संरेखित करना चाहिए ताकि लोग स्रोत कोड के विभिन्न हिस्सों पर काम कर सकें। यदि हर कोई लगातार एक ही फाइल को संपादित कर रहा है, तो कोई भी तकनीक वास्तव में आपको समन्वयित रखने में मदद नहीं करेगी।

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

मैं अगले संस्करण को विकसित करते समय कोड के वर्तमान संस्करण जारी रखने के लिए शाखाओं का उपयोग करता हूं।

Answer 3

डेवलपर शाखाओं के साथ समस्या शाखाएं ही नहीं है (जैसा कि आपने स्वयं लिखा है) विलय। दुर्भाग्यवश विलय अभी भी svn के साथ एक दर्द है। जबकि डेवलपर शाखाएं समझ में आती हैं कि उपकरण समस्या है। मैं थोड़ी देर के बाद से गिट (जीआईटी एसवीएन के साथ) का उपयोग कर रहा हूं और डेवलपर शाखाएं स्वाभाविक हो गई हैं क्योंकि विलय के लिए समर्थन रास्ता बेहतर है - आप बस विलय कर सकते हैं, और विवादों को विलय करते समय भी वे (मेरे अनुभव से) हैं बहुत कम हो रहा है और बहुत कम दर्दनाक है।

Answer 4

यह भयानक लग रहा था क्योंकि आपको हर बार जांचना था कि आपकी शाखा में अंतिम संशोधन क्या हुआ था।

मैं बस यह इंगित करना चाहता था कि अब आपको यह नहीं करना है: एसवीएन 1.5.0 और ऊपर समर्थन विलय ट्रैकिंग।

Answer 5

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

शाखाएं वास्तव में एक मुद्दा नहीं हैं, समस्याएं विलय का प्रबंधन कर रही हैं। मैंने अतीत में जो किया है वह मर्ज टोकन का उपयोग करता है (मुलायम खिलौना या एक्शन आकृति अच्छी तरह से काम करती है - जो टोकन धारण करता है वह ट्रंक में विलय कर सकता है) या देव विकी पर विलय विलय कर सकता है, मूल रूप से केवल एक देव विलय हो रहा है एक समय में ट्रंक।

Answer 6

मैं लगभग 10 वर्षों के लिए सीवीएस और एसवीएन के साथ काम कर रहा हूं और प्रति डेवलपर शाखा का उपयोग करके मुझे भी डराता है :)।

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

शाखाओं को डेवलपर्स (एसवीएन) या लेखक (सीवीएस) द्वारा ट्रंक में वापस विलय कर दिया गया।

और क्योंकि सबवर्सन 1.5 आसान होने के कारण दैनिक अभ्यास के रूप में विलय करना आसान है, तो विलय करने में कोई समस्या नहीं होनी चाहिए।

Answer 7

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

इसका मतलब है कि आपके पास लोगों के काम का रात का बैक अप है, और डेवलपर के विकास के लिए (आंशिक रूप से) काम करने वाले संस्करण में वापस लौटना आसान है यदि वे गलती करते हैं या उनके कार्यान्वयन के साथ समस्या का सामना करते हैं कलन विधि।

यह भी सुनिश्चित करेगा कि केवल पूरी तरह स्वीकृत और परीक्षण कोड (मान लें कि आप कोड समीक्षा और इकाई परीक्षण कर रहे हैं) मुख्य लाइन में चेक हो जाता है।

मैं मानता हूं कि विलय करने वाला ओवरहेड कठिन हो सकता है, लेकिन यदि हर कोई लगातार (सप्ताह में कम से कम दो बार, दिन में एक बार, मुख्य रूप से अपनी शाखा में एकीकृत करने के लिए डेवलपर से विलय का प्रभाव) शाखा न्यूनतम होना चाहिए।

Answer 8

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

Answer 9

Mercurial का उपयोग करने का प्रयास करें। इसमें डिजाइन द्वारा केंद्रीय भंडार नहीं है।

कोई प्रतिबद्ध संघर्ष भी नहीं है, क्योंकि कोई धक्का नहीं है।

Answer 10

मैंने अपनी आखिरी टीमों (छोटी टीमों: वर्तमान में 4 देव बड़े हैं) पर एसवीएन में एक समान शाखा रणनीति का उपयोग किया है और मेरी वर्तमान टीम पर टीएफएस में दृष्टिकोण अपनाया है।

हम प्रति बग ट्रैकर कार्य आइटम शाखा करते हैं।

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

प्रैक्टिस में, मुझे यह परिणाम छोटे बदलावों में काफी बार ट्रंक में विलय कर पाए गए हैं। मेरी टीमों की छोटी प्रकृति को देखते हुए, हम शायद ही कभी एक दूसरे के पैर पर विलय कर रहे हैं, इसलिए विवाद आमतौर पर समस्याग्रस्त नहीं होते हैं।

मैं कहूंगा, यह प्रणाली एसवीएन में काफी आरामदायक थी: टीएफएस में कम जो एसवीएन 1.4 के रूप में विलीन रूप से विलय को संभालने में प्रतीत नहीं होता है, यहां तक ​​कि अकेले 1.5+ दें।

Answer 11

सबवर्सन साथ

, मैं का उपयोग करें "काम शाखा (ते)" जो एक टीम के स्वामित्व में है और टीम के सभी सदस्यों के महान Version Control for Multiple Agile Teams आलेख में वर्णित और नीचे दर्शाया गया है द्वारा साझा कर रहे हैं:

मैं पूरी तरह से पूरे पेपर को पढ़ने की सिफारिश करता हूं, यह वाकई पढ़ने योग्य है।

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

Answer 12

मैंने अतीत में एक समान अभ्यास का उपयोग किया है।

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

Answer 13

आपके प्रतिमान को उपकरण के संबंध में फिट होना आवश्यक है। सबवर्सन उस प्रतिमान के लिए गलत उपकरण है क्योंकि सबवर्सन में विलय एक पिटा है। अपना प्रतिमान बदलें या गिट या Mercurial पर स्विच करें।

Answer 14

हम दिन-प्रतिदिन के संचालन के लिए एक एकल विकास शाखा का उपयोग करते हैं। हमने अनुभव के माध्यम से सीखा है कि जब एक डेवलपर वास्तव में बड़ी परियोजना पर काम कर रहा है जो कई मॉड्यूल का विस्तार करता है, तो उसे अपनी शाखा बनाना चाहिए और उस से काम करना चाहिए। अन्यथा, हमें एक एकल एसवीएन शाखा से कोई समस्या नहीं चल रही है, और यह चीजों को बहुत सरल बनाता है। चेतावनी, हमारे पास 3 डेवलपर्स + कभी-कभी ठेकेदार की एक छोटी सी टीम है।