वितरित संस्करण नियंत्रण (डिस्ट्रिब्यूटेड वर्जन कंट्रोल)
सॉफ़्टवेयर विकास में, वितरित संस्करण नियंत्रण (जिसे वितरित संशोधन नियंत्रण के रूप में भी जाना जाता है) संस्करण नियंत्रण का एक रूप है जिसमें संपूर्ण कोडबेस, उसके पूर्ण इतिहास सहित, प्रत्येक डेवलपर के कंप्यूटर पर प्रतिबिंबित होता है।[1] केंद्रीकृत संस्करण नियंत्रण की तुलना में, यह स्वचालित प्रबंधन ब्रांचिंग (संस्करण नियंत्रण) और मर्ज (संस्करण नियंत्रण) को सक्षम बनाता है, अधिकांश संचालन को गति देता है (धकेलने और खींचने को छोड़कर), ऑफ़लाइन काम करने की क्षमता में सुधार करता है, और बैकअप के लिए एक ही स्थान पर निर्भर नहीं होता है .[1][2][3] Git (सॉफ़्टवेयर), दुनिया की सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली,[4]एक वितरित संस्करण नियंत्रण प्रणाली है।
2010 में, सॉफ्टवेयर विकास लेखक जोएल स्पोल्स्की ने वितरित संस्करण नियंत्रण प्रणालियों को संभवतः [पिछले] दस वर्षों में सॉफ्टवेयर विकास प्रौद्योगिकी में सबसे बड़ी प्रगति के रूप में वर्णित किया।[2]
वितरित बनाम केंद्रीकृत
वितरित संस्करण नियंत्रण प्रणालियाँ (डीवीसीएस) केंद्रीकृत प्रणालियों के क्लाइंट-सर्वर मॉडल|क्लाइंट-सर्वर दृष्टिकोण के विपरीत, संस्करण नियंत्रण के लिए पीयर-टू-पीयर दृष्टिकोण का उपयोग करती हैं। वितरित पुनरीक्षण नियंत्रण पैच (यूनिक्स) को एक सहकर्मी से दूसरे सहकर्मी में स्थानांतरित करके रिपॉजिटरी को सिंक्रनाइज़ करता है। कोडबेस का कोई एक केंद्रीय संस्करण नहीं है; इसके बजाय, प्रत्येक उपयोगकर्ता के पास एक कार्यशील प्रति और पूर्ण परिवर्तन इतिहास होता है।
डीवीसीएस के लाभ (केंद्रीकृत प्रणालियों की तुलना में) में शामिल हैं:
- उपयोगकर्ताओं को नेटवर्क से कनेक्ट न होने पर भी उत्पादक ढंग से काम करने की अनुमति देता है।
- डीवीसीएस के लिए सामान्य ऑपरेशन (जैसे कमिट, इतिहास देखना और परिवर्तनों को वापस लाना) तेज़ हैं, क्योंकि केंद्रीय सर्वर के साथ संचार करने की कोई आवश्यकता नहीं है।[5] डीवीसीएस के साथ, संचार केवल तभी आवश्यक है जब अन्य साथियों के बीच परिवर्तन साझा किए जाएं।
- निजी कार्य की अनुमति देता है, ताकि उपयोगकर्ता अपने परिवर्तनों का उपयोग शुरुआती ड्राफ्ट के लिए भी कर सकें जिन्हें वे प्रकाशित नहीं करना चाहते हैं।[citation needed]
- कार्यशील प्रतियां प्रभावी रूप से रिमोट बैकअप के रूप में कार्य करती हैं, जो विफलता के एकल बिंदु के रूप में एक भौतिक मशीन पर निर्भर होने से बचाती है।[5]* विभिन्न विकास मॉडलों का उपयोग करने की अनुमति देता है, जैसे ब्रांचिंग (संस्करण नियंत्रण)#विकास शाखा या कमांडर/लेफ्टिनेंट मॉडल का उपयोग करना।[6]
- परियोजना के रिलीज़ संस्करण के केंद्रीकृत नियंत्रण की अनुमति देता है[citation needed]
- FOSS सॉफ़्टवेयर परियोजनाओं पर किसी ऐसे प्रोजेक्ट से फ़ोर्क (सॉफ़्टवेयर विकास) बनाना बहुत आसान है जो नेतृत्व संघर्ष या डिज़ाइन असहमति के कारण रुका हुआ है।
डीवीसीएस के नुकसान (केंद्रीकृत प्रणालियों की तुलना में) में शामिल हैं:
- केंद्रीकृत संस्करण नियंत्रण प्रणाली में चेकआउट की तुलना में रिपॉजिटरी का प्रारंभिक चेकआउट धीमा है, क्योंकि सभी शाखाएं और संशोधन इतिहास डिफ़ॉल्ट रूप से स्थानीय मशीन पर कॉपी किए जाते हैं।
- लॉकिंग तंत्र की कमी जो अधिकांश केंद्रीकृत वीसीएस का हिस्सा है और अभी भी गैर-मर्ज करने योग्य बाइनरी फ़ाइलों जैसे ग्राफिक संपत्तियों या बहुत जटिल एकल फ़ाइल बाइनरी या एक्सएमएल पैकेज (जैसे कार्यालय दस्तावेज़, पावरबीआई फ़ाइलें, एसक्यूएल) की बात आती है, तब भी एक महत्वपूर्ण भूमिका निभाती है। सर्वर डेटा टूल्स बीआई पैकेज, आदि)।[citation needed]
- प्रत्येक उपयोगकर्ता के लिए संपूर्ण कोडबेस इतिहास की पूरी प्रतिलिपि के लिए अतिरिक्त संग्रहण की आवश्यकता है।[7]
- चूंकि प्रत्येक प्रतिभागी के पास स्थानीय रूप से असुरक्षित प्रतिलिपि होती है, इसलिए कोड आधार का एक्सपोज़र बढ़ जाता है।[citation needed]
कुछ मूल रूप से केंद्रीकृत प्रणालियाँ अब कुछ वितरित सुविधाएँ प्रदान करती हैं। टीम फाउंडेशन सर्वर और विजुअल स्टूडियो टीम सर्विसेज अब Git की मेजबानी के माध्यम से केंद्रीकृत और वितरित संस्करण नियंत्रण रिपॉजिटरी की मेजबानी करते हैं।
इसी तरह, कुछ वितरित प्रणालियाँ अब ऐसी सुविधाएँ प्रदान करती हैं जो चेकआउट समय और भंडारण लागत के मुद्दों को कम करती हैं, जैसे कि Microsoft द्वारा बहुत बड़े कोडबेस के साथ काम करने के लिए Git के लिए वर्चुअल फ़ाइल सिस्टम विकसित किया गया है।[8] जो एक वर्चुअल फ़ाइल सिस्टम को उजागर करता है जो फ़ाइलों को स्थानीय स्टोरेज में केवल आवश्यकतानुसार डाउनलोड करता है।
कार्य मॉडल
This section needs expansion. You can help by adding to it. (June 2008) |
वितरित मॉडल आम तौर पर आंशिक रूप से स्वतंत्र डेवलपर्स के साथ बड़ी परियोजनाओं के लिए बेहतर अनुकूल है, जैसे कि लिनक्स कर्नेल प्रोजेक्ट, क्योंकि डेवलपर्स स्वतंत्र रूप से काम कर सकते हैं और मर्ज (या अस्वीकृति) के लिए अपने परिवर्तन सबमिट कर सकते हैं। वितरित मॉडल लचीले ढंग से कस्टम स्रोत कोड योगदान वर्कफ़्लो को अपनाने की अनुमति देता है। इंटीग्रेटर वर्कफ़्लो सबसे व्यापक रूप से उपयोग किया जाता है। केंद्रीकृत मॉडल में, विभिन्न संस्करणों के साथ समस्याओं से बचने के लिए, डेवलपर्स को अपने काम को क्रमबद्ध करना होगा।
केंद्रीय और शाखा भंडार
वास्तव में वितरित परियोजना में, जैसे कि लिनक्स, प्रत्येक योगदानकर्ता परियोजना का अपना संस्करण बनाए रखता है, विभिन्न योगदानकर्ता अपने स्वयं के संबंधित संस्करणों की मेजबानी करते हैं और आवश्यकतानुसार अन्य उपयोगकर्ताओं से परिवर्तन खींचते हैं, जिसके परिणामस्वरूप कई अलग-अलग नोड्स से एक आम सहमति बनती है। इससे फोर्किंग की प्रक्रिया भी आसान हो जाती है, क्योंकि केवल एक योगदानकर्ता अन्य योगदानकर्ताओं से पुल अनुरोध स्वीकार करना बंद कर देता है और कोडबेस को धीरे-धीरे अलग होने देता है।
हालाँकि, इस व्यवस्था को बनाए रखना मुश्किल हो सकता है, जिसके परिणामस्वरूप कई परियोजनाएँ एक ऐसे प्रतिमान में स्थानांतरित होने का विकल्प चुनती हैं जिसमें एक योगदानकर्ता सार्वभौमिक अपस्ट्रीम होता है, एक भंडार जिससे परिवर्तन लगभग हमेशा खींचे जाते हैं। इस प्रतिमान के तहत, विकास को कुछ हद तक नवीनीकृत किया गया है, क्योंकि अब प्रत्येक परियोजना में एक केंद्रीय भंडार होता है जिसे अनौपचारिक रूप से आधिकारिक भंडार माना जाता है, जिसे परियोजना अनुरक्षकों द्वारा सामूहिक रूप से प्रबंधित किया जाता है। जबकि वितरित संस्करण नियंत्रण प्रणालियाँ नए डेवलपर्स के लिए किसी अन्य योगदानकर्ता के भंडार की प्रतिलिपि को क्लोन करना आसान बनाती हैं, एक केंद्रीय मॉडल में, नए डेवलपर्स हमेशा कोड आधार की समान स्थानीय प्रतियां बनाने के लिए केंद्रीय भंडार को क्लोन करते हैं। इस प्रणाली के तहत, केंद्रीय भंडार में कोड परिवर्तन समय-समय पर स्थानीय भंडार के साथ सिंक्रनाइज़ किए जाते हैं, और एक बार विकास पूरा हो जाने पर, परिवर्तन को जल्द से जल्द केंद्रीय भंडार में एकीकृत किया जाना चाहिए।
इस केंद्रीकृत पैटर्न का उपयोग करने वाले संगठन अक्सर GitHub जैसी तीसरी पार्टी सेवा पर केंद्रीय भंडार की मेजबानी करना चुनते हैं, जो न केवल स्वयं-होस्ट किए गए भंडार की तुलना में अधिक विश्वसनीय अपटाइम प्रदान करता है, बल्कि ट्रैकर्स जारी करें और निरंतर एकीकरण जैसी केंद्रीकृत सुविधाएं भी जोड़ सकता है।
अनुरोध खींचें
वितरित संस्करण नियंत्रण प्रणाली का उपयोग करने वाले स्रोत कोड रिपॉजिटरी में योगदान आमतौर पर पुल अनुरोध के माध्यम से किया जाता है, जिसे मर्ज अनुरोध के रूप में भी जाना जाता है।[9] योगदानकर्ता अनुरोध करता है कि परियोजना अनुरक्षक स्रोत कोड परिवर्तन को खींच ले, इसलिए इसका नाम पुल अनुरोध है। यदि योगदान स्रोत आधार का हिस्सा बनना चाहिए तो अनुरक्षक को पुल अनुरोध को मर्ज करना होगा।[10] डेवलपर नए परिवर्तन के अनुरक्षकों को सूचित करने के लिए एक पुल अनुरोध बनाता है; प्रत्येक पुल अनुरोध के साथ एक टिप्पणी थ्रेड जुड़ा हुआ है। यह कोड समीक्षा की अनुमति देता है। सबमिट किए गए पुल अनुरोध रिपॉजिटरी एक्सेस वाले किसी भी व्यक्ति को दिखाई देते हैं। पुल अनुरोध को अनुरक्षकों द्वारा स्वीकार या अस्वीकार किया जा सकता है।[11] एक बार पुल अनुरोध की समीक्षा और अनुमोदन हो जाने के बाद, इसे रिपॉजिटरी में विलय कर दिया जाता है। स्थापित वर्कफ़्लो के आधार पर, आधिकारिक रिलीज़ में शामिल किए जाने से पहले कोड का परीक्षण करने की आवश्यकता हो सकती है। इसलिए, कुछ परियोजनाओं में अप्रयुक्त पुल अनुरोधों को मर्ज करने के लिए एक विशेष शाखा होती है।[10][12] अन्य परियोजनाएं निरंतर एकीकरण उपकरण का उपयोग करके प्रत्येक पुल अनुरोध पर एक स्वचालित परीक्षण सूट चलाती हैं, और समीक्षक यह जांचता है कि किसी भी नए कोड में उचित परीक्षण कवरेज है या नहीं।
इतिहास
पहले ओपन-सोर्स डीवीसीएस सिस्टम में जीएनयू आर्क, मोनोटोन (सॉफ्टवेयर), और अंधेरा शामिल थे। हालाँकि, Git (सॉफ़्टवेयर) और मर्क्यूरियल (सॉफ़्टवेयर) के रिलीज़ होने तक ओपन सोर्स DVCS कभी भी बहुत लोकप्रिय नहीं थे।
बिटकीपर का उपयोग 2002 से 2005 तक लिनक्स कर्नेल के विकास में किया गया था।[13] Git (सॉफ़्टवेयर) का विकास, जो अब दुनिया की सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली है,[4] उस कंपनी के निर्णय से प्रेरित हुआ जिसने बिटकीपर को उस मुफ्त लाइसेंस को रद्द करने के लिए प्रेरित किया जिसका लिनस टोरवाल्ड्स और कुछ अन्य लिनक्स कर्नेल डेवलपर्स ने पहले लाभ उठाया था।[13]
यह भी देखें
- Version control
- List of version-control software
- Comparison of version-control software
- Category:Software using distributed version control
- Repository clone
- Git, an open source DVCS developed for Linux Kernel development
- Mercurial, a cross-platform system similar to Git
- 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
संदर्भ
- ↑ 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