तोड़फोड़ की तुलना में मर्क्यूरियल में ब्रांचिंग और विलय आसान क्यों है?

Question

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

मेरा सवाल इस तथ्य से उपजा है कि मर्क्यूरियल के साथ आप सबवेर्शन / सीवीएस सेंट्रल रिपॉजिटरी के समान काम करने का तरीका अपना सकते हैं और सब कुछ ठीक चलेगा। आप एक ही शाखा पर कई मर्ज कर सकते हैं और आपको प्रतिबद्ध संख्याओं और टैग नामों के साथ कागज के अंतहीन स्क्रैप की आवश्यकता नहीं होगी।

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

सभी के काम करने के तरीके में बुनियादी अंतर होना चाहिए।

Answer 1

सबवर्सन (और सीवीएस) में, रिपॉजिटरी पहले और सबसे महत्वपूर्ण है। गिट और मर्क्यूरियल में वास्तव में उसी तरह एक रिपॉजिटरी की अवधारणा नहीं है; यहाँ परिवर्तन केंद्रीय विषय हैं।

+1

सीवीएस / एसवीएन में परेशानी इस तथ्य से आती है कि इन प्रणालियों को परिवर्तनों के पितृत्व को याद नहीं है। Git और Mercurial में, न केवल एक प्रतिबद्ध कई बच्चे हो सकते हैं, इसमें कई माता-पिता भी हो सकते हैं!

यह आसानी से एक ग्राफिकल टूल का उपयोग करके देखा जा सकता है, gitkया hg view। निम्नलिखित उदाहरण में, शाखा # 2 को कमिट ए में # 1 से लिया गया था, और तब से एक बार (एम में, कमिट बी में विलय कर दिया गया है):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

ध्यान दें कि A और B के दो बच्चे हैं, जबकि M के दो माता-पिता हैं । ये संबंध भंडार में दर्ज हैं । मान लीजिए कि शाखा # 2 के अनुरक्षक अब शाखा # 1 से नवीनतम परिवर्तनों को मर्ज करना चाहते हैं, वे इस तरह के रूप में एक आदेश जारी कर सकते हैं:

$ git merge branch-1

और उपकरण को स्वचालित रूप से पता चल जाएगा कि आधार B है - क्योंकि यह प्रतिबद्ध M में दर्ज किया गया था, # 2 की नोक के पूर्वज - और यह है कि B और C. CVS के बीच जो कुछ भी हुआ है, उसे इस जानकारी को रिकॉर्ड नहीं करना है। , और न ही संस्करण 1.5 से पहले SVN। इन प्रणालियों में, ग्राफ ऐसा दिखेगा:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

जहाँ M, A और B के बीच होने वाली हर चीज़ के लिए केवल एक विशाल "विवादित" प्रतिबद्ध है, जो एम। के शीर्ष पर लागू होता है कि विलेख किए जाने के बाद, जहाँ M का कोई निशान नहीं बचा है (संभवतः मानव-पठनीय टिप्पणियों में) से उत्पन्न हुआ था, न ही कितने कमिट एक साथ ढह गए थे - इतिहास को और अधिक अभेद्य बना दिया।

इससे भी बदतर, एक दूसरे मर्ज का प्रदर्शन दुःस्वप्न बन जाता है: किसी को यह पता लगाना होगा कि पहले मर्ज के समय मर्ज का आधार क्या था (और किसी को यह जानना होगा कि पहले स्थान पर मर्ज हो गया है!), फिर उसे प्रस्तुत करें! उपकरण की जानकारी ताकि वह एम के शीर्ष पर A..B को फिर से चलाने की कोशिश न करे। यह सब काफी मुश्किल है जब करीबी सहयोग में काम कर रहा है, लेकिन वितरित वातावरण में बस असंभव है।

ए (संबंधित) समस्या यह है कि सवाल का जवाब देने का कोई तरीका नहीं है: "क्या एक्स में बी शामिल है?" जहां B एक संभावित महत्वपूर्ण बग फिक्स है। तो, क्यों न केवल उस जानकारी को कमिट में दर्ज किया जाए, क्योंकि यह मर्ज के समय पर जानी जाती है !

P.-S. - मुझे SVN 1.5+ मर्ज रिकॉर्डिंग क्षमताओं के साथ कोई अनुभव नहीं है, लेकिन वर्कफ़्लो वितरित सिस्टम की तुलना में बहुत अधिक विपरीत प्रतीत होता है। यदि वास्तव में ऐसा है, तो शायद ऐसा इसलिए है - जैसा कि ऊपर की टिप्पणी में बताया गया है - ध्यान स्वयं परिवर्तनों के बजाय रिपॉजिटरी संगठन पर केंद्रित है।

Comments

एसवीएन 1.5+ वास्तव में मर्ज कमिट पर एक एसवीएन संपत्ति लगाएगा, जिसमें मर्ज किए गए कमिट्स को सूचीबद्ध किया जाएगा, दूसरे शब्दों में एबी। तो आपके पास एक ही जानकारी है।

— साइमन डी

एक प्रकार का। तकनीकी रूप से, एसवीएन का मर्ज ट्रैकिंग उस चीज के समान है, जिसे Git "चेरी-पिकिंग" कहता है, अतिरिक्त जादू के साथ उपयोगकर्ता पर इसे आसान बनाता है; मर्ज करते समय यह Git, Hg और Bzr से क्या शब्दार्थ से अलग है। मुझे लगता है कि जब तक आप डीएजी ( egain.net/articles/git-for-computer-scientists ) की परवाह नहीं करते हैं तब तक व्यवहार में बहुत अंतर नहीं आता है ।

— डेमियन डिडरिन

धिक्कार है कि कोई +100 बटन नहीं है। धन्यवाद।

— चार्ली फूल

मैं मानती हूं कि SVN 1.5 सुविधा जिसके बारे में आप बात कर रहे हैं वह svn:mergeinfoसंपत्ति का उपयोग है ?

— MatrixFrog

@ मेट्रिक्सफ्रॉग: हाँ, यह बस क्या svn:mergeinfoकरता है।

— तिल

Answer 2

क्योंकि सबवर्सन (कम से कम संस्करण 1.4 और उससे नीचे) का विलय नहीं किया गया है। तोड़फोड़ के लिए, विलय मूल रूप से किसी भी कमिट के समान होता है, जबकि अन्य संस्करण नियंत्रण जैसे कि जीआईटी, जो विलय किए गए हैं, उन्हें याद किया जाता है।

Answer 3

पहले से ही प्रदान किए गए किसी भी उत्तर से अछूता, एचजी ने बेहतर मर्ज क्षमताओं की पेशकश की क्योंकि यह परिवर्तन ( hginate.com ) को विलय करते समय अधिक जानकारी का उपयोग करता है :

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

बेशक, यह याद रखना कि अंतिम विलय क्या था (यहां दिए गए अधिकांश उत्तरों द्वारा संबोधित बिंदु) भी एक बड़ी जीत है।

दोनों सुधार, हालाँकि, तोड़फोड़ के बाद से संदिग्ध हैं। 1.5+ स्टोर में अतिरिक्त मर्ज की जानकारी को तोड़फोड़ के गुणों के रूप में संग्रहीत करता है: यह जानकारी उपलब्ध है, कोई स्पष्ट कारण नहीं है कि तोड़फोड़ मर्ज सफलतापूर्वक एचजी या गिट के रूप में मर्ज को लागू नहीं कर सका। मुझे नहीं पता कि यह क्या करता है, हालांकि, लेकिन यह निश्चित रूप से लगता है कि तोड़फोड़ डेवलपर्स इस मुद्दे पर पहुंचने के लिए अपने रास्ते पर हैं।

Answer 4

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

Answer 5

सबवर्सन (और सीवीएस) में, रिपॉजिटरी पहले और सबसे महत्वपूर्ण है। गिट और मर्क्यूरियल में वास्तव में उसी तरह एक रिपॉजिटरी की अवधारणा नहीं है; यहाँ परिवर्तन केंद्रीय विषय हैं।

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

Answer 6

मेरे पास केवल तोड़फोड़ का अनुभव है लेकिन मैं आपको बता सकता हूं कि TortoiseSVN में मर्ज स्क्रीन बुरी तरह से जटिल है। सौभाग्य से वे एक सूखी रन बटन शामिल करते हैं ताकि आप देख सकें कि क्या आप इसे सही कर रहे हैं। जटिलता यह है कि आप क्या विलय करना चाहते हैं, के विन्यास में कहां है। एक बार जब आप मर्ज के लिए स्थापित हो जाते हैं तो मर्ज आम तौर पर ठीक हो जाता है। फिर आपको किसी भी और सभी संघर्षों को हल करने की आवश्यकता है और फिर रिपॉजिटरी में काम करने वाली कॉपी में अपना विलय कर दें।

यदि मर्क्यूरियल मर्ज के विन्यास को आसान बना सकता है तो मैं कह सकता हूं कि विलय को 100% आसान बना देगा फिर सबवर्सन।