वितरित संस्करण नियंत्रण (डिस्ट्रिब्यूटेड वर्जन कंट्रोल): Difference between revisions
No edit summary |
No edit summary |
||
| 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> गिट (सॉफ़्टवेयर), संसार की अधिक लोकप्रिय संस्करण नियंत्रण सिस्टम,<ref name=":1" /> एक डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम है। | ||
2010 में, सॉफ्टवेयर विकास लेखक [[जोएल स्पोल्स्की]] ने | 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 | ||
| Line 24: | Line 24: | ||
* कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में भौतिक मशीन पर निर्भर होने से बचाती है।<ref name='OSullivan'/> | * कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में भौतिक मशीन पर निर्भर होने से बचाती है।<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>{{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|फॉस]] सॉफ़्टवेयर परियोजनाओं पर किसी ऐसे प्रोजेक्ट से फ़ोर्क (सॉफ़्टवेयर विकास) बनाना अधिक सरल है जो नेतृत्व संघर्ष या डिज़ाइन असहमति के कारण रुका हुआ है। | ||
डीवीसीएस के हानि ( | डीवीसीएस के हानि ( सेंट्रलाइज्ड सिस्टम्स की तुलना में) में सम्मिलित हैं: | ||
* | * सेंट्रलाइज्ड संस्करण नियंत्रण सिस्टम में चेकआउट की तुलना में रिपॉजिटरी का प्रारंभिक चेकआउट धीमा है, क्योंकि सभी शाखाएं और संशोधन इतिहास डिफ़ॉल्ट रूप से स्थानीय मशीन पर कॉपी किए जाते हैं। | ||
* लॉकिंग तंत्र की कमी जो अधिकांश | * लॉकिंग तंत्र की कमी जो अधिकांश सेंट्रलाइज्ड वीसीएस का भाग है और अभी भी गैर-मर्ज करने योग्य बाइनरी फ़ाइलों जैसे ग्राफिक प्रोपर्टी या अधिक समष्टि एकल फ़ाइल बाइनरी या एक्सएमएल पैकेज (जैसे कार्यालय दस्तावेज़, पावरबीआई फ़ाइलें, एसक्यूएल) की बात आती है, तब भी महत्वपूर्ण भूमिका निभाती है। सर्वर डेटा टूल्स बीआई पैकेज, आदि)। | ||
* प्रत्येक उपयोगकर्ता के लिए संपूर्ण कोडबेस इतिहास की पूर्ण प्रतिलिपि के लिए अतिरिक्त संग्रहण की आवश्यकता है।<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> | ||
* चूंकि प्रत्येक प्रतिभागी के पास स्थानीय रूप से असुरक्षित प्रतिलिपि होती है, इसलिए कोड आधार का एक्सपोज़र बढ़ जाता है। | * चूंकि प्रत्येक प्रतिभागी के पास स्थानीय रूप से असुरक्षित प्रतिलिपि होती है, इसलिए कोड आधार का एक्सपोज़र बढ़ जाता है। | ||
कुछ मूल रूप से | कुछ मूल रूप से सेंट्रलाइज्ड सिस्टम्स अब कुछ डिस्ट्रिब्यूटेड सुविधाएँ प्रदान करती हैं। इस प्रकार [[टीम फाउंडेशन सर्वर]] और विजुअल स्टूडियो टीम सर्विसेज अब गिट की होस्ट के माध्यम से सेंट्रलाइज्ड और डिस्ट्रिब्यूटेड वर्जन कंट्रोल रिपॉजिटरी की होस्ट करते हैं। | ||
इसी प्रकार, कुछ | इसी प्रकार, कुछ डिस्ट्रिब्यूटेड सिस्टम्स अब ऐसी सुविधाएँ प्रदान करती हैं जो चेकआउट समय और संग्रहण निवेश के उद्देश्यों को कम करती हैं, जैसे कि माइक्रोसॉफ्ट द्वारा अधिक उच्च कोडबेस के साथ कार्य करने के लिए [[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> जो वर्चुअल फ़ाइल सिस्टम को प्रदर्शित करता है जो फ़ाइलों को स्थानीय स्टोरेज में केवल आवश्यकतानुसार डाउनलोड करता है। | ||
==कार्य मॉडल== | ==कार्य मॉडल== | ||
डिस्ट्रिब्यूटेड मॉडल सामान्यतः आंशिक रूप से स्वतंत्र डेवलपर्स के साथ उच्च परियोजनाओं के लिए उत्तम अनुकूल है, जैसे कि लिनक्स कर्नेल प्रोजेक्ट, क्योंकि डेवलपर्स स्वतंत्र रूप से कार्य कर सकते हैं और मर्ज (या अस्वीकृति) के लिए अपने परिवर्तन सबमिट कर सकते हैं। डिस्ट्रिब्यूटेड मॉडल विधि से कस्टम स्रोत कोड योगदान वर्कफ़्लो को अपनाने की अनुमति देता है। [[इंटीग्रेटर वर्कफ़्लो]] सबसे व्यापक रूप से उपयोग किया जाता है। सेंट्रलाइज्ड मॉडल में, विभिन्न संस्करणों के साथ समस्याओं से बचने के लिए, डेवलपर्स को अपने कार्य को क्रमबद्ध करना होता है। | |||
===केंद्रीय और शाखा रिपॉजिटरी === | ===केंद्रीय और शाखा रिपॉजिटरी === | ||
वास्तव में | वास्तव में डिस्ट्रिब्यूटेड परियोजना में, जैसे कि [[लिनक्स]], प्रत्येक योगदानकर्ता परियोजना का अपना संस्करण बनाए रखता है, विभिन्न योगदानकर्ता अपने स्वयं के संबंधित संस्करणों की होस्ट करते हैं और इस प्रकार आवश्यकतानुसार अन्य उपयोगकर्ताओं से परिवर्तन करते हैं, जिसके परिणामस्वरूप कई अलग-अलग नोड्स से सामान्य सहमति बनती है। इससे फोर्किंग की प्रक्रिया भी सरल हो जाती है, क्योंकि केवल योगदानकर्ता अन्य योगदानकर्ताओं से पुल अनुरोध स्वीकार करना बंद कर देता है और कोडबेस को धीरे-धीरे अलग होने देता है। | ||
चूँकि, इस व्यवस्था को बनाए रखना कठिन हो सकता है, जिसके परिणामस्वरूप कई परियोजनाएँ ऐसे प्रतिमान में स्थानांतरित होने का विकल्प चुनती हैं जिसमें योगदानकर्ता सार्वभौमिक अपस्ट्रीम होता है, रिपॉजिटरी जिससे परिवर्तन लगभग सदैव खींचे जाते हैं। इस प्रतिमान के अनुसार, विकास को कुछ सीमा तक नवीनीकृत किया गया है, क्योंकि अब प्रत्येक परियोजना में केंद्रीय रिपॉजिटरी होता है जिसे अनौपचारिक रूप से आधिकारिक रिपॉजिटरी माना जाता है, जिसे परियोजना अनुरक्षकों द्वारा सामूहिक रूप से प्रबंधित किया जाता है। जबकि | चूँकि, इस व्यवस्था को बनाए रखना कठिन हो सकता है, जिसके परिणामस्वरूप कई परियोजनाएँ ऐसे प्रतिमान में स्थानांतरित होने का विकल्प चुनती हैं जिसमें योगदानकर्ता सार्वभौमिक अपस्ट्रीम होता है, रिपॉजिटरी जिससे परिवर्तन लगभग सदैव खींचे जाते हैं। इस प्रतिमान के अनुसार, विकास को कुछ सीमा तक नवीनीकृत किया गया है, क्योंकि अब प्रत्येक परियोजना में केंद्रीय रिपॉजिटरी होता है जिसे अनौपचारिक रूप से आधिकारिक रिपॉजिटरी माना जाता है, जिसे परियोजना अनुरक्षकों द्वारा सामूहिक रूप से प्रबंधित किया जाता है। जबकि डिस्ट्रिब्यूटेड वर्जन कंट्रोल सिस्टम्स नए डेवलपर्स के लिए किसी अन्य योगदानकर्ता के रिपॉजिटरी की प्रतिलिपि को क्लोन करना सरल बनाती हैं, केंद्रीय मॉडल में, नए डेवलपर्स सदैव कोड आधार की समान स्थानीय प्रतियां बनाने के लिए केंद्रीय रिपॉजिटरी को क्लोन करते हैं। इस सिस्टम के अनुसार, केंद्रीय रिपॉजिटरी में कोड परिवर्तन समय-समय पर स्थानीय रिपॉजिटरी के साथ सिंक्रनाइज़ किए जाते हैं, और विकास पूर्ण हो जाने पर, परिवर्तन को शीघ्र से शीघ्र केंद्रीय रिपॉजिटरी में एकीकृत किया जाना चाहिए। | ||
इस | इस सेंट्रलाइज्ड पैटर्न का उपयोग करने वाले संगठन अक्सर [[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>{{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> अन्य परियोजनाएं निरंतर एकीकरण उपकरण का उपयोग करके प्रत्येक पुल अनुरोध पर स्वचालित परीक्षण सूट चलाती हैं, और समीक्षक यह जांचता है कि किसी भी नए कोड में उचित परीक्षण कवरेज है या नहीं है। | ||
Revision as of 13:48, 20 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.0 1.1 Chacon, Scott; Straub, Ben (2014). "About version control". गिट के लिए (2nd ed.). Apress. Chapter 1.1. Retrieved 4 June 2019.
- ↑ 2.0 2.1 Spolsky, Joel (17 March 2010). "Distributed Version Control Is Here to Stay, Baby". Joel on Software. Retrieved 4 June 2019.
- ↑ "वितरित संस्करण नियंत्रण का परिचय (सचित्र)". www.betterexplained.com. Retrieved 7 January 2018.
- ↑ 4.0 4.1 "Version Control Systems Popularity in 2016". www.rhodecode.com. Retrieved 7 January 2018.
- ↑ 5.0 5.1 O'Sullivan, Bryan. "Distributed revision control with Mercurial". Retrieved July 13, 2007.
- ↑ Chacon, Scott; Straub, Ben (2014). "Distributed workflows". Pro Git (2nd ed.). Apress. Chapter 5.1.
- ↑ "What is version control: centralized vs. DVCS". www.atlassian.com. Retrieved 7 January 2018.
- ↑ Jonathan Allen (2017-02-08). "Microsoft ने बड़े रिपॉजिटरी के साथ Git की समस्या का समाधान कैसे किया". Retrieved 2019-08-06.
- ↑ Sijbrandij, Sytse (29 September 2014). "गिटलैब प्रवाह". GitLab. Retrieved 4 August 2018.
- ↑ 10.0 10.1 Johnson, Mark (8 November 2013). "What is a pull request?". Oaawatch. Retrieved 27 March 2016.
- ↑ "पुल अनुरोधों का उपयोग करना". GitHub. Retrieved 27 March 2016.
- ↑ "पुल अनुरोध करना". Atlassian. Retrieved 27 March 2016.
- ↑ 13.0 13.1 McAllister, Neil. "लिनस टोरवाल्ड्स का बिटकीपर स्नूज़ करता है". InfoWorld (in English). Retrieved 2017-03-19.
बाहरी संबंध
- Essay on various revision control systems, especially the section "Centralized vs. Decentralized SCM"
- Introduction to distributed version control systems - IBM Developer Works article
