संस्करण नियंत्रण प्रणालियों का इतिहास

इस लेख में, हम सबसे प्रसिद्ध संस्करण नियंत्रण प्रणालियों को देखने के तकनीकी बिंदु से तुलना करते हैं (भविष्य में हम सूची का विस्तार करने की योजना बनाते हैं):

1. पहली पीढ़ी
   
   • SCCS (सोर्स कोड कंट्रोल सिस्टम)
   • आरसीएस (रिविजन कंट्रोल सिस्टम)
2. दूसरी पीढ़ी
   • सीवीएस (समवर्ती संस्करण प्रणाली)
   • एसवीएन (अपाचे तोड़फोड़)
3. तीसरी पीढ़ी
   • Git
   • अस्थिर

पहली पीढ़ी के संस्करण नियंत्रण प्रणाली (VCS) ने व्यक्तिगत फ़ाइलों में परिवर्तन ट्रैक किए, और संपादन केवल स्थानीय और एक समय में एक उपयोगकर्ता द्वारा समर्थित था। सिस्टम इस धारणा पर बनाए गए थे कि सभी उपयोगकर्ता समान सामान्य यूनिक्स नोड पर अपने खातों में लॉग इन करेंगे।

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

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

वीसीएस रिलीज़ टाइमलाइन

संदर्भ के लिए, यहाँ एक चार्ट है जिसमें ये उपकरण दिखाई देते हैं:

SCCS (सोर्स कोड कंट्रोल सिस्टम): पहली पीढ़ी

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

आर्किटेक्चर

अधिकांश आधुनिक प्रणालियों की तरह, SCCS में फ़ाइल संस्करणों के साथ काम करने के लिए कमांड का एक सेट है:

1. SCCS में इतिहास ट्रैकिंग के लिए चेक-इन फ़ाइलें।
   
2. समीक्षा या संकलन के लिए फाइलों के विशिष्ट संस्करणों की जांच करें।
   
3. संपादन के लिए विशिष्ट संस्करण निकालें।
   
4. परिवर्तनों की व्याख्या करने वाली टिप्पणियों के साथ-साथ फाइलों के नए संस्करणों का परिचय।
   
5. निकाले गए फ़ाइल में किए गए परिवर्तनों को त्यागें।
   
6. प्रमुख शाखाओं में बंटना और विलय।
   
7. फ़ाइल बदलें लॉग।

SCCS में एक ट्रैकिंग फ़ाइल जोड़ते समय, एक विशेष प्रकार की फ़ाइल बनाई जाती है, जिसे s- या कहा जाता है। इसे स्रोत फ़ाइल के रूप में संदर्भित किया जाता है, केवल उपसर्ग के साथ s. , और SCCS उपनिर्देशिका में संग्रहीत है। इस प्रकार, test.txt फ़ाइल के लिए, एक इतिहास फ़ाइल test.txt ./SCCS/ निर्देशिका में बनाई जाएगी। निर्माण के समय, इतिहास फ़ाइल में स्रोत फ़ाइल की प्रारंभिक सामग्री होती है, साथ ही कुछ मेटाडेटा भी होते हैं जो संस्करणों को ट्रैक करने में मदद करते हैं। सामग्री को संशोधित नहीं किया गया है यह सुनिश्चित करने के लिए यहां चेकसम जमा किए जाते हैं। इतिहास फ़ाइल की सामग्री संकुचित या एन्कोडेड नहीं है (जैसा कि अगली पीढ़ी के वीसीएस में)।

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

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

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

जब SCCS में संपादन के लिए एक फ़ाइल निकाली जाती है, तो उस पर एक ताला लगाया जाता है, ताकि कोई दूसरा उसे संपादित न कर सके। यह अन्य उपयोगकर्ताओं द्वारा परिवर्तनों की ओवरराइटिंग को रोकता है, लेकिन विकास को भी सीमित करता है, क्योंकि किसी भी समय केवल एक उपयोगकर्ता इस फाइल के साथ काम कर सकता है।

SCCS उन शाखाओं का समर्थन करता है जो एक विशिष्ट फ़ाइल में क्रम को बदलते हैं। आप मूल संस्करण के साथ या किसी अन्य शाखा के साथ एक शाखा को मर्ज कर सकते हैं।

मुख्य टीमें

निम्नलिखित सबसे सामान्य SCCS आदेशों की एक सूची है।

• sccs create <filename.ext> : sccs create <filename.ext> एक नई फ़ाइल जोड़ें और इसके लिए एक नई इतिहास फ़ाइल बनाएं (डिफ़ॉल्ट रूप से ./SCCS/ निर्देशिका में)।
  
• sccs get <filename.ext> : फाइल को संबंधित हिस्ट्री फ़ाइल से निकालें और इसे sccs get <filename.ext> -ओनली मोड में वर्किंग डायरेक्टरी में रखें।
  
• sccs edit <filename.ext> : संपादन के लिए संबंधित इतिहास फ़ाइल से फ़ाइल निकालें। इतिहास फ़ाइल को लॉक करें ताकि अन्य उपयोगकर्ता इसे संशोधित न कर सकें।
  
• sccs delta <filename.ext> : निर्दिष्ट फ़ाइल में परिवर्तन जोड़ें। सिस्टम एक टिप्पणी का अनुरोध करेगा, इतिहास फ़ाइल में परिवर्तन सहेजेगा और लॉक को रिलीज़ करेगा।
  
• sccs prt <filename.ext> : मॉनिटर की गई फ़ाइल के लिए परिवर्तन लॉग प्रदर्शित करें।
  
• sccs diffs <filename.ext> : sccs diffs <filename.ext> की वर्तमान कार्य प्रतिलिपि और फ़ाइल की स्थिति के बीच अंतर दिखाते हैं जब इसे निकाला गया था।

SCCS इंटर्नल्स के बारे में अधिक जानकारी के लिए, एरिक अल्लमैन गाइड और ओरेकल के प्रोग्रामिंग यूटिलिटी गाइड देखें ।

SCCS इतिहास फ़ाइल उदाहरण

 ^Ah20562 ^As 00001/00001/00002 ^Ad D 1.3 19/11/26 14:37:08 jack 3 2 ^Ac Here is a comment. ^Ae ^As 00002/00000/00001 ^Ad D 1.2 19/11/26 14:36:00 jack 2 1 ^Ac No. ^Ae ^As 00001/00000/00000 ^Ad D 1.1 19/11/26 14:35:27 jack 1 0 ^Ac date and time created 19/11/26 14:35:27 by jack ^Ae ^Au ^AU ^Af e 0 ^At ^AT ^AI 1 Hi there ^AE 1 ^AI 2 ^AD 3 This is a test of SCCS ^AE 2 ^AE 3 ^AI 3 A test of SCCS ^AE 3 

आरसीएस (रिविजन कंट्रोल सिस्टम): पहली पीढ़ी

RCS को 1982 में Walter Tihey द्वारा C में SCCS प्रणाली के विकल्प के रूप में लिखा गया था, जो उस समय खुला स्रोत नहीं था।

आर्किटेक्चर

RCS में अपने पूर्ववर्ती के साथ बहुत कुछ सामान्य है, जिसमें शामिल हैं:

• प्रत्येक फ़ाइल के लिए अलग से संस्करण।
  
• कई फ़ाइलों में परिवर्तन को एक ही प्रतिबद्ध में वर्गीकृत नहीं किया जा सकता है।
  
• एक ही समय में कई उपयोगकर्ताओं द्वारा ट्रैक की गई फ़ाइलों को संपादित नहीं किया जा सकता है।
  
• कोई नेटवर्क समर्थन नहीं।
  
• प्रत्येक ट्रैक की गई फ़ाइल के संस्करणों को संबंधित इतिहास फ़ाइल में संग्रहीत किया जाता है।
  
• केवल व्यक्तिगत फ़ाइलों के लिए शाखाओं में बंटना और विलय करना।

जब किसी फ़ाइल को पहली बार RCS में जोड़ा जाता है, तो स्थानीय निर्देशिका में स्थानीय संग्रहण में इसके लिए एक संबंधित इतिहास फ़ाइल बनाई जाती है ./RCS/ इस फ़ाइल में एक एक्सटेंशन ,v , जोड़ा जाता है, अर्थात, test.txt नामक एक फ़ाइल को test.txt,v नामक फ़ाइल द्वारा ट्रैक किया जाएगा।

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

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

मुख्य टीमें

नीचे सबसे सामान्य आरसीएस कमांड की एक सूची दी गई है:

• <filename.ext> : RCS में एक नई फ़ाइल जोड़ें और इसके लिए एक नई इतिहास फ़ाइल बनाएं (डिफ़ॉल्ट रूप से ./RCS/ निर्देशिका में)।
  
• co <filename.ext> : संबंधित इतिहास फ़ाइल से फ़ाइल निकालें और इसे केवल-पढ़ने के लिए मोड में कार्यशील निर्देशिका में डालें।
  
• co -l <filename.ext> : संपादन के लिए संबंधित इतिहास फ़ाइल से फ़ाइल निकालें। इतिहास फ़ाइल को लॉक करें ताकि अन्य उपयोगकर्ता इसे संशोधित न कर सकें।
  
• ci <filename.ext> : फ़ाइल परिवर्तन जोड़ें और संबंधित इतिहास फ़ाइल में इसके लिए एक नया संशोधन बनाएँ।
  
• merge <file-to-merge-into.ext> <parent.ext> <file-to-merge-from.ext> : एक ही मूल फ़ाइल के दो संशोधित बच्चों से परिवर्तन मर्ज करें।
  
• rcsdiff <filename.ext> : rcsdiff <filename.ext> की वर्तमान कार्य प्रतिलिपि और फ़ाइल की स्थिति के बीच अंतर प्रदर्शित करें जब इसे निकाला गया था।
  
• rcsclean : उन कार्य फ़ाइलों को हटा दें जिन्हें लॉक नहीं किया गया है।

आंतरिक आरसीएस घटकों के बारे में अधिक जानकारी के लिए, जीएनयू आरसीएस मैनुअल देखें ।

उदाहरण RCS इतिहास फ़ाइल

 head 1.2; access; symbols; locks; strict; comment @# @; 1.2 date 2019.11.25.05.51.55; author jstopak; state Exp; branches; next 1.1; 1.1 date 2019.11.25.05.49.02; author jstopak; state Exp; branches; next ; desc @This is a test. @ 1.2 log @Edited the file. @ text @hi there, you are my bud. You are so cool! The end. @ 1.1 log @Initial revision @ text @d1 5 a5 1 hi there @ 

सीवीएस (समवर्ती संस्करण प्रणाली): दूसरी पीढ़ी

संस्करण नियंत्रण में नेटवर्क समर्थन को जोड़ने के लिए 1986 में डिक ग्रुन द्वारा CVS बनाया गया था। यह सी में भी लिखा गया है और वीसीएस उपकरणों की दूसरी पीढ़ी के जन्म को चिह्नित करता है, जिसकी बदौलत भौगोलिक रूप से बिखरी हुई विकास टीमों को एक साथ परियोजनाओं पर काम करने का अवसर मिलता है।

आर्किटेक्चर

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

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

मुख्य टीमें

• export CVSROOT=<path/to/repository> CVS रिपॉजिटरी की रूट डायरेक्टरी सेट करें, इसलिए आपको इसे हर कमांड में निर्दिष्ट करने की आवश्यकता नहीं है।
  
• cvs import -m 'Import module' <module-name> <vendor-tag> <release-tag> : सीवीएस मॉड्यूल में फ़ाइलों के साथ आयात निर्देशिकाएं। इस प्रक्रिया को शुरू करने से पहले, परियोजना की मूल निर्देशिका पर जाएं।
  
• cvs checkout <module-name> : मॉड्यूल को कार्यशील निर्देशिका में कॉपी करें।
  
• cvs commit <filename.ext> : केंद्रीय रिपॉजिटरी में मॉड्यूल में वापस संशोधित फ़ाइल करें।
  
• cvs add <filename.txt> : परिवर्तनों को ट्रैक करने के लिए एक नई फ़ाइल जोड़ें।
  
• cvs update : केंद्रीय रिपॉजिटरी में मौजूद नहीं बल्कि कार्यशील प्रतिलिपि में मौजूद परिवर्तनों को मर्ज करके कार्य प्रतिलिपि को अपडेट करें।
  
• cvs status : मॉड्यूल के निकाले गए काम की नकल के बारे में सामान्य जानकारी दिखाएं।
  
• cvs tag <tag-name> <files> : किसी फ़ाइल या फ़ाइलों के सेट में एक टैग जोड़ें।
  
• cvs tag -b <new-branch-name> : रिपॉजिटरी में एक नई शाखा बनाएं (आपको किसी भी वेबसाइट से पहले इसे निकालने की आवश्यकता है)।
  
• cvs checkout -r <branch-name> : किसी मौजूदा ब्रांच को वर्किंग डायरेक्टरी में निकालें।
  
• cvs update -j <branch-to-merge> : किसी मौजूदा ब्रांच को लोकल वर्किंग कॉपी के साथ मर्ज करें।

सीवीएस के आंतरिक घटकों के बारे में अधिक जानकारी के लिए, जीएनयू सीवीएस हैंडबुक और डिक ग्रोन का लेख देखें ।

सीवीएस इतिहास फ़ाइल उदाहरण

 head 1.1; branch 1.1.1; access ; symbols start:1.1.1.1 jack:1.1.1; locks ; strict; comment @# @; 1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches 1.1.1.1; next ; commitid zsEBhVyPc4lonoMB; 1.1.1.1 date 2019.11.26.18.45.07; author jstopak; state Exp; branches ; next ; commitid zsEBhVyPc4lonoMB; desc @@ 1.1 log @Initial revision @ text @hi there @ 1.1.1.1 log @Imported sources @ text @@ 

एसवीएन (तोड़फोड़): दूसरी पीढ़ी

तोड़फोड़ 2000 में Collabnet Inc. द्वारा बनाई गई थी और वर्तमान में यह Apache Software Foundation द्वारा समर्थित है। सिस्टम सी में लिखा गया है और सीवीएस की तुलना में अधिक विश्वसनीय केंद्रीकृत समाधान के रूप में डिज़ाइन किया गया है।

आर्किटेक्चर

सीवीएस की तरह, सबवर्सन एक केंद्रीकृत रिपोजिटरी मॉडल का उपयोग करता है। केंद्रीय रिपॉजिटरी के लिए दूरस्थ उपयोगकर्ताओं को नेटवर्क कनेक्शन की आवश्यकता होती है।

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

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

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

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

एसवीएन सामान्य ब्रांचिंग और टैगिंग प्रणाली का उपयोग नहीं करता है। नियमित तोड़फोड़ रिपॉजिटरी टेम्पलेट में रूट में तीन फ़ोल्डर हैं:

• trunk/
  
• branches/
  
• tags/

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

मुख्य टीमें

• svn create <path-to-repository> : निर्दिष्ट निर्देशिका में एक नया खाली रिपॉजिटरी शेल बनाएँ।
  
• svn import <path-to-project> <svn-url> : फ़ाइल निर्देशिका को निर्दिष्ट सबवर्सन रिपॉजिटरी में आयात करें।
  
• svn checkout <svn-path> <path-to-checkout> : रिपोजिटरी को वर्किंग डायरेक्टरी में कॉपी करें।
  
• svn commit -m 'Commit message' : svn commit -m 'Commit message' के साथ संशोधित फाइलों और फ़ोल्डरों का एक सेट।
  
• svn add <filename.txt> : परिवर्तनों को ट्रैक करने के लिए एक नई फ़ाइल जोड़ें।
  
• svn update : केंद्रीय भंडार में मौजूद नहीं बल्कि कार्यशील प्रतिलिपि में मौजूद परिवर्तनों को मर्ज करके कार्य प्रतिलिपि को अद्यतन करें।
  
• svn status : मॉनिटर की गई फ़ाइलों की एक सूची प्रदर्शित करें जो कार्य निर्देशिका (यदि कोई हो) में बदल गई हैं।
  
• svn info : निकाली गई कॉपी के बारे में सामान्य जानकारी।
  
• svn copy <branch-to-copy> <new-branch-path-and-name> : किसी मौजूदा को कॉपी करके एक नई ब्रांच बनाएं।
  
• svn switch <existing-branch> : काम करने वाली निर्देशिका को किसी मौजूदा शाखा में स्विच करें। इससे आप वहां से फाइल ले सकेंगे।
  
• svn merge <existing-branch> : निर्दिष्ट शाखा को मौजूदा एक के साथ मर्ज कर रहा है जो कि कार्यशील निर्देशिका में कॉपी की गई है। कृपया ध्यान दें कि आपको बाद में करने की आवश्यकता होगी।
  
• svn log : कमिट का इतिहास और सक्रिय शाखा के लिए संबंधित संदेश दिखाते हैं।

एसवीएन के आंतरिक घटकों के बारे में अधिक जानकारी के लिए, तोड़फोड़ संस्करण देखें।

नमूना SVN इतिहास फ़ाइल

 DELTA SVN^B^@^@ ^B ^A<89> hi there ENDREP id: 2-1.0.r1/4 type: file count: 0 text: 1 3 21 9 12f6bb1941df66b8f138a446d4e8670c 279d9035886d4c0427549863c4c2101e4a63e041 0-0/_4 cpath: /trunk/hi.txt copyroot: 0 / DELTA SVN^B^@^@$^B%^A¤$K 6 hi.txt V 15 file 2-1.0.r1/4 END ENDREP id: 0-1.0.r1/6 type: dir count: 0 text: 1 5 48 36 d84cb1c29105ee7739f3e834178e6345 - - cpath: /trunk copyroot: 0 / DELTA SVN^B^@^@'^B#^A¢'K 5 trunk V 14 dir 0-1.0.r1/6 END ENDREP id: 0.0.r1/2 type: dir pred: 0.0.r0/2 count: 1 text: 1 7 46 34 1d30e888ec9e633100992b752c2ff4c2 - - cpath: / copyroot: 0 / _0.0.t0-0 add-dir false false false /trunk _2.0.t0-0 add-file true false false /trunk/hi.txt L2P-INDEX ^A<80>@^A^A^A^M^H^@ä^H÷^Aé^FDÎ^Bzè^AP2L-INDEX ^A<91>^E<80><80>@^A?^@'2^@<8d>»Ý<90>^C§^A^X^@õ ½½^N= ^@ü<8d>Ôã^Ft^V^@<92><9a><89>Ã^E; ^@<8a>åw|I^@<88><83>Î<93>^L`^M^@ù<92>À^Eïú?^[^@^@657 6aad60ec758d121d5181ea4b81a9f5f4 688 75f59082c8b5ab687ae87708432ca406I 

Git: तीसरी पीढ़ी

गिट सिस्टम को 2005 में लिनस टोरवाल्ड्स (लिनक्स का निर्माता) द्वारा विकसित किया गया था। यह कुछ कमांड लाइन स्क्रिप्ट के संयोजन में मुख्य रूप से सी में लिखा गया है। VCS से कार्यों, लचीलेपन और गति में कठिनाई। टॉर्वाल्ड्स ने मूल रूप से लिनक्स कोड बेस के लिए सिस्टम लिखा था, लेकिन समय के साथ इसका दायरा विस्तृत हो गया, और आज यह दुनिया में सबसे लोकप्रिय संस्करण नियंत्रण प्रणाली है।

आर्किटेक्चर

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

इसके अलावा, डेवलपर्स अन्य रिपॉजिटरी के ज्ञान के बिना रिपॉजिटरी की स्थानीय कॉपी में अपने बदलाव कर सकते हैं। यह बिना नेटवर्क या इंटरनेट से जुड़े रहने की अनुमति देता है। डेवलपर्स स्थानीय रूप से ऑफ़लाइन काम कर सकते हैं, जब तक कि वे अपना काम दूसरों के साथ साझा करने के लिए तैयार न हों। इस बिंदु पर, सत्यापन, परीक्षण, या परिनियोजन के लिए अन्य रिपॉजिटरी में परिवर्तन भेजे जाते हैं।

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

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

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

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

मुख्य टीमें

• git init: Git रिपॉजिटरी (एक छिपे हुए फ़ोल्डर .gitऔर इसकी सामग्री बनाई गई है) के रूप में वर्तमान निर्देशिका को इनिशियलाइज़ करें ।
  
• git clone <git-url> : निर्दिष्ट URL पर Git रिपॉजिटरी की एक प्रति डाउनलोड करें।
  
• git add <filename.ext> : स्टेजिंग क्षेत्र में एक अनट्रैक या संशोधित फ़ाइल जोड़ें (ऑब्जेक्ट्स के डेटाबेस में संबंधित रिकॉर्ड बनाता है)।
  
• git commit -m 'Commit message' : एक प्रतिबद्ध संदेश के साथ संशोधित फ़ाइलों और फ़ोल्डरों का एक सेट।
  
• git status : वर्किंग डायरेक्टरी, करंट ब्रांच, अनट्रैक फाइल्स, मॉडिफाइड फाइल्स आदि का स्टेटस दिखाएं।
  
• git branch <new-branch> : वर्तमान निकाले गए शाखा के आधार पर एक नई शाखा बनाएँ।
  
• git checkout <branch> : कार्यशील निर्देशिका के लिए निर्दिष्ट शाखा निकालें।
  
• git merge <branch> : वर्तमान शाखा के साथ निर्दिष्ट शाखा को मर्ज करें, जिसे कार्य निर्देशिका में निकाला जाता है।
  
• git pull : दूरस्थ रिपॉजिटरी में मौजूद प्रतिबद्ध परिवर्तनों को जोड़कर वर्किंग कॉपी को अपडेट करें, लेकिन वर्किंग कॉपी में नहीं।
  
• git push : सक्रिय ब्रांच की स्थानीय कमिटियों के लिए पैकेज फाइल में पैक करें और रिमोट रिपॉजिटरी में ट्रांसफर करें।
  
• git log : सक्रिय शाखा के लिए आवागमन के इतिहास और संबंधित संदेशों को दिखाएं।
  
• git stash : बाद में पुनर्प्राप्ति के लिए कार्यशील निर्देशिका से कैश के लिए सभी अनियोजित परिवर्तनों को सहेजें।

यदि आप जानना चाहते हैं कि Git कोड कैसे काम करता है, तो Git Starter Guide देखें । आंतरिक घटकों के बारे में अधिक जानकारी के लिए, प्रो गिट बुक में संबंधित अध्याय देखें ।

उदाहरण बूँद, पेड़ और कमिट

एक हैश के साथ बूँद 37d4e6c5c48ba0d245164c4e10d5f41140cab980:

 hi there 

एक हैश के साथ ट्री ऑब्जेक्ट b769f35b07fbe0076dcfc36fd80c121d747ccc04:

 100644 blob 37d4e6c5c48ba0d245164c4e10d5f41140cab980hi.txt 

हैश कमिट dc512627287a61f6111705151f4e53f204fbda9b:

 tree b769f35b07fbe0076dcfc36fd80c121d747ccc04 author Jacob Stopak 1574915303 -0800 committer Jacob Stopak 1574915303 -0800 Initial commit 

मर्क्यूरियल: तीसरी पीढ़ी

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

आर्किटेक्चर

मर्क्यूरियल भी एक वितरित प्रणाली है जो किसी भी संख्या में डेवलपर्स को स्वतंत्र रूप से दूसरों की परियोजना की कॉपी के साथ काम करने की अनुमति देता है। मर्क्यूरियल कई तकनीकों का उपयोग करता है जैसे गिट, जिसमें SHA-1 संपीड़न और हैशिंग शामिल हैं, लेकिन यह इसे अलग तरीके से करता है।

जब एक नई फ़ाइल Mercurial में ट्रैकिंग के लिए प्रतिबद्ध होती है, तो revlogएक छिपी निर्देशिका में इसके लिए एक संबंधित फ़ाइल बनाई जाती है .hg/store/data/। आप फ़ाइल revlog(परिवर्तन लॉग) को एक उन्नत संस्करण के रूप में मान सकते हैं CVS, RCS और SCCS जैसे पुराने VCS में। गिट के विपरीत, जो प्रत्येक तैयार की गई फ़ाइल के प्रत्येक संस्करण के लिए एक नई बूँद बनाता है, मर्क्यूरियल बस इस फ़ाइल के लिए एक नया रिवॉल्ग प्रविष्टि बनाता है। अंतरिक्ष को बचाने के लिए, प्रत्येक नए रिकॉर्ड में पिछले संस्करण से केवल डेल्टा होता है। जब डेल्टास की दहलीज संख्या तक पहुंच जाती है, तो फ़ाइल का पूरा स्नैपशॉट फिर से सहेजा जाता है। यह खोज के समय को कम करता है जब किसी फ़ाइल के विशिष्ट संस्करण को पुनर्स्थापित करने के लिए बड़ी संख्या में डेल्टास का प्रसंस्करण होता है।

प्रत्येक रिग्लॉग को उस फ़ाइल के अनुसार नामित किया जाता है जिसे वह ट्रैक कर रहा है, लेकिन एक्सटेंशन के साथ .iया .d। फ़ाइलों .dमें एक संकुचित डेल्टा होता है। फ़ाइलों .iको फ़ाइलों के भीतर अलग-अलग संस्करणों को जल्दी से ट्रैक करने के लिए अनुक्रमित के रूप में उपयोग किया जाता है.d। कुछ परिवर्तनों वाली छोटी फ़ाइलों के लिए, अनुक्रमणिका और सामग्री फ़ाइलों के अंदर संग्रहीत की जाती हैं .i। Revlog प्रविष्टियाँ प्रदर्शन के लिए संकुचित हैं और पहचान के लिए hashed हैं। इन हैश मूल्यों का नाम दिया गया है nodeid।

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

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

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

प्रत्येक चैंज एंट्री भी एक हैश के रूप में जाना जाता है उत्पन्न करता है nodeid।

मुख्य टीमें

• hg init: एक मर्क्यूरियल रिपॉजिटरी के रूप में वर्तमान निर्देशिका को इनिशियलाइज़ करें (एक हिडन फोल्डर .hgऔर उसकी सामग्री बनाता है )।
  
• hg clone <hg-url> : निर्दिष्ट URL पर मरकरी रिपॉजिटरी की एक प्रति डाउनलोड करें।
  
• hg add <filename.ext> : परिवर्तनों को ट्रैक करने के लिए एक नई फ़ाइल जोड़ें।
  
• hg commit -m 'Commit message' : कमिट मैसेज के साथ बदले हुए फाइल और फोल्डर का सेट तैयार करें।
  
• hg status : वर्किंग डायरेक्टरी की स्थिति, अनटैक की गई फाइल्स, मॉडिफाइड फाइल्स आदि से संबंधित जानकारी प्रदर्शित करें।
  
• hg update <revision> : कार्यशील निर्देशिका के लिए निर्दिष्ट शाखा निकालें।
  
• hg merge <branch> : कार्यशील निर्देशिका में निकाले गए वर्तमान एक के साथ निर्दिष्ट शाखा को मर्ज करें।
  
• hg pull : दूरस्थ रिपॉजिटरी से नए संस्करण डाउनलोड करें, लेकिन उन्हें एक कार्यशील निर्देशिका में मर्ज न करें।
  
• hg push : नए संस्करणों को दूरस्थ रिपॉजिटरी में स्थानांतरित करें।
  
• hg log : सक्रिय शाखा के लिए आवागमन और संबंधित संदेशों का इतिहास दिखाएं।

उदाहरण Mercurial फ़ाइलें

घोषणा पत्र:

 hey.txt208b6e0998e8099b16ad0e43f036ec745d58ec04 hi.txt74568dc1a5b9047c8041edd99dd6f566e78d3a42 

परिवर्तन लॉग (चैंज)

 b8ee947ce6f25b84c22fbefecab99ea918fc0969 Jacob Stopak 1575082451 28800 hey.txt Add hey.txt 

मर्क्यूरियल डिवाइस के बारे में अतिरिक्त जानकारी:

• ब्रायन ओ'सुलीवन की पुस्तक मर्क्यूरियल पर
• विकी मर्क्यूरियल (रिवालॉग)
• विकी मर्क्यूरियल (चेंजसेट)
• विकी मर्क्यूरियल (मैनिफेस्ट)
• विकी मर्क्यूरियल (संशोधन)
• Mercurial (Nodeid)