svn क्या DVCS में विलय आसान बनाता है?




git version-control (8)

मैंने सॉफ्टवेयर पर जोएल में पढ़ा:

वितरित संस्करण नियंत्रण के साथ, वितरित हिस्सा वास्तव में सबसे दिलचस्प हिस्सा नहीं है।

दिलचस्प हिस्सा यह है कि ये सिस्टम संस्करणों के संदर्भ में परिवर्तनों के संदर्भ में सोचते हैं।

और HgInit :

जब हमें विलय करना होता है, तो सबवर्जन दोनों संशोधनों को देखने की कोशिश करता है- मेरा संशोधित कोड, और आपका संशोधित कोड- और यह अनुमान लगाने का प्रयास करता है कि उन्हें एक बड़ी अपवित्र गड़बड़ी में कैसे एक साथ नष्ट करना है। यह आम तौर पर विफल रहता है, "मर्ज विवाद" के पृष्ठों और पृष्ठों का उत्पादन करता है जो वास्तव में संघर्ष नहीं होते हैं, बस उन जगहों पर जहां सबवर्सन हमारे द्वारा किए गए कार्यों को समझने में असफल रहा।

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

एसवीएन के रिपोजिटरी फ़ोल्डर को देखकर, मुझे लगता है कि सबवर्जन प्रत्येक संशोधन को परिवर्तन के रूप में बनाए रखता है। और जो मुझे पता है, एचजी दोनों परिवर्तन और स्नैपशॉट का उपयोग कर रहा है, जबकि गिट पूरी तरह से डेटा स्टोर करने के लिए स्नैपशॉट का उपयोग कर रहा है।

अगर मेरी धारणा सही है, तो अन्य तरीकों से होना चाहिए जो डीवीसीएस में विलय को आसान बनाते हैं। वो क्या है?

* अद्यतन करें:

  • मुझे तकनीकी परिप्रेक्ष्य में अधिक दिलचस्पी है, लेकिन गैर-तकनीकी परिप्रेक्ष्य के उत्तर स्वीकार्य हैं
  • सुधार:
    1. गिट का वैचारिक मॉडल पूरी तरह से स्नैपशॉट्स पर आधारित है। स्नैपशॉट्स को अन्य स्नैपशॉट्स के डिफ के रूप में संग्रहीत किया जा सकता है, यह सिर्फ इतना है कि diffs पूरी तरह से भंडारण अनुकूलन के लिए हैं। - राफल डॉउगर्ड की comment
  • गैर-तकनीकी परिप्रेक्ष्य से:
    1. यह बस सांस्कृतिक है: अगर विलय कठिन होता तो एक डीवीसीएस बिल्कुल काम नहीं करेगा, इसलिए डीवीसीएस डेवलपर्स विलय को आसान बनाने में काफी समय और प्रयास करते हैं। सीवीसीएस उपयोगकर्ता ओटीओएच का उपयोग विलय विलय करने के लिए किया जाता है, इसलिए डेवलपर्स के लिए इसे काम करने के लिए कोई प्रोत्साहन नहीं है। (कुछ उपयोगकर्ता क्यों अच्छा करते हैं जब आपके उपयोगकर्ता आपको कुछ बकवास के लिए समान रूप से भुगतान करते हैं?)
      ...
      संक्षेप में: एक डीवीसीएस का पूरा बिंदु कई विकेन्द्रीकृत भंडार होना है और लगातार बदलावों को लगातार आगे बढ़ाना है। अच्छी विलय के बिना, एक डीवीसीएस बस बेकार है। हालांकि, एक सीवीसीएस अभी भी क्रैपी विलय के साथ जीवित रह सकता है, खासकर अगर विक्रेता अपने उपयोगकर्ताओं को ब्रांचिंग से बचने के लिए शर्त दे सकता है। - जोर्ग डब्ल्यू मिट्टाग का answer
  • तकनीकी परिप्रेक्ष्य से:
    1. इतिहास के एक असली डीएजी रिकॉर्डिंग मदद करता है! मुझे लगता है कि मुख्य अंतर यह है कि सीवीसीएस ने हमेशा कुछ माता-पिता के साथ एक बदलाव के रूप में विलय रिकॉर्ड नहीं किया, कुछ जानकारी खो दी। - tonfa की comment
    2. विलय ट्रैकिंग के कारण , और अधिक मौलिक तथ्य यह है कि प्रत्येक संशोधन अपने माता-पिता को जानता है । ... जब विलय करने सहित प्रत्येक संशोधन (प्रत्येक प्रतिबद्धता), अपने माता-पिता को जानें (उन कार्यों को मर्ज करने के लिए जिसका मतलब है कि एक से अधिक माता-पिता को रखना / याद रखना, यानी मर्ज ट्रैकिंग), आप पुनरीक्षण के आरेख (डीएजी = डायरेक्ट एसाइक्लिक ग्राफ) का पुनर्निर्माण कर सकते हैं इतिहास। यदि आप संशोधन के ग्राफ को जानते हैं, तो आप उन मज़ेदारों के सामान्य पूर्वजों को पा सकते हैं जिन्हें आप विलय करना चाहते हैं। और जब आपका डीवीसीएस खुद को जानता है कि आम पूर्वजों को कैसे ढूंढें , तो आपको इसे एक तर्क के रूप में प्रदान करने की आवश्यकता नहीं है, उदाहरण के लिए सीवीएस में।

      ध्यान दें कि दो (या अधिक) के एक से अधिक आम पूर्वज हो सकते हैं। गिट तथाकथित "रिकर्सिव" मर्ज रणनीति का उपयोग करता है, जो कि एक वर्चुअल / प्रभावी आम पूर्वज (कुछ सरलीकरण में) के साथ छोड़ा जाता है, और जब तक कि यह सरल 3-तरफा विलय नहीं कर सकता है, तब तक विलय अड्डों (सामान्य पूर्वजों) को विलीन कर देता है। - Jakub Narębski का answer

एसवीएन की तुलना में गिट में विलय कैसे और / या क्यों विलय कर रहा है?


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

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

बहुत अच्छी चीजें।


कारण का एक हिस्सा निश्चित रूप से तकनीकी तर्क है कि डीवीसीएस एसवीएन की तुलना में अधिक जानकारी संग्रहीत करता है (डीएजी, प्रतियां), और इसमें एक सरल आंतरिक मॉडल भी है, यही कारण है कि यह अन्य प्रतिक्रियाओं में वर्णित अनुसार अधिक सटीक विलय करने में सक्षम है ।

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

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

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

Mercurial के साथ, आप अपने छोटे incremental प्रतिबद्धताओं के बीच में अक्सर आने वाले परिवर्तनों के साथ विलय कर सकते हैं। परिभाषा के अनुसार यह कम विलय विवादों के परिणामस्वरूप होगा, क्योंकि आप एक अधिक अद्यतित कोडबेस पर काम करेंगे।

और यदि कोई संघर्ष हो जाता है, तो आप मर्ज स्थगित करने और अपने अवकाश पर ऐसा करने का निर्णय ले सकते हैं। यह विशेष रूप से विलय को इतना कम परेशान करता है।


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

इसलिए:

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

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

तो, संक्षेप में:

  • DVCS: es को आसान विलय की आवश्यकता है, उसके आधार पर उनके फीचर सेट हैं। डिजाइन निर्णय जहां ऐसा किया गया था कि इन विलयों को करना आसान है और ट्रैक (डीएजी के माध्यम से), और अन्य विशेषताओं (शाखाओं / टैग / submodules) को लागू करने के लिए लागू किया गया है, न कि दूसरी तरफ।
  • सीवीसीएस: एस में शुरुआत से कुछ विशेषताएं थीं (जैसे मॉड्यूल) जिसने कुछ चीजों को आसान बना दिया, लेकिन रिपो-वाइड विलय को लागू करने के लिए बहुत मुश्किल बना दिया।

सीवी, एसवीएन, गिट और एचजी के साथ कम से कम यह मेरे अनुभव से मुझे लगता है। (शायद अन्य सीवीसीएस हैं: es जो इस चीज़ को भी सही मिला है।)


एक ऐतिहासिक नोट के रूप में, अब-पुरातन PRCS प्रणाली सामान्य पूर्वजों के बारे में भी जानता है और कुशलतापूर्वक विलय कर सकती है, हालांकि इसे वितरित नहीं किया गया था (यह आरसीएस फाइलों के शीर्ष पर बनाया गया था!)। इसका मतलब यह था कि इतिहास को बनाए रखने के दौरान इसे प्रभावी रूप से गिट करने के लिए माइग्रेट किया जा सकता है।


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


विशेष रूप से डीवीसीएस में कुछ भी नहीं है जो विलय को आसान बनाता है। यह बस सांस्कृतिक है: अगर विलय कठिन होता तो एक डीवीसीएस बिल्कुल काम नहीं करेगा , इसलिए डीवीसीएस डेवलपर्स विलय को आसान बनाने में काफी समय और प्रयास करते हैं। सीवीसीएस उपयोगकर्ता ओटीओएच का उपयोग विलय विलय करने के लिए किया जाता है, इसलिए डेवलपर्स के लिए इसे काम करने के लिए कोई प्रोत्साहन नहीं है। (कुछ उपयोगकर्ता क्यों अच्छा करते हैं जब आपके उपयोगकर्ता आपको कुछ बकवास के लिए समान रूप से भुगतान करते हैं?)

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

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

और जब वे एक डीवीसीएस को आजमाते हैं, तो वे जादूगर रूप से "डी" भाग में सभी भलाई को श्रेय देते हैं।

सैद्धांतिक रूप से, केंद्रीकृत प्रकृति के कारण, एक सीवीसीएस में बेहतर विलय क्षमताएं होनी चाहिए, क्योंकि उनके पास पूरे इतिहास का वैश्विक दृष्टिकोण है, क्योंकि डीवीसीएस के विपरीत प्रत्येक भंडार में केवल एक छोटा टुकड़ा होता है।

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

तो, सॉफ्टवेयर इंजीनियरिंग में बाकी सब कुछ की तरह, यह प्रयास की बात है।


एक बिंदु यह है कि एसवीएन विलय को पूरी तरह टूटा हुआ है; http://blogs.open.collab.net/svn/2008/07/subversion-merg.html मुझे संदेह है कि यह चेरी-पिकिंग विलय पर भी svn रिकॉर्डिंग mergeinfo के संयोजन के साथ है। सीमा मामलों को संभालने में कुछ सादे बग जोड़ें, और एसवीएन के मौजूदा पोस्टर बच्चे के रूप में एसवीएन उन्हें सभी डीवीसीएस के विपरीत खराब दिखता है, जो इसे अभी सही मिला है।


वाह, 5 अनुच्छेद निबंधों का हमला!

संक्षेप में, कुछ भी आसान नहीं बनाता है। यह कठिन है, और मेरा अनुभव इंगित करता है कि त्रुटियां होती हैं। परंतु:

  • डीवीसीएस आपको विलय से निपटने के लिए मजबूर करता है, जिसका मतलब है कि आपको मदद करने के लिए मौजूद उपकरणों के साथ खुद को परिचित करने के लिए कुछ मिनट लगाना। वह अकेला मदद करता है।

  • डीवीसीएस आपको अक्सर मर्ज करने के लिए प्रोत्साहित करता है, जो भी मदद करता है।

आपने उद्धृत किया गया हैगिनिट का स्निपेट, दावा करता है कि सबवर्जन तीन-तरफा विलय करने में असमर्थ है और दोनों शाखाओं में सभी परिवर्तनों को देखकर मर्कुरियल विलीन हो जाता है, दोनों गिनती पर बस गलत है।







dvcs