वितरित संस्करण नियंत्रण (डिस्ट्रिब्यूटेड वर्जन कंट्रोल): Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Software engineering tool}} सॉफ़्टवेयर विकास में, वितरित संस्करण नियंत्रण...")
 
No edit summary
 
(9 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Short description|Software engineering tool}}
{{Short description|Software engineering tool}}
सॉफ़्टवेयर विकास में, वितरित [[संस्करण नियंत्रण]] (जिसे वितरित संशोधन नियंत्रण के रूप में भी जाना जाता है) संस्करण नियंत्रण का एक रूप है जिसमें संपूर्ण [[कोडबेस]], उसके पूर्ण इतिहास सहित, प्रत्येक डेवलपर के कंप्यूटर पर प्रतिबिंबित होता है।<ref name="git-scm">{{cite book | chapter = About version control | chapter-url = https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control | title = गिट के लिए| first1 = Scott | last1 = Chacon | first2 = Ben | last2 = Straub | edition = 2nd | date = 2014 | publisher = Apress | at = Chapter 1.1 | access-date = 4 June 2019}}</ref> केंद्रीकृत संस्करण नियंत्रण की तुलना में, यह स्वचालित प्रबंधन ब्रांचिंग (संस्करण नियंत्रण) और [[मर्ज (संस्करण नियंत्रण)]] को सक्षम बनाता है, अधिकांश संचालन को गति देता है (धकेलने और खींचने को छोड़कर), ऑफ़लाइन काम करने की क्षमता में सुधार करता है, और बैकअप के लिए एक ही स्थान पर निर्भर नहीं होता है .<ref name="git-scm"/><ref name="Joel 2010" /><ref>{{cite web|title=वितरित संस्करण नियंत्रण का परिचय (सचित्र)|url=https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/|website=www.betterexplained.com|access-date=7 January 2018}}</ref> Git (सॉफ़्टवेयर), दुनिया की सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली,<ref name=":1" />एक वितरित संस्करण नियंत्रण प्रणाली है।
सॉफ़्टवेयर विकास में, '''डिस्ट्रिब्यूटेड वर्जन कंट्रोल''' (जिसे डिस्ट्रिब्यूटेड संशोधन कंट्रोल के रूप में भी जाना जाता है) वर्जन कंट्रोल का रूप है जिसमें संपूर्ण [[कोडबेस]], उसके पूर्ण इतिहास सहित, प्रत्येक डेवलपर के कंप्यूटर पर प्रतिबिंबित होता है।<ref name="git-scm">{{cite book | chapter = About version control | chapter-url = https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control | title = गिट के लिए| first1 = Scott | last1 = Chacon | first2 = Ben | last2 = Straub | edition = 2nd | date = 2014 | publisher = Apress | at = Chapter 1.1 | access-date = 4 June 2019}}</ref> सेंट्रलाइज्ड वर्जन कंट्रोल की तुलना में, यह स्वचालित मैनेजमेंट ब्रांचिंग (वर्जन कंट्रोल) और [[मर्ज (संस्करण नियंत्रण)|मर्ज (वर्जन कंट्रोल)]] को सक्षम बनाता है, इस प्रकार अधिकांश संचालन को गति देता है, ऑफ़लाइन कार्य करने की क्षमता में सुधार करता है, और बैकअप के लिए ही स्थान पर निर्भर नहीं होता है .<ref name="git-scm"/><ref name="Joel 2010" /><ref>{{cite web|title=वितरित संस्करण नियंत्रण का परिचय (सचित्र)|url=https://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/|website=www.betterexplained.com|access-date=7 January 2018}}</ref> गिट (सॉफ़्टवेयर), संसार की अधिक लोकप्रिय वर्जन कंट्रोल सिस्टम,<ref name=":1" /> एक डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम है।


2010 में, सॉफ्टवेयर विकास लेखक [[जोएल स्पोल्स्की]] ने वितरित संस्करण नियंत्रण प्रणालियों को संभवतः [पिछले] दस वर्षों में सॉफ्टवेयर विकास प्रौद्योगिकी में सबसे बड़ी प्रगति के रूप में वर्णित किया।<ref name="Joel 2010">{{cite web
2010 में, सॉफ्टवेयर विकास लेखक [[जोएल स्पोल्स्की]] ने डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम्स को संभवतः विगत दस वर्षों में सॉफ्टवेयर विकास प्रौद्योगिकी में अधिक उच्च प्रगति के रूप में वर्णित किया था।<ref name="Joel 2010">{{cite web
   | url=http://joelonsoftware.com/items/2010/03/17.html
   | url=http://joelonsoftware.com/items/2010/03/17.html
   | first=Joel
   | first=Joel
Line 10: Line 10:
   | date=17 March 2010
   | date=17 March 2010
   | access-date=4 June 2019}}</ref>
   | access-date=4 June 2019}}</ref>
==डिस्ट्रिब्यूटेड बनाम सेंट्रलाइज्ड==
डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम्स (डीवीसीएस) सेंट्रलाइज्ड सिस्टम्स के क्लाइंट-सर्वर मॉडल या क्लाइंट-सर्वर दृष्टिकोण के विपरीत, वर्जन कंट्रोल के लिए पीयर-टू-पीयर दृष्टिकोण का उपयोग करती हैं। इस प्रकार डिस्ट्रिब्यूटेड पुनरीक्षण कंट्रोल [[पैच (यूनिक्स)]] को सहकर्मी से दूसरे सहकर्मी में स्थानांतरित करके रिपॉजिटरी को सिंक्रनाइज़ करता है। कोडबेस का कोई केंद्रीय वर्जन नहीं है; इसके अतिरिक्त, प्रत्येक उपयोगकर्ता के पास कार्यशील प्रति और पूर्ण परिवर्तन इतिहास होता है।


 
डीवीसीएस के लाभ (सेंट्रलाइज्ड सिस्टम्स की तुलना में) में सम्मिलित हैं:
==वितरित बनाम केंद्रीकृत==
* उपयोगकर्ताओं को नेटवर्क से कनेक्ट न होने पर भी उत्पादक विधि से कार्य करने की अनुमति देता है।
वितरित संस्करण नियंत्रण प्रणालियाँ (डीवीसीएस) केंद्रीकृत प्रणालियों के क्लाइंट-सर्वर मॉडल|क्लाइंट-सर्वर दृष्टिकोण के विपरीत, संस्करण नियंत्रण के लिए पीयर-टू-पीयर दृष्टिकोण का उपयोग करती हैं। वितरित पुनरीक्षण नियंत्रण [[पैच (यूनिक्स)]] को एक सहकर्मी से दूसरे सहकर्मी में स्थानांतरित करके रिपॉजिटरी को सिंक्रनाइज़ करता है। कोडबेस का कोई एक केंद्रीय संस्करण नहीं है; इसके बजाय, प्रत्येक उपयोगकर्ता के पास एक कार्यशील प्रति और पूर्ण परिवर्तन इतिहास होता है।
* डीवीसीएस के लिए सामान्य ऑपरेशन (जैसे कमिट, इतिहास देखना और परिवर्तनों को वापस लाना) तीव्र हैं, क्योंकि केंद्रीय सर्वर के साथ संचार करने की कोई आवश्यकता नहीं है।<ref name='OSullivan'>{{cite web
 
डीवीसीएस के लाभ (केंद्रीकृत प्रणालियों की तुलना में) में शामिल हैं:
* उपयोगकर्ताओं को नेटवर्क से कनेक्ट न होने पर भी उत्पादक ढंग से काम करने की अनुमति देता है।
* डीवीसीएस के लिए सामान्य ऑपरेशन (जैसे कमिट, इतिहास देखना और परिवर्तनों को वापस लाना) तेज़ हैं, क्योंकि केंद्रीय सर्वर के साथ संचार करने की कोई आवश्यकता नहीं है।<ref name='OSullivan'>{{cite web
   | last = O'Sullivan
   | last = O'Sullivan
   | first = Bryan
   | first = Bryan
   | title = Distributed revision control with Mercurial
   | title = Distributed revision control with Mercurial
   | url = http://hgbook.red-bean.com/hgbook.html
   | url = http://hgbook.red-bean.com/hgbook.html
   | access-date = July 13, 2007 }}</ref> डीवीसीएस के साथ, संचार केवल तभी आवश्यक है जब अन्य साथियों के बीच परिवर्तन साझा किए जाएं।
   | access-date = July 13, 2007 }}</ref> डीवीसीएस के साथ, संचार केवल तभी आवश्यक है जब अन्य साथियों के बीच परिवर्तन साझा किए जाते है।
* निजी कार्य की अनुमति देता है, ताकि उपयोगकर्ता अपने परिवर्तनों का उपयोग शुरुआती ड्राफ्ट के लिए भी कर सकें जिन्हें वे प्रकाशित नहीं करना चाहते हैं।{{cn|date=August 2019|reason=This isn't unique to dvcs; any source code control system allows 'private work', though on some it requires changing (private) file permissions}}
* निजी कार्य की अनुमति देता है, जिससे उपयोगकर्ता अपने परिवर्तनों का उपयोग प्रारंभिक ड्राफ्ट के लिए भी कर सकें जिन्हें वे प्रकाशित नहीं करना चाहते हैं।
* कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में एक भौतिक मशीन पर निर्भर होने से बचाती है।<ref name='OSullivan'/>* विभिन्न विकास मॉडलों का उपयोग करने की अनुमति देता है, जैसे ब्रांचिंग (संस्करण नियंत्रण)#विकास शाखा या कमांडर/लेफ्टिनेंट मॉडल का उपयोग करना।<ref>{{cite book|first1=Scott|last1=Chacon|first2=Ben|last2=Straub|edition=2nd|date=2014|publisher=Apress|at=Chapter 5.1|chapter=Distributed workflows|chapter-url=https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows|title=Pro Git}}</ref>
* कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में भौतिक मशीन पर निर्भर होने से बचाती है।<ref name='OSullivan'/>
* परियोजना के रिलीज़ संस्करण के केंद्रीकृत नियंत्रण की अनुमति देता है{{cn|date=August 2019|reason=Not specific to dvcs; centralized systems generally control release version}}
*विभिन्न विकास मॉडलों का उपयोग करने की अनुमति देता है, जैसे ब्रांचिंग (वर्जन कंट्रोल) विकास शाखा या कमांडर/लेफ्टिनेंट मॉडल का उपयोग करता है।<ref>{{cite book|first1=Scott|last1=Chacon|first2=Ben|last2=Straub|edition=2nd|date=2014|publisher=Apress|at=Chapter 5.1|chapter=Distributed workflows|chapter-url=https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows|title=Pro Git}}</ref>
* [[FOSS]] सॉफ़्टवेयर परियोजनाओं पर किसी ऐसे प्रोजेक्ट से फ़ोर्क (सॉफ़्टवेयर विकास) बनाना बहुत आसान है जो नेतृत्व संघर्ष या डिज़ाइन असहमति के कारण रुका हुआ है।
* परियोजना के रिलीज़ वर्जन के सेंट्रलाइज्ड कंट्रोल की अनुमति देता है
* [[FOSS|फॉस]] सॉफ़्टवेयर परियोजनाओं पर किसी ऐसे प्रोजेक्ट से फ़ोर्क (सॉफ़्टवेयर विकास) बनाना अधिक सरल है जो नेतृत्व संघर्ष या डिज़ाइन असहमति के कारण रुका हुआ है।


डीवीसीएस के नुकसान (केंद्रीकृत प्रणालियों की तुलना में) में शामिल हैं:
डीवीसीएस के हानि ( सेंट्रलाइज्ड सिस्टम्स की तुलना में) में सम्मिलित हैं:
* केंद्रीकृत संस्करण नियंत्रण प्रणाली में चेकआउट की तुलना में रिपॉजिटरी का प्रारंभिक चेकआउट धीमा है, क्योंकि सभी शाखाएं और संशोधन इतिहास डिफ़ॉल्ट रूप से स्थानीय मशीन पर कॉपी किए जाते हैं।
* सेंट्रलाइज्ड वर्जन कंट्रोल सिस्टम में चेकआउट की तुलना में रिपॉजिटरी का प्रारंभिक चेकआउट धीमा है, क्योंकि सभी शाखाएं और संशोधन इतिहास डिफ़ॉल्ट रूप से स्थानीय मशीन पर कॉपी किए जाते हैं।
* लॉकिंग तंत्र की कमी जो अधिकांश केंद्रीकृत वीसीएस का हिस्सा है और अभी भी गैर-मर्ज करने योग्य बाइनरी फ़ाइलों जैसे ग्राफिक संपत्तियों या बहुत जटिल एकल फ़ाइल बाइनरी या एक्सएमएल पैकेज (जैसे कार्यालय दस्तावेज़, पावरबीआई फ़ाइलें, एसक्यूएल) की बात आती है, तब भी एक महत्वपूर्ण भूमिका निभाती है। सर्वर डेटा टूल्स बीआई पैकेज, आदि)।{{citation needed|date=January 2018}}
* लॉकिंग तंत्र की कमी जो अधिकांश सेंट्रलाइज्ड वीसीएस का भाग है और अभी भी गैर-मर्ज करने योग्य बाइनरी फ़ाइलों जैसे ग्राफिक प्रोपर्टी या अधिक समष्टि एकल फ़ाइल बाइनरी या एक्सएमएल पैकेज (जैसे ऑफिस डाक्यूमेंट, पावरबीआई फ़ाइलें, एसक्यूएल) की बात आती है, तब भी महत्वपूर्ण भूमिका निभाती है। सर्वर डेटा टूल्स बीआई पैकेज, आदि)।
* प्रत्येक उपयोगकर्ता के लिए संपूर्ण कोडबेस इतिहास की पूरी प्रतिलिपि के लिए अतिरिक्त संग्रहण की आवश्यकता है।<ref>{{cite web|title=What is version control: centralized vs. DVCS|url=https://www.atlassian.com/blog/software-teams/version-control-centralized-dvcs|website=www.atlassian.com|access-date=7 January 2018}}</ref>
* प्रत्येक उपयोगकर्ता के लिए संपूर्ण कोडबेस इतिहास की पूर्ण प्रतिलिपि के लिए अतिरिक्त संग्रहण की आवश्यकता है।<ref>{{cite web|title=What is version control: centralized vs. DVCS|url=https://www.atlassian.com/blog/software-teams/version-control-centralized-dvcs|website=www.atlassian.com|access-date=7 January 2018}}</ref>
* चूंकि प्रत्येक प्रतिभागी के पास स्थानीय रूप से असुरक्षित प्रतिलिपि होती है, इसलिए कोड आधार का एक्सपोज़र बढ़ जाता है।{{cn|date=August 2019|reason=Also true of centralized codebases}}
* चूंकि प्रत्येक प्रतिभागी के पास स्थानीय रूप से असुरक्षित प्रतिलिपि होती है, इसलिए कोड आधार का एक्सपोज़र बढ़ जाता है।


कुछ मूल रूप से केंद्रीकृत प्रणालियाँ अब कुछ वितरित सुविधाएँ प्रदान करती हैं। [[टीम फाउंडेशन सर्वर]] और विजुअल स्टूडियो टीम सर्विसेज अब Git की मेजबानी के माध्यम से केंद्रीकृत और वितरित संस्करण नियंत्रण रिपॉजिटरी की मेजबानी करते हैं।
कुछ मूल रूप से सेंट्रलाइज्ड सिस्टम्स अब कुछ डिस्ट्रिब्यूटेड सुविधाएँ प्रदान करती हैं। इस प्रकार [[टीम फाउंडेशन सर्वर]] और विजुअल स्टूडियो टीम सर्विसेज अब गिट की होस्ट के माध्यम से सेंट्रलाइज्ड और डिस्ट्रिब्यूटेड वर्जन कंट्रोल रिपॉजिटरी की होस्ट करते हैं।


इसी तरह, कुछ वितरित प्रणालियाँ अब ऐसी सुविधाएँ प्रदान करती हैं जो चेकआउट समय और भंडारण लागत के मुद्दों को कम करती हैं, जैसे कि Microsoft द्वारा बहुत बड़े कोडबेस के साथ काम करने के लिए [[Git के लिए वर्चुअल फ़ाइल सिस्टम]] विकसित किया गया है।<ref>{{cite web|author=Jonathan Allen|url=https://www.infoq.com/news/2017/02/GVFS/|title=Microsoft ने बड़े रिपॉजिटरी के साथ Git की समस्या का समाधान कैसे किया|date=2017-02-08|access-date=2019-08-06}}</ref> जो एक वर्चुअल फ़ाइल सिस्टम को उजागर करता है जो फ़ाइलों को स्थानीय स्टोरेज में केवल आवश्यकतानुसार डाउनलोड करता है।
इसी प्रकार, कुछ डिस्ट्रिब्यूटेड सिस्टम्स अब ऐसी सुविधाएँ प्रदान करती हैं जो चेकआउट समय और संग्रहण निवेश के उद्देश्यों को कम करती हैं, जैसे कि माइक्रोसॉफ्ट द्वारा अधिक उच्च कोडबेस के साथ कार्य करने के लिए [[Git के लिए वर्चुअल फ़ाइल सिस्टम|गिट के लिए वर्चुअल फ़ाइल सिस्टम]] विकसित किया गया है।<ref>{{cite web|author=Jonathan Allen|url=https://www.infoq.com/news/2017/02/GVFS/|title=Microsoft ने बड़े रिपॉजिटरी के साथ Git की समस्या का समाधान कैसे किया|date=2017-02-08|access-date=2019-08-06}}</ref> जो वर्चुअल फ़ाइल सिस्टम को प्रदर्शित करता है जो फ़ाइलों को स्थानीय स्टोरेज में केवल आवश्यकतानुसार डाउनलोड करता है।


==कार्य मॉडल==
==कार्य मॉडल==
{{Expand section|date=June 2008}}
डिस्ट्रिब्यूटेड मॉडल सामान्यतः आंशिक रूप से स्वतंत्र डेवलपर्स के साथ उच्च परियोजनाओं के लिए उत्तम अनुकूल है, जैसे कि लिनक्स कर्नेल प्रोजेक्ट, क्योंकि डेवलपर्स स्वतंत्र रूप से कार्य कर सकते हैं और मर्ज (या अस्वीकृति) के लिए अपने परिवर्तन सबमिट कर सकते हैं। डिस्ट्रिब्यूटेड मॉडल विधि से कस्टम स्रोत कोड योगदान वर्कफ़्लो को अपनाने की अनुमति देता है। [[इंटीग्रेटर वर्कफ़्लो]] सबसे व्यापक रूप से उपयोग किया जाता है। सेंट्रलाइज्ड मॉडल में, विभिन्न वर्जनों के साथ समस्याओं से बचने के लिए, डेवलपर्स को अपने कार्य को क्रमबद्ध करना होता है।


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


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


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


इस केंद्रीकृत पैटर्न का उपयोग करने वाले संगठन अक्सर [[GitHub]] जैसी तीसरी पार्टी सेवा पर केंद्रीय भंडार की मेजबानी करना चुनते हैं, जो न केवल स्वयं-होस्ट किए गए भंडार की तुलना में अधिक विश्वसनीय [[अपटाइम]] प्रदान करता है, बल्कि [[ट्रैकर्स जारी करें]] और निरंतर एकीकरण जैसी केंद्रीकृत सुविधाएं भी जोड़ सकता है।
===पुल रिक्वेस्ट ===
डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम का उपयोग करने वाले स्रोत कोड रिपॉजिटरी में योगदान समान्यतः पुल अनुरोध के माध्यम से किया जाता है, जिसे मर्ज अनुरोध के रूप में भी जाना जाता है।<ref name="gitlab-merge-req">{{cite web|last=Sijbrandij|first=Sytse|title=गिटलैब प्रवाह|date=29 September 2014|access-date=4 August 2018|website=GitLab|url=https://about.gitlab.com/2014/09/29/gitlab-flow/}}</ref> पुल रिक्वेस्ट करता है कि परियोजना अनुरक्षक स्रोत कोड परिवर्तन को पुल करते है, इसलिए इसका नाम पुल अनुरोध है। यदि योगदान स्रोत आधार का भाग बनना चाहिए तो अनुरक्षक को पुल अनुरोध को मर्ज करना होता है।<ref name="ossw">{{cite web|last1=Johnson|first1=Mark|title=What is a pull request?|url=http://oss-watch.ac.uk/resources/pullrequest|website=Oaawatch|access-date=27 March 2016|date=8 November 2013}}</ref>


===अनुरोध खींचें===
डेवलपर नए परिवर्तन के अनुरक्षकों को सूचित करने के लिए पुल अनुरोध बनाता है; प्रत्येक पुल अनुरोध के साथ टिप्पणी थ्रेड जुड़ा हुआ है। यह कोड समीक्षा की अनुमति देता है। सबमिट किए गए पुल अनुरोध रिपॉजिटरी एक्सेस वाले किसी भी व्यक्ति को दिखाई देते हैं। पुल अनुरोध को अनुरक्षकों द्वारा स्वीकार या अस्वीकार किया जा सकता है।<ref>{{cite web|title=पुल अनुरोधों का उपयोग करना|url=https://help.github.com/articles/using-pull-requests/|publisher=GitHub|access-date=27 March 2016}}</ref> एक बार पुल अनुरोध की समीक्षा और अनुमोदन हो जाने के पश्चात्, इसे रिपॉजिटरी में विलय कर दिया जाता है। स्थापित वर्कफ़्लो के आधार पर, आधिकारिक रिलीज़ में सम्मिलित किए जाने से पहले कोड का परीक्षण करने की आवश्यकता हो सकती है। इसलिए, कुछ परियोजनाओं में अप्रयुक्त पुल अनुरोधों को मर्ज करने के लिए विशेष शाखा होती है।<ref name="ossw" /><ref>{{cite web|title=पुल अनुरोध करना|url=https://www.atlassian.com/git/tutorials/making-a-pull-request|publisher=Atlassian|access-date=27 March 2016}}</ref> अन्य परियोजनाएं निरंतर एकीकरण उपकरण का उपयोग करके प्रत्येक पुल अनुरोध पर स्वचालित परीक्षण सूट चलाती हैं, और समीक्षक यह जांचता है कि किसी भी नए कोड में उचित परीक्षण कवरेज है या नहीं है।
वितरित संस्करण नियंत्रण प्रणाली का उपयोग करने वाले स्रोत कोड रिपॉजिटरी में योगदान आमतौर पर पुल अनुरोध के माध्यम से किया जाता है, जिसे मर्ज अनुरोध के रूप में भी जाना जाता है।<ref name="gitlab-merge-req">{{cite web|last=Sijbrandij|first=Sytse|title=गिटलैब प्रवाह|date=29 September 2014|access-date=4 August 2018|website=GitLab|url=https://about.gitlab.com/2014/09/29/gitlab-flow/}}</ref> योगदानकर्ता अनुरोध करता है कि परियोजना अनुरक्षक स्रोत कोड परिवर्तन को खींच ले, इसलिए इसका नाम पुल अनुरोध है। यदि योगदान स्रोत आधार का हिस्सा बनना चाहिए तो अनुरक्षक को पुल अनुरोध को मर्ज करना होगा।<ref name="ossw">{{cite web|last1=Johnson|first1=Mark|title=What is a pull request?|url=http://oss-watch.ac.uk/resources/pullrequest|website=Oaawatch|access-date=27 March 2016|date=8 November 2013}}</ref>
डेवलपर नए परिवर्तन के अनुरक्षकों को सूचित करने के लिए एक पुल अनुरोध बनाता है; प्रत्येक पुल अनुरोध के साथ एक टिप्पणी थ्रेड जुड़ा हुआ है। यह कोड समीक्षा की अनुमति देता है। सबमिट किए गए पुल अनुरोध रिपॉजिटरी एक्सेस वाले किसी भी व्यक्ति को दिखाई देते हैं। पुल अनुरोध को अनुरक्षकों द्वारा स्वीकार या अस्वीकार किया जा सकता है।<ref>{{cite web|title=पुल अनुरोधों का उपयोग करना|url=https://help.github.com/articles/using-pull-requests/|publisher=GitHub|access-date=27 March 2016}}</ref>
एक बार पुल अनुरोध की समीक्षा और अनुमोदन हो जाने के बाद, इसे रिपॉजिटरी में विलय कर दिया जाता है। स्थापित वर्कफ़्लो के आधार पर, आधिकारिक रिलीज़ में शामिल किए जाने से पहले कोड का परीक्षण करने की आवश्यकता हो सकती है। इसलिए, कुछ परियोजनाओं में अप्रयुक्त पुल अनुरोधों को मर्ज करने के लिए एक विशेष शाखा होती है।<ref name="ossw" /><ref>{{cite web|title=पुल अनुरोध करना|url=https://www.atlassian.com/git/tutorials/making-a-pull-request|publisher=Atlassian|access-date=27 March 2016}}</ref> अन्य परियोजनाएं निरंतर एकीकरण उपकरण का उपयोग करके प्रत्येक पुल अनुरोध पर एक स्वचालित परीक्षण सूट चलाती हैं, और समीक्षक यह जांचता है कि किसी भी नए कोड में उचित परीक्षण कवरेज है या नहीं।


==इतिहास==
==इतिहास==
पहले ओपन-सोर्स डीवीसीएस सिस्टम में जीएनयू आर्क, [[मोनोटोन (सॉफ्टवेयर)]], और [[ अंधेरा ]] शामिल थे। हालाँकि, Git (सॉफ़्टवेयर) और मर्क्यूरियल (सॉफ़्टवेयर) के रिलीज़ होने तक ओपन सोर्स DVCS कभी भी बहुत लोकप्रिय नहीं थे।
पहले ओपन-सोर्स डीवीसीएस सिस्टम में जीएनयू आर्क, [[मोनोटोन (सॉफ्टवेयर)]], और [[ अंधेरा |डार्क्स]] सम्मिलित थे। चूँकि, गिट (सॉफ़्टवेयर) और मर्क्यूरियल (सॉफ़्टवेयर) के रिलीज़ होने तक ओपन सोर्स डीवीसीएस कभी भी अधिक लोकप्रिय नहीं थे।
 
[[बिटकीपर]] का उपयोग 2002 से 2005 तक [[लिनक्स कर्नेल]] के विकास में किया गया था।<ref name=":0">{{Cite news|url=http://www.infoworld.com/article/2670360/operating-systems/linus-torvalds--bitkeeper-blunder.html|title=लिनस टोरवाल्ड्स का बिटकीपर स्नूज़ करता है|last=McAllister|first=Neil|work=InfoWorld|access-date=2017-03-19|language=en}}</ref> Git (सॉफ़्टवेयर) का विकास, जो अब दुनिया की सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली है,<ref name=":1">{{cite web|title=Version Control Systems Popularity in 2016|url=https://rhodecode.com/insights/version-control-systems-2016|website=www.rhodecode.com|access-date=7 January 2018}}</ref> उस कंपनी के निर्णय से प्रेरित हुआ जिसने बिटकीपर को उस मुफ्त लाइसेंस को रद्द करने के लिए प्रेरित किया जिसका लिनस टोरवाल्ड्स और कुछ अन्य लिनक्स कर्नेल डेवलपर्स ने पहले लाभ उठाया था।<ref name=":0" />
 


[[बिटकीपर]] का उपयोग 2002 से 2005 तक [[लिनक्स कर्नेल]] के विकास में किया गया था।<ref name=":0">{{Cite news|url=http://www.infoworld.com/article/2670360/operating-systems/linus-torvalds--bitkeeper-blunder.html|title=लिनस टोरवाल्ड्स का बिटकीपर स्नूज़ करता है|last=McAllister|first=Neil|work=InfoWorld|access-date=2017-03-19|language=en}}</ref> गिट (सॉफ़्टवेयर) का विकास, जो अब संसार की अधिक लोकप्रिय वर्जन कंट्रोल सिस्टम है,<ref name=":1">{{cite web|title=Version Control Systems Popularity in 2016|url=https://rhodecode.com/insights/version-control-systems-2016|website=www.rhodecode.com|access-date=7 January 2018}}</ref> उस कंपनी के निर्णय से प्रेरित हुआ जिसने बिटकीपर को उस फ्री लाइसेंस को निरस्त करने के लिए प्रेरित किया जिसका लिनस टोरवाल्ड्स और कुछ अन्य लिनक्स कर्नेल डेवलपर्स ने पहले लाभ उठाया था।<ref name=":0" />
==यह भी देखें==
==यह भी देखें==
{{columns-list|colwidth=30em|
{{columns-list|colwidth=30em|
* [[Version control]]
* [[वर्जन कंट्रोल]]
* [[List of version-control software]]
* [[वर्जन-कंट्रोल सॉफ्टवेयर की सूची]]
* [[Comparison of version-control software]]
* [[वर्जन-कंट्रोल सॉफ़्टवेयर की तुलना]]
* [[:Category:Software using distributed version control]]
* [[वितरित वर्जन कंट्रोल का उपयोग करने वाला सॉफ़्टवेयर]]
* [[Repository clone]]
* [[रिपोजिटरी क्लोन]]
* [[Git (software)|Git]], an [[Open-source software|open source]] DVCS developed for Linux Kernel development
* [[गिट (सॉफ्टवेयर)|गिट]], एक [[ओपन-सोर्स सॉफ्टवेयर|ओपन सोर्स]] लिनक्स कर्नेल विकास के लिए डीवीसीएस विकसित किया गया
* [[Mercurial]], a cross-platform system similar to Git
* [[मर्क्यूरियल]], गिट के समान एक क्रॉस-प्लेटफ़ॉर्म सिस्टम
* [[Fossil (software)|Fossil]], a distributed version control system, bug tracking system and wiki software
* [[फ़ॉसिल (सॉफ़्टवेयर)|फ़ॉसिल]], एक वितरित संस्करण नियंत्रण सिस्टम, बग ट्रैकिंग सिस्टम और विकी सॉफ़्टवेयर
* [[BitKeeper]]
* [[बिटकीपर]]
* [[GNU Bazaar]]
* [[जीएनयू बाज़ार]]
* [[Concurrent Versions System]], a predecessor of distributed version control systems
* [[समवर्ती वर्जन सिस्टम]], वितरित वर्जन कंट्रोल सिस्टम का पूर्ववर्ती
* [[TortoiseHg]], a graphical interface for Mercurial
* [[टोरटोइजएचजी]], मर्क्यूरियल के लिए एक ग्राफिकल इंटरफ़ेस
* [[Code Co-op]], a peer-to-peer version control system
* [[कोड को-ऑप]], एक पीयर-टू-पीयर वर्जन कंट्रोल सिस्टम}}
}}


==संदर्भ==
==संदर्भ==
{{reflist}}
{{reflist}}
==बाहरी संबंध==
==बाहरी संबंध==
* [http://www.dwheeler.com/essays/scm.html Essay on various revision control systems], especially the section "Centralized vs. Decentralized SCM"
* [http://www.dwheeler.com/essays/scm.html Essay on various revision control systems], especially the section "Centralized vs. Decentralized SCM"
* [https://web.archive.org/web/20090602084310/http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Introduction to distributed version control systems] - IBM Developer Works article
* [https://web.archive.org/web/20090602084310/http://www.ibm.com/developerworks/aix/library/au-dist_ver_control/ Introduction to distributed version control systems] - IBM Developer Works article


{{Version control software}}
{{DEFAULTSORT:Distributed Revision Control}}    
 
{{DEFAULTSORT:Distributed Revision Control}}[[Category: संस्करण नियंत्रण]] [[Category: मुफ़्त सॉफ़्टवेयर प्रोजेक्ट]] [[Category: मुफ़्त संस्करण नियंत्रण सॉफ़्टवेयर]] [[Category: वितरित संस्करण नियंत्रण प्रणाली]] [[Category: समवर्ती संस्करण प्रणाली| समवर्ती संस्करण प्रणाली]]


[[de:Versionsverwaltung#Verteilte Versionsverwaltung]]
[[de:Versionsverwaltung#Verteilte Versionsverwaltung]]
Line 94: Line 84:
[[ja:分散型バージョン管理システム]]
[[ja:分散型バージョン管理システム]]


 
[[Category:CS1 English-language sources (en)]]
 
[[Category:Created On 10/07/2023|Distributed Revision Control]]
[[Category: Machine Translated Page]]
[[Category:Lua-based templates|Distributed Revision Control]]
[[Category:Created On 10/07/2023]]
[[Category:Machine Translated Page|Distributed Revision Control]]
[[Category:Multi-column templates|Distributed Revision Control]]
[[Category:Pages using div col with small parameter|Distributed Revision Control]]
[[Category:Pages with script errors|Distributed Revision Control]]
[[Category:Templates Vigyan Ready|Distributed Revision Control]]
[[Category:Templates that add a tracking category|Distributed Revision Control]]
[[Category:Templates that generate short descriptions|Distributed Revision Control]]
[[Category:Templates using TemplateData|Distributed Revision Control]]
[[Category:Templates using under-protected Lua modules|Distributed Revision Control]]
[[Category:Wikipedia fully protected templates|Div col]]
[[Category:मुफ़्त संस्करण नियंत्रण सॉफ़्टवेयर|Distributed Revision Control]]
[[Category:मुफ़्त सॉफ़्टवेयर प्रोजेक्ट|Distributed Revision Control]]
[[Category:वितरित संस्करण नियंत्रण प्रणाली|Distributed Revision Control]]
[[Category:संस्करण नियंत्रण|Distributed Revision Control]]
[[Category:समवर्ती संस्करण प्रणाली| समवर्ती संस्करण प्रणाली]]

Latest revision as of 16:15, 25 July 2023

सॉफ़्टवेयर विकास में, डिस्ट्रिब्यूटेड वर्जन कंट्रोल (जिसे डिस्ट्रिब्यूटेड संशोधन कंट्रोल के रूप में भी जाना जाता है) वर्जन कंट्रोल का रूप है जिसमें संपूर्ण कोडबेस, उसके पूर्ण इतिहास सहित, प्रत्येक डेवलपर के कंप्यूटर पर प्रतिबिंबित होता है।[1] सेंट्रलाइज्ड वर्जन कंट्रोल की तुलना में, यह स्वचालित मैनेजमेंट ब्रांचिंग (वर्जन कंट्रोल) और मर्ज (वर्जन कंट्रोल) को सक्षम बनाता है, इस प्रकार अधिकांश संचालन को गति देता है, ऑफ़लाइन कार्य करने की क्षमता में सुधार करता है, और बैकअप के लिए ही स्थान पर निर्भर नहीं होता है .[1][2][3] गिट (सॉफ़्टवेयर), संसार की अधिक लोकप्रिय वर्जन कंट्रोल सिस्टम,[4] एक डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम है।

2010 में, सॉफ्टवेयर विकास लेखक जोएल स्पोल्स्की ने डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम्स को संभवतः विगत दस वर्षों में सॉफ्टवेयर विकास प्रौद्योगिकी में अधिक उच्च प्रगति के रूप में वर्णित किया था।[2]

डिस्ट्रिब्यूटेड बनाम सेंट्रलाइज्ड

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

डीवीसीएस के लाभ (सेंट्रलाइज्ड सिस्टम्स की तुलना में) में सम्मिलित हैं:

  • उपयोगकर्ताओं को नेटवर्क से कनेक्ट न होने पर भी उत्पादक विधि से कार्य करने की अनुमति देता है।
  • डीवीसीएस के लिए सामान्य ऑपरेशन (जैसे कमिट, इतिहास देखना और परिवर्तनों को वापस लाना) तीव्र हैं, क्योंकि केंद्रीय सर्वर के साथ संचार करने की कोई आवश्यकता नहीं है।[5] डीवीसीएस के साथ, संचार केवल तभी आवश्यक है जब अन्य साथियों के बीच परिवर्तन साझा किए जाते है।
  • निजी कार्य की अनुमति देता है, जिससे उपयोगकर्ता अपने परिवर्तनों का उपयोग प्रारंभिक ड्राफ्ट के लिए भी कर सकें जिन्हें वे प्रकाशित नहीं करना चाहते हैं।
  • कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में भौतिक मशीन पर निर्भर होने से बचाती है।[5]
  • विभिन्न विकास मॉडलों का उपयोग करने की अनुमति देता है, जैसे ब्रांचिंग (वर्जन कंट्रोल) विकास शाखा या कमांडर/लेफ्टिनेंट मॉडल का उपयोग करता है।[6]
  • परियोजना के रिलीज़ वर्जन के सेंट्रलाइज्ड कंट्रोल की अनुमति देता है
  • फॉस सॉफ़्टवेयर परियोजनाओं पर किसी ऐसे प्रोजेक्ट से फ़ोर्क (सॉफ़्टवेयर विकास) बनाना अधिक सरल है जो नेतृत्व संघर्ष या डिज़ाइन असहमति के कारण रुका हुआ है।

डीवीसीएस के हानि ( सेंट्रलाइज्ड सिस्टम्स की तुलना में) में सम्मिलित हैं:

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

कुछ मूल रूप से सेंट्रलाइज्ड सिस्टम्स अब कुछ डिस्ट्रिब्यूटेड सुविधाएँ प्रदान करती हैं। इस प्रकार टीम फाउंडेशन सर्वर और विजुअल स्टूडियो टीम सर्विसेज अब गिट की होस्ट के माध्यम से सेंट्रलाइज्ड और डिस्ट्रिब्यूटेड वर्जन कंट्रोल रिपॉजिटरी की होस्ट करते हैं।

इसी प्रकार, कुछ डिस्ट्रिब्यूटेड सिस्टम्स अब ऐसी सुविधाएँ प्रदान करती हैं जो चेकआउट समय और संग्रहण निवेश के उद्देश्यों को कम करती हैं, जैसे कि माइक्रोसॉफ्ट द्वारा अधिक उच्च कोडबेस के साथ कार्य करने के लिए गिट के लिए वर्चुअल फ़ाइल सिस्टम विकसित किया गया है।[8] जो वर्चुअल फ़ाइल सिस्टम को प्रदर्शित करता है जो फ़ाइलों को स्थानीय स्टोरेज में केवल आवश्यकतानुसार डाउनलोड करता है।

कार्य मॉडल

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

केंद्रीय और शाखा रिपॉजिटरी

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

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

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

पुल रिक्वेस्ट

डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम का उपयोग करने वाले स्रोत कोड रिपॉजिटरी में योगदान समान्यतः पुल अनुरोध के माध्यम से किया जाता है, जिसे मर्ज अनुरोध के रूप में भी जाना जाता है।[9] पुल रिक्वेस्ट करता है कि परियोजना अनुरक्षक स्रोत कोड परिवर्तन को पुल करते है, इसलिए इसका नाम पुल अनुरोध है। यदि योगदान स्रोत आधार का भाग बनना चाहिए तो अनुरक्षक को पुल अनुरोध को मर्ज करना होता है।[10]

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

इतिहास

पहले ओपन-सोर्स डीवीसीएस सिस्टम में जीएनयू आर्क, मोनोटोन (सॉफ्टवेयर), और डार्क्स सम्मिलित थे। चूँकि, गिट (सॉफ़्टवेयर) और मर्क्यूरियल (सॉफ़्टवेयर) के रिलीज़ होने तक ओपन सोर्स डीवीसीएस कभी भी अधिक लोकप्रिय नहीं थे।

बिटकीपर का उपयोग 2002 से 2005 तक लिनक्स कर्नेल के विकास में किया गया था।[13] गिट (सॉफ़्टवेयर) का विकास, जो अब संसार की अधिक लोकप्रिय वर्जन कंट्रोल सिस्टम है,[4] उस कंपनी के निर्णय से प्रेरित हुआ जिसने बिटकीपर को उस फ्री लाइसेंस को निरस्त करने के लिए प्रेरित किया जिसका लिनस टोरवाल्ड्स और कुछ अन्य लिनक्स कर्नेल डेवलपर्स ने पहले लाभ उठाया था।[13]

यह भी देखें

संदर्भ

  1. ↑ 1.0 1.1 Chacon, Scott; Straub, Ben (2014). "About version control". गिट के लिए (2nd ed.). Apress. Chapter 1.1. Retrieved 4 June 2019.
  2. ↑ 2.0 2.1 Spolsky, Joel (17 March 2010). "Distributed Version Control Is Here to Stay, Baby". Joel on Software. Retrieved 4 June 2019.
  3. ↑ "वितरित संस्करण नियंत्रण का परिचय (सचित्र)". www.betterexplained.com. Retrieved 7 January 2018.
  4. ↑ 4.0 4.1 "Version Control Systems Popularity in 2016". www.rhodecode.com. Retrieved 7 January 2018.
  5. ↑ 5.0 5.1 O'Sullivan, Bryan. "Distributed revision control with Mercurial". Retrieved July 13, 2007.
  6. ↑ Chacon, Scott; Straub, Ben (2014). "Distributed workflows". Pro Git (2nd ed.). Apress. Chapter 5.1.
  7. ↑ "What is version control: centralized vs. DVCS". www.atlassian.com. Retrieved 7 January 2018.
  8. ↑ Jonathan Allen (2017-02-08). "Microsoft ने बड़े रिपॉजिटरी के साथ Git की समस्या का समाधान कैसे किया". Retrieved 2019-08-06.
  9. ↑ Sijbrandij, Sytse (29 September 2014). "गिटलैब प्रवाह". GitLab. Retrieved 4 August 2018.
  10. ↑ 10.0 10.1 Johnson, Mark (8 November 2013). "What is a pull request?". Oaawatch. Retrieved 27 March 2016.
  11. ↑ "पुल अनुरोधों का उपयोग करना". GitHub. Retrieved 27 March 2016.
  12. ↑ "पुल अनुरोध करना". Atlassian. Retrieved 27 March 2016.
  13. ↑ 13.0 13.1 McAllister, Neil. "लिनस टोरवाल्ड्स का बिटकीपर स्नूज़ करता है". InfoWorld (in English). Retrieved 2017-03-19.

बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=वितरित_संस्करण_नियंत्रण_(डिस्ट्रिब्यूटेड_वर्जन_कंट्रोल)&oldid=224008’