मर्क्यूरियल: जहां कार्यान्वयन शुरू करना है और पैच की आवश्यकता क्यों है

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

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

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

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

मर्क्यूरियल कैसे लागू करना शुरू करें?

जब डेवलपर अकेला होता है, तो यह सवाल नहीं उठता है। मैंने डाउनलोड किया, स्थापित किया, यह पता लगाया, इसका उपयोग किया।

यदि टीम छोटी है, तो, सामान्य श्रमिकों की ओर से समझ की अनुपस्थिति में, यह स्वैच्छिक-अनिवार्य आधार पर ऊपर से डिक्री या नीचे से एक लंबी शिक्षा के आधार पर किया जाता है। एक समझ के साथ, सब कुछ अपने आप निकलता है।

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

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

यह समझाने के लिए कि यह क्यों आवश्यक है, मैं कुछ उदाहरण दूंगा।

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

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

Mercurial`om का उपयोग कैसे करें के बारे में और मैं टीम को नहीं बताऊंगा, क्योंकि उनकी साइट प्रलेखन से भरी है।

हमें मर्क्यूरियल में पैच की आवश्यकता क्यों है?

पैच एक बहुत शक्तिशाली और विवादास्पद व्यापारिक विशेषता है।

प्रारंभ में, hg में केवल कमिट्स (कमिट) द्वारा परिवर्तन करने की क्षमता थी, जिसे रिपॉजिटरी में जोड़े जाने के बाद तय नहीं किया जा सकता था, अंतिम को छोड़कर, इसे वापस रोल किया जा सकता था। लेकिन केवल एक। समय के साथ, mq एक्सटेंशन दिखाई दिया, जिसने एक नियमित प्रतिबद्ध के समान पैच बनाने की अनुमति दी, लेकिन परस्पर। यानी एक पैच अंतिम प्रतिबद्ध / पैच से परिवर्तन का एक सेट है जिसे ठीक किया जा सकता है।

यह एक ही समय में ताकत और कमजोरी है। इस की ताकत यह है कि यदि आप कुछ भूल गए, सील कर दिया गया, एक त्रुटि नहीं देखी गई, तो यह इस बदलाव में ठीक किया जा सकता है। पैच [और] चैट / icq / jabber / ई-मेल, आदि के माध्यम से भेजा जा सकता है, क्योंकि पूरे कार्यक्रम की तुलना में, यह छोटा है। यहां हम कह सकते हैं कि एक तथाकथित है बंडल, अर्थात दोनों के बीच भंडार का एक टुकड़ा है, लेकिन आप बस पैच को खोल सकते हैं और इसे देख / मूल्यांकन कर सकते हैं, फिर इसे ठीक कर सकते हैं, यदि आवश्यक हो, लेकिन बंडल नहीं है।

पैच की कमजोरी यह है कि जितना अधिक वे होते हैं, उतना ही अधिक यह भंडार में उनके भंडारण के साथ गड़बड़ करने की संभावना है। या, कतार में सबसे पुराने पैच को सही करते समय, आपको सभी अन्य को संपादित करने की आवश्यकता हो सकती है जो इस संपादन को प्रभावित कर सकते हैं।

यहाँ से हम निष्कर्ष निकाल सकते हैं:

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

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

अभी के लिए बस इतना ही। शायद कोई मदद करेगा।