एचजी इनिट: भाग 6. रिपोजिटरी आर्किटेक्चर

यह Hg Init श्रृंखला का छठा, अंतिम भाग है : जोएल स्पोलस्की का मर्क्यूरियल ट्यूटोरियल । पिछले भाग:

• तोड़फोड़ उपयोगकर्ताओं के लिए फिर से काम करना
• मर्क्यूरियल की मूल बातें
• "एक टीम में काम करने की आदत डालें"
• "त्रुटियों को ठीक करना"
• "विलय प्रक्रिया"

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

भाग 6. रिपोजिटरी वास्तुकला

हमारा नुस्खा बेहतर हो रहा है:











आइए परिवर्तन सेट संख्या पर एक नज़र डालें:







कमरे का पहला भाग, 13, छोटा और आरामदायक है। समस्या यह है ... आप उस पर भरोसा नहीं कर सकते!



टीम के सदस्यों और विलय के स्वतंत्र काम के साथ, ये कम संख्या अलग-अलग टीम के सदस्यों के लिए अलग-अलग हो सकती है:







इसलिए व्यवहार में, मैं यह नहीं कह सकता: "ठीक है, चलो 13 वें परिवर्तन सेट से संकलित एक संस्करण जारी करें", क्योंकि कर्मचारियों को 13 वें सेट के बारे में एक अलग विचार हो सकता है। यही कारण है कि पागल हेक्साडेसिमल संख्या भी है।







यह हेक्साडेसिमल संख्या सभी रिपॉजिटरी में अद्वितीय है और कभी नहीं बदलती है।



यही है, मैं लोगों को बता सकता हूँ: “अरे, आज रिलीज! 1b03ab783b17th परिवर्तन का सेट! "। सहमत हूँ, इस सेट को एक नाम देने में सक्षम होना अच्छा होगा?



अच्छा, आपके पास ऐसा अवसर है। इस नाम को एक टैग (या टैग, अंग्रेजी टैग से) कहा जाता है।







आइए अब लॉग पर एक नज़र डालें:







ध्यान दें कि परिवर्तनों के एक सेट में एक टैग जोड़ना परिवर्तनों का एक सेट है। परिवर्तनों का यह सेट स्वचालित रूप से रिपॉजिटरी (कमिट) के लिए प्रतिबद्ध है। इसलिए अब हर बार जब हम जारी किए गए कोड के संस्करण का उल्लेख करना चाहते हैं, तो मैं 1b03ab783b17 के बजाय संस्करण -1.0 का उपयोग कर सकता हूं ।



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



बाकी गुआक 2.0 पर काम करने के लिए नौकरी पर लौट आए।







प्रतिबद्ध:







कहने की जरूरत नहीं है, यह नुस्खा अभी भी संदिग्ध है। उदाहरण के लिए, उसका परीक्षण नहीं किया गया था। और फिर ग्राहक कॉल करता है।



"यह बहुत नमकीन है!" ग्राहक ने कहा। और नहीं, वह त्रुटि के सुधार के साथ संस्करण 2.0 की रिहाई के लिए इंतजार नहीं करना चाहता है।



सौभाग्य से, हमारे पास वह टैग है। मैं भंडार में किसी भी संस्करण में जाने के लिए hg up



का उपयोग कर सकता हूं।







अब मैं इस नम नमक समस्या को ठीक कर सकता हूं:







तो:







मर्क्यूरियल मुझे याद दिलाता है कि मेरे कार्यों ने एक नया सिर बनाया। अब रिपॉजिटरी के दो प्रमुख हैं: संस्करण 2.0, जिसे मैंने हाल ही में काम किया था, और वह संस्करण जो मैंने अभी-अभी किया है।







फिलहाल, मैं क्लाइंट को नवीनतम परिवर्तनों के साथ संस्करण दे सकता हूं, इसे 1.1 के रूप में चिह्नित कर सकता हूं, और संस्करण 2.0 के साथ काम करना जारी रख सकता हूं।







लेकिन एक समस्या है ... संस्करण 2.0 में नमक के बारे में सुधार अनुपस्थित हैं। मैं इसे कैसे ठीक कर सकता हूं?











खैर यहाँ। मुझे एक टैग मर्ज करना होगा। यह मर्क्यूरियल में एक ज्ञात बग है। समस्या यह है कि मर्क्यूरियल में टैग केवल .hgtags नामक एक फ़ाइल है, जिसमें संस्करण नियंत्रण भी है। इसलिए, समय-समय पर, आपको .httags फ़ाइल के विभिन्न संस्करणों को मैन्युअल रूप से मर्ज करने की आवश्यकता होती है। ऐसी स्थिति में, आपके कार्य सरल हैं ... आपको हमेशा एक फ़ाइल में प्रत्येक पंक्ति के बीओटीएच संस्करणों को सहेजना चाहिए।







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



इसलिए अब मैं 1.0 के बाद किए गए सभी परिवर्तनों को पूर्ववत कर दूंगा, राज्य को रिपॉजिटरी को वापस कर दूंगा जो कि 1.0 रिलीज के समय था, और फिर मैं आपको मौजूदा क्लाइंट्स के बग्स को ठीक करने और समानांतर रूप से नए संस्करण पर काम करने के लिए एक फैशनेबल विश्वसनीय तरीका दिखा सकता हूं।







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



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



देव रिपॉजिटरी वह जगह है जहां अगला प्रमुख संस्करण विकसित किया जा रहा है, अर्थात संस्करण 2.0।



जैसे ही संस्करण 1.0 जारी किया जाता है, मैं देव में स्थिर हो जाता हूं:







अब मेरे पास दो समान रिपॉजिटरी हैं:







चूंकि दोनों रिपॉजिटरी में इतिहास 14 वें सेट के परिवर्तन तक समान है, इसलिए समावेशी, मर्क्यूरियल डिस्क पर दो प्रतियां बनाने के बजाय हार्ड लिंक का उपयोग करेगा। इसलिए, hg clone



ऑपरेशन तेज और सस्ता है, जिसका मतलब है कि आप बिना किसी हिचकिचाहट के कई, कई रिपोजिटरी क्लोन बना सकते हैं।



अब देव भण्डार में गुआक पर काम करना शुरू करते हैं:







और स्थिर भंडार में नमक की समस्या को ठीक करें:







मैं इस संस्करण को ध्वजांकित करूंगा और इसे 1.1 के रूप में जारी करूंगा:







अब, समय-समय पर, हमें स्थिर से देव में परिवर्तन करने की आवश्यकता है:







यहाँ हम क्या किया है:







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



कई रिपॉजिटरी में अन्य उपयोग हैं।

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

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

खुद को परखो

इस भाग को पढ़ने के बाद आपको क्या करना चाहिए:

1. पुराने संस्करणों को चिह्नित करें और उन पर वापस लौटें।
2. टीम के काम को दो रिपॉजिटरी (स्थिर और देव) के साथ व्यवस्थित करें।

खैर, ऐसा हुआ कि हम मैनुअल के अंत तक पहुंच गए। मैं मर्क्यूरियल की सभी विशेषताओं का वर्णन करने के लिए करीब नहीं आया हूं, लेकिन गहन अध्ययन के लिए पर्याप्त सामग्री है। एक किताब है जो सब कुछ महान विस्तार से वर्णन करती है। और यदि आपके कोई प्रश्न हैं, तो मैं आपको भट्ठा ज्ञान विनिमय वेबसाइट पर आमंत्रित करता हूं (यह केवल StackOverflow की तरह है, और भोजनालय के बारे में प्रश्न इस साइट पर स्वागत से अधिक हैं)।



अनुवादक से टिप्पणी:

यदि आप, मेरी तरह, guacamole देखने में रुचि रखते हैं, तो यहाँ एक वीडियो है जो इस व्यंजन की खाना पकाने की प्रक्रिया को दर्शाता है।