DVCS, Mercurial पर स्विच करना

किस उद्देश्य से और किसके लिए

यह लेख DVCS के प्रमुख लाभों का सारांश है।
मैंने डीवीसीएस (यानी, मर्क्यूरियल) पर स्विच करने के लाभों के बारे में सभी तर्क दिए हैं और मैं उन लोगों के लिए यह स्पष्ट करने की कोशिश करूँगा, जिनके पास किसी भी डीवीसीएस के साथ काम करने का व्यावहारिक अनुभव नहीं है।

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

वितरित सिस्टम पर स्विच क्यों? संक्रमण की खुशियाँ

स्थानीय कार्य

पहला कारण जो सभी स्रोतों में इंगित किया गया है वह स्थानीय स्तर पर काम करने की क्षमता है।
एक और पहला कारण गति है। यह हास्यास्पद लग सकता है: "ठीक है, किस तरह की गति के लिए आप मुझे माफ कर देते हैं जब आप इसे करते हैं या अपडेट करते हैं या अन्य ऑपरेशन करते हैं।" यह वास्तव में ऐसा है, इसलिए ऐसा नहीं है कि आपके द्वारा किए गए संशोधनों के केंद्रीकृत नियंत्रण प्रणालियों में अक्सर ऐसा नहीं होता है और अक्सर अच्छी तरह से अपडेट होते हैं या दूरस्थ रिपॉजिटरी के साथ अन्य जोड़तोड़ करते हैं। लेकिन यहां छड़ी 3 छोरों में है। सबसे पहले, DVCS आपको रिपॉजिटरी के साथ अधिक निकटता से काम करने के लिए धक्का देता है। दूसरे, गति में अंतर हड़ताली है। लगभग किसी भी ऑपरेशन को करने के बारे में बिल्कुल भी सोचने की ज़रूरत नहीं है और गति को किसी भी तरह से मापा नहीं जाता है, यानी गति तात्कालिक है।

स्थानीय आवागमन करता है

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

ट्रस्ट पदानुक्रम

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

रिपोजिटरी प्रोजेक्ट मॉडल

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

तैनाती के मामले में, स्रोत कोड प्रदान करने वाली तैनाती कई मायनों में सुरक्षित हैं। जब तैनाती सबसे आदिम तरीके से होती है, तो svnup या svncheckout द्वारा svn में जो किया जाता है वह यहां सुरक्षित है। यह मुश्किल है, यहां तक ​​कि असंभव भी है, क्योंकि आप एक युद्ध सर्वर या कुछ "खतरनाक" सर्वर पर ले जाना चाहते हैं। केवल एक रिपॉजिटरी लें जिसे आप तैनात करते हैं, और हमें याद है कि रिपॉजिटरी शब्द "प्रोजेक्ट" का पर्याय है, अर्थात, सबसे खराब स्थिति में, आपकी परियोजना को नुकसान होगा। प्लसस की एक संख्या है, सबसे पहले, नेस्टेड .svn उपनिर्देशिका की कमी, जो हालांकि svn अब ऐसा नहीं करता है, फिर भी, कई में 1.6 तक के संस्करण हैं।
एक निर्देशिका है, एक उच्च-स्तरीय .hg निर्देशिका, और ये सेवा उपनिर्देशिकाएँ उन सभी स्थानों पर नहीं दिखाई देती हैं जहाँ यह आवश्यक है और आवश्यक नहीं है, और एक दुष्ट हाथ उनके अंदर घुसने का जोखिम इस तथ्य के कारण कम हो जाता है कि ये निर्देशिकाएँ एक ही स्थान पर हैं और सुरक्षा के लिए केवल एक ही स्थान है। हर उपनिर्देशिका में नहीं।
चूंकि परियोजनाएं स्वयं अलग फ़ोल्डर हैं, इसलिए आप उन्हें आसानी से जगह से कॉपी कर सकते हैं और उन्हें अपनी फाइल सिस्टम पर स्थानांतरित कर सकते हैं। यह svn में एक ज्ञात समस्या है जब आप पहली बार एक उच्च-स्तरीय परियोजना की जांच करते हैं और फिर परियोजनाओं के तहत अंदर हेरफेर करते हैं। यह कई समस्याओं का कारण बनता है। Svn द्वारा नियंत्रित पदानुक्रम के अंदर निर्देशिकाओं को स्थानांतरित करने का विचार एक बहुत बुरा विचार है और बहुत अधिक सिरदर्द हो सकता है और एक विशेषज्ञ की आवश्यकता होती है जो यह अच्छी तरह जानता है कि सब कुछ svn में कैसे काम करता है ताकि स्थिति को बाद में हल किया जा सके।

ऑडिट डिलीवरी की विश्वसनीयता

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

शाखाओं का साने मॉडल। मर्ज, शाखा (मर्ज, शाखाएं)

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

Ssh रिपॉजिटरी एक्सेस

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

एकीकरण और केंद्रीय रिपॉजिटरी और प्रतिकृति को तैनात करना आसान है

दूरस्थ रिपॉजिटरी को बढ़ाने में कोई विशेष समस्या नहीं है जो आपके पुश को स्वीकार करेगा या आपको पूल देगा - नहीं।

सैद्धांतिक रूप से सबसे अच्छी मापनीयता

बेहतर स्केलेबिलिटी के लिए कुछ प्रशंसा DVCS। यही है, जब वे किसी कारण से एक सर्वर को अब और सामना नहीं कर सकते हैं, तो इसका विस्तार करना आसान हो सकता है, 2, 5 और 10 से कनेक्ट करना आसान है, क्योंकि इससे कुछ फायदा होता है, क्योंकि मैंने ऐसी अड़चनों को नोटिस नहीं किया था कि सर्वर एक प्लग था। यहां, "केंद्रीय" के लिए सर्वर की आवश्यकता है (क्योंकि यह आपके समान केंद्रीय है, हर कोई इसे एक्सेस करता है) एक रिपॉजिटरी है, इसके लिए एक्सेस की आवश्यकताएं हैं, और प्रदर्शन बहुत अधिक हैं। वे उसके साथ अक्सर संवाद नहीं करते हैं।

डीवीसीएस पर स्विच करते समय आप क्या खोते हैं

टार की एक बूंद। सादगी का नुकसान

सबसे पहली चीज जो आप खोते हैं, और निश्चित रूप से गंभीर नुकसान, मॉडल की सादगी का नुकसान है। यदि svn में सब कुछ सरल है, तो एक जगह है जहां आप प्रतिबद्ध हैं, एक ऐसी जगह है जहां आप अद्यतन करते हैं कि इसकी स्थिति समझ में आती है और अधिक या कम पूर्वानुमान है, अब मॉडल पूरी तरह से बदल गया है। आपके पास किसी प्रकार का स्वतंत्र भंडार है। यहां तक ​​कि उन्नत विशेषज्ञ जो हर चीज को सैद्धांतिक रूप से समझते हैं, इस परिष्कृत मॉडल में अपने माथे से चिपके हुए लगते हैं, उदाहरण के लिए, यह विचार कि आपका भंडार खदान से पूरी तरह से अलग है और मेरे संस्करण संख्या का आपके संस्करण संख्या से कोई लेना-देना नहीं है, आसानी से आपके सिर में नहीं बैठती है।

सशर्त माइनस - आपको डॉक पढ़ने की आवश्यकता है

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

शाखा करने के तरीके

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

इस पद्धति के नुकसान भी मौजूद हैं, और कुछ इसी तरह से इन नुकसानों के कारण व्यावहारिक रूप से उपयोग नहीं किए जाते हैं। सबसे पहले, परियोजना प्रबंधन के दृष्टिकोण से भंडार की एक स्टैंड-अलोन कॉपी कभी-कभी एक परेशानी वाली बात होती है। शायद आप जो कार्यक्रम विकसित कर रहे हैं, वह वास्तव में पसंद नहीं है जब आपकी परियोजनाएं एक जगह से दूसरी जगह पर पहुंचती हैं, जब आप किसी परीक्षण या विकास संस्करण या अस्थिर संस्करण पर जाते हैं और इसके लिए परियोजना के मार्ग में बदलाव की आवश्यकता होती है, तो कुछ स्थितियों में यह बहुत महत्वपूर्ण नहीं है। सुविधाजनक। दूसरी समस्या यह है कि यदि आपको इस रिपॉजिटरी को सुलभ बनाने की आवश्यकता है, तो आपको 2 बार पुश करने की आवश्यकता है। यही है, आपको अपने मुख्य भंडार को धक्का देने और इस एक को धक्का देने की आवश्यकता है। वे इतने स्वतंत्र हैं कि यह पहले से ही कुछ समस्याएं पैदा करता है, और इन 2 संस्करणों के समर्थन के लिए दोहरे आंदोलन की आवश्यकता होती है, मेरा मतलब है 2 ब्रंच। और एक बड़े रिपॉजिटरी के लिए, क्लोन लेना लाभहीन हो सकता है, हालांकि यहां ऑप्टिमाइज़ेशन तकनीकें हैं, यानी अगर आपका सर्वर बहुत दूर है, तो आपको रिमोट सर्वर से 2 बार क्लोन लेने की ज़रूरत नहीं है, बस एक को जगह लेने के लिए A और फिर जगह से B को एक जगह बनाने के लिए A. Mercurial काफी स्मार्ट है। स्थानीय रूप से फ़ाइलों को कॉपी न करने के लिए, वह लिंक बनाता है, इस मामले में, डिस्क स्थान भी बचा है, और सबसे महत्वपूर्ण बात यह है कि बड़ी रिपॉजिटरी के लिए गति महत्वपूर्ण हो सकती है।

(भी सशर्त) चबाने की दूसरी विधि बुकमार्क मंचिंग है, अर्थात आप किसी भी संशोधन को किसी भी तरह से कॉल कर सकते हैं और इस संशोधन के साथ काम करना शुरू कर सकते हैं। सिद्धांत रूप में, यदि आप बहु-समता की अवधारणा को समझते हैं, तो ये सभी विधियां एक ही चीज के बारे में हैं - "आप विभिन्न शीर्षों का नेतृत्व करते हैं।" बुकमार्क करने के मामले में, आप बस उपयोगी लक्ष्यों में से एक को कॉल करते हैं, उदाहरण के लिए, शाखा ए, और इसके साथ काम करते हैं। कड़ाई से बोलते हुए, आपको इसे कुछ भी कॉल करने की ज़रूरत नहीं है यदि आप इसकी पहचानकर्ता संख्या को याद रखने में सक्षम हैं, तो आप इसे गुमनाम रूप से काम कर सकते हैं और जब आप अपने सिर को केवल अपग्रेड (यहाँ, "अपडेट") कहते हैं, तो यह एक और समान तरीका है। सिर ”) एक निश्चित सिर तक एक निश्चित संशोधन और इस जगह से काम करने तक। बुकमार्क इस पद्धति का सिर्फ एक अनुकूलन है ताकि आप भूल न जाएं कि आपका क्या मतलब है।
अब स्ट्रगलिंग बुकमार्क-एस की खूबियों के बारे में। सबसे पहले, यह एक बहुत तेज और बहुत समझ में आता है। यह क्लोन बनाने की तुलना में बहुत अधिक समझने योग्य तरीका है, हालांकि किसी कारण से क्लोन को डिफ़ॉल्ट पथ माना जाता है। सभी शाखाएं एक ही स्थान पर स्थित हैं, अर्थात्, आप भौतिक प्रतियां (क्लोन) नहीं बनाते हैं।

ऊपर वर्णित नामांकित स्टार्च, चिकित्सकों का कहना है कि यह सबसे सही तरीका है, जिसे एचजी शाखा कहा जाता है - यह विधि तार्किक है, स्पष्ट है और उनकी राय में काफी सुरक्षित है, क्लोन के विपरीत, आपको 2 समानांतर विकास पेड़ों को बनाए रखने की आवश्यकता नहीं है और किसी भी तरह इन 2 पेड़ों के साथ है। , आपको अपने वातावरण के साथ इन परिवर्तनों को प्रतिबिंबित करने की आवश्यकता नहीं है, अर्थात, आपकी परियोजना एक ही स्थान पर है, बस समय-समय पर आप इसे एक शाखा या किसी अन्य शाखा में बदल देते हैं।स्विच प्राथमिक है, ब्रांड के नाम के साथ मानक अपडेट कमांड का उपयोग किया जाता है।
स्वाभाविक रूप से, इस विधि में, दूसरों की तरह, स्विचिंग बहुत तेज़ी से एक ब्रांड से दूसरे ब्रांड में की जाती है, वे वैश्विक हैं और वे शाश्वत हैं, अर्थात, ब्रांड जानकारी मानक व्यापारिक मेटा-डेट (मेटा-सूचना) का हिस्सा है, और वहां ब्रांड जानकारी हमेशा (गिट के विपरीत) होगा। यदि आप अपने रिपॉजिटरी को धक्का देते हैं, तो यह जानकारी किसी भी पोर्टेबिलिटी के साथ, किसी भी क्लोन के साथ धकेल रही है, इसे स्थानांतरित कर दिया गया है और मेरी राय में यह सही तरीका है, और इसे एक विशेष योग्यता कहना मुश्किल है, यह है कि यह कैसे काम करना चाहिए।
इस पद्धति की कमियों में - उन्हें माना जाता है 2. कुछ कहते हैं कि यह एक जटिल तरीका है, बहुत स्पष्ट नहीं है (इससे सहमत होना मुश्किल है)। दूसरी खामी यह है कि यह अत्यधिक मल्टी-अंडरस्टैंडिंग के दृष्टिकोण से चेतावनियों और स्व-निगरानी की इस अवधारणा को थोड़ा खराब कर देता है। जब आप किसी ऐसी चीज को चूसने की कोशिश करते हैं जो एक नया सिर लाती है, तो इस घटना में कि यह नया सिर आपके मुख्य ब्रांड का हिस्सा है, इस मामले में शायद कुछ सोचने के लिए है। बेशक यह आपके समझौतों पर, आपके तर्क पर निर्भर करता है। लेकिन जब आप एक नया ब्रांड बनाते हैं और पहला धक्का आपको बताएगा कि आपके लिए "-f" करना अच्छा होगा क्योंकि एक नया सिर बनाया जा रहा है। इस मामले में, आप वास्तव में एक नया प्रमुख बनाने जा रहे थे, और इस तरह का संदेश हमें आश्चर्यचकित कर सकता है और हमें थोड़ा सावधान कर सकता है, "यह इस तरह की कसम क्यों खाता है, मैं इसे सही करता हूं"।

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

इसके अलावा

रिबेस

रिबेस के साथ समस्या। यह बुरा क्यों है?सूचना खो जाती है। यह एक ऐसी चीज है जो तुरंत स्पष्ट परिणामों के साथ पहली नज़र में है और यह स्पष्ट नहीं है कि ऐसा क्यों करना है। श्रृंखला से आने वाले बड़ी संख्या में आने से बचने के लिए "मैंने लगभग 1 फीचर बनाया", "मैंने लगभग 1 85% फीचर बनाया", आदि। यह सुविधा आपको 1 से 1 सुविधा बनाने और चलाने के लिए अनुमति देती है। रिबास का खतरा यह नहीं है कि हम अपने कई कामों को एक में जोड़ दें, यह रिबेस नहीं है, बल्कि एक बुनियादी ऑपरेशन है। रिबास का खतरा यह है कि हमने 10 कमिट खुद किए और हमने रिपॉजिटरी से एक अपडेट लिया और पेटीएम के 10 कमिट किए। अब, अगर हम ईमानदारी से शादी करते हैं, तो हम देखते हैं कि: यहां हमारे पास रिपॉजिटरी शाखा बिंदु है, पेटिना में परिवर्तन होता है, आपके परिवर्तन होते हैं और अब किसी बिंदु पर वे परिवर्तित हो गए, हमें एक स्रोत मिला। यदि हम रिबेस करते हैं तो हम निम्नलिखित करते हैं।तदनुसार, हम संस्करण नियंत्रण प्रणाली को भूल जाते हैं कि हमने पेटी के समानांतर अपने परिवर्तन किए और उन्हें पेट्या के परिवर्तनों के शीर्ष पर प्रत्यारोपण किया और फिर संस्करण नियंत्रण प्रणाली के लिए परिणाम दिया। इसी समय, यह "प्रत्यारोपण" की प्रक्रिया है, वह हमें कुछ "मध्यवर्ती" प्रतिबद्ध बनाता है, जो पेटी के बाद और हमारे सामने राज्य को सिंक्रनाइज़ करने के लिए कोड में कुछ बदलाव करता है। इस मामले में, तदनुसार, कहानी राक्षसी रूप से खो गई है, अर्थात्, जब हम भविष्य में इस तरह के "चपटा" को देखते हैं, तो हम यह निर्धारित नहीं कर सकते कि यह पेट्या के समानांतर किया गया था और वास्तव में, इस तरह के विलय का कारण था।इसी समय, यह "प्रत्यारोपण" की प्रक्रिया है, वह हमें कुछ "मध्यवर्ती" प्रतिबद्ध बनाता है, जो पेटी के बाद और हमारे सामने राज्य को सिंक्रनाइज़ करने के लिए कोड में कुछ बदलाव करता है। इस मामले में, तदनुसार, कहानी राक्षसी रूप से खो गई है, अर्थात्, जब हम भविष्य में इस तरह के "चपटा" को देखते हैं, तो हम यह निर्धारित नहीं कर सकते कि यह पेट्या के समानांतर किया गया था और वास्तव में, इस तरह के विलय का कारण था।इसी समय, यह "प्रत्यारोपण" की प्रक्रिया है, वह हमें कुछ "मध्यवर्ती" प्रतिबद्ध बनाता है, जो पेटी के बाद और हमारे सामने राज्य को सिंक्रनाइज़ करने के लिए कोड में कुछ बदलाव करता है। इस मामले में, तदनुसार, कहानी राक्षसी रूप से खो गई है, अर्थात्, जब हम भविष्य में इस तरह के "चपटा" को देखते हैं, तो हम यह निर्धारित नहीं कर सकते कि यह पेट्या के समानांतर किया गया था और वास्तव में, इस तरह के विलय का कारण था।
जब रिबेस किया जाता है तो मैं इतिहास कैसे खो सकता हूं? कहानी को खोने का ऐसा मौका है। तो आप एक विशिष्ट संशोधन पर एक विशिष्ट शाखा में रिबास को विभाजित करते हैं, और उस पल के बाद एक और डेवलपर आपकी शाखा से शाखा (नवनिर्मित) का उत्पादन करते हैं, तो यह स्पष्ट नहीं होता है। यह वह स्थिति है जब दोनों डेवलपर सार्वजनिक शाखा के साथ काम करते हैं, इसके लिए इतिहास को फिर से नहीं लिखा जा सकता है। सार्वजनिक शाखाओं के लिए इस तरह के भ्रम से बचने के लिए केवल अपनी निजी शाखाओं पर ही छूट न दें।

कार्यात्मक खोल

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

रिपोजिटरी प्रबंधक

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

रोडोडबोस - साइट पर एक डेमो है, आप इसे कार्रवाई में देख सकते हैं।
phpHgAdmin
अंतर्निहित हल्के वजन वाले वेब सर्वर
hGate
सभी समाधान निःशुल्क हैं।

PS प्रस्तुत सामग्री का उपयोग करते हुए, उमपुतन पॉडकास्ट और आर्थर ओर्लोव द्वारा एक रिपोर्ट परोसी गई

अद्यतन
एक लेख को ठीक किया जहां यह कहा गया था कि बुकमार्क करने की विधि पोर्टेबिलिटी से वंचित है।
वास्तव में, बुकमार्क रिपॉजिटरी के बीच स्वचालित रूप से सिंक्रनाइज़ किए जाते हैं।

यह मर्क्यूरियल-सर्वर के बारे में भी ध्यान देने योग्य था। नाम थोड़ा भ्रमित है, यह एक Mercurial सर्वर नहीं है।
मर्क्यूरियल-सर्वर साझा ssh तंत्र के लिए एक बेहतर प्रबंधन इंटरफ़ेस प्रदान करता है जो hg-ssh में प्रदान किया जाता है।