संस्करण नियंत्रण प्रणाली के साथ मेरा पहला परिचित स्कूल में वापस आ गया था। यह तोड़फोड़ थी। उस समय मैं उनकी ताकत और क्षमताओं से बहुत प्रभावित था। लेकिन समय बीतता गया। फ़ाइलों, निर्देशिकाओं और अधिक (हाँ, लंबे समय तक रहने वाले svn 1.5, 1.6 और इसके शाश्वत फ़ोल्डर .vn) का नाम बदलने के साथ बहुत सुखद क्षण नहीं थे। और सब कुछ उसी नस में जारी रहता अगर एक दिन कंपनी ने संस्करण नियंत्रण प्रणाली को बदलने के बारे में नहीं सोचा होता। सब कुछ अप्रत्याशित रूप से जल्दी से हुआ और मेरे सामने मर्क्यूरियल प्रकट हुआ। मुझे इसकी विशेषताओं के बारे में पढ़ना था, अनुभवी युक्तियों के लिए पूछना था, और अब मैंने खुद अपने सहयोगियों को नए टूल के व्यवहार और कार्य का पता लगाने में मदद की। एचजी को जितना अधिक समय तक मैं जानता था, उतना ही मुझे यह पसंद आया, या बल्कि, मुझे संस्करण नियंत्रण के लिए इसका विकेन्द्रीकृत दृष्टिकोण पसंद आया, जबकि तोड़फोड़ अनिवार्य रूप से पृष्ठभूमि में फीका पड़ गया।
हालांकि, काम के नए स्थान पर, मुझे फिर से तोड़फोड़ को वापस बुलाना पड़ा, जिसने स्पष्ट रूप से मुझे खुश नहीं किया। सौभाग्य से, यह कंपनी की बिना शर्त नीति नहीं थी और विकल्प की पेशकश करना काफी संभव था, खासकर यह देखते हुए कि कुछ कर्मचारियों ने गिट को चुना और इसके साथ सफलतापूर्वक काम किया। तो, छोटी बात विकेंद्रीकृत संस्करण नियंत्रण प्रणालियों के साथ काम करने के फायदों को स्पष्ट रूप से प्रदर्शित करना है: गिट या मर्क्यूरियल, लेकिन, अपने व्यक्तिगत अनुभव के कारण, मैंने एचजी के बारे में बात करने का फैसला किया। दरअसल, यह लेख संस्करण नियंत्रण प्रणाली की तुलना करने और बदलने के उद्देश्य से मेरे द्वारा आयोजित गोल मेज का सारांश है।
कई राय हैं जिस पर संस्करण नियंत्रण प्रणाली बेहतर है। बेशक, प्रत्येक राय के लिए और उसके खिलाफ अपने तर्क हैं। हालांकि, कम से कम सबसे सरल परिदृश्य लें: 2 या अधिक लोग परियोजना पर काम कर रहे हैं, और परियोजना में आगे समर्थन और विकास शामिल है, कहते हैं, एक पुस्तकालय के रूप में, फिर इसे svn में संग्रहीत करना आपको मर्क्यूरियल में संग्रहीत करने की तुलना में बहुत अधिक परेशानी लाएगा।
आइए विशिष्ट विशेषताओं पर चलते हैं जो मर्क्यूरियल को बाकी हिस्सों से अलग करते हैं।
1. svn कमिट के विपरीत, hg पुश कमांड से आपको हमेशा पता चलेगा कि क्या किसी ने प्रोजेक्ट में कुछ बदलाव करने में कामयाबी पाई और सर्वर में ये बदलाव किए।
svn प्रतिबद्ध - दूरस्थ सर्वर पर स्थानीय परिवर्तन भेजने के लिए एक कमांड। यह परमाणु से होता है। हालाँकि, यह केवल तभी विफल होता है जब संस्करण जिस पर संशोधित फ़ाइलें आधारित हैं, अब दूरस्थ सर्वर पर अंतिम नहीं है। यही है, अगर निर्देशिका में दो फाइलें a.txt और b.txt हैं और आपने केवल b.txt को बदल दिया है, और पेटी केवल फाइल a.txt को बदल देता है, तो कमिट कमांड आपके लिए सफलतापूर्वक पूरी हो जाएगी और यदि आप svn अपडेट कमांड निष्पादित नहीं करते हैं (सभी फाइलों को अपडेट करें) नवीनतम संस्करण के लिए निर्देशिकाएं), फिर आप इसके बारे में नहीं जान पाएंगे। Svn किसी भी प्रोजेक्ट फ़ोल्डर से कमिट (और चेकआउट) का भी समर्थन करता है। इस वजह से, यदि आप एक फ़ोल्डर में करते हैं, तो आप दूसरे में बदलावों के बारे में नहीं जान पाएंगे।
hg पुश - hg कमिट कमांड के साथ पहले किए गए परिवर्तनों के सेट भेजने के लिए एक कमांड। अंतिम आदेश रिपॉजिटरी की वर्तमान स्थिति को कैप्चर करता है, लेकिन क्या यह पूरी तरह से स्थानीय स्तर पर है। केवल जब hg पुश कमांड निष्पादित होता है, तो परिवर्तन दूरस्थ सर्वर पर भेजे जाते हैं। चूंकि यह परिवर्तनों को अग्रेषित करने के लिए एक आदेश है, यह पूरी तरह से संपूर्ण भंडार तक विस्तारित होता है। इस प्रकार, इस कमांड के साथ, रिपॉजिटरी का पूरा राज्य पूरी तरह से दर्ज किया जाएगा। और अगर कोई आपके आगे बढ़ने में कामयाब रहा, तो इस स्थिति को क्रॉबर माना जाता है और डिफ़ॉल्ट रूप से, एचजी पुश विफल हो जाएगा, जो कहता है कि आपकी कार्रवाई रिमोट स्टोरेज में एक नया सिर बनाएगी।
पूर्णता के लिए, हम सिर को परिभाषित करते हैं। यह एक संशोधन है जो इस ब्रंच में कुछ अन्य संशोधन का जनक नहीं है। पॉलीहेड - एक ऐसी स्थिति जहां एक ब्रंच में एक से अधिक सिर होते हैं।
आइए अपनी स्थिति पर वापस जाएं जब कोई हमसे आगे निकल गया। उनके द्वारा त्रुटि वापस करने के बाद, हमें hg पुल कमांड बनाने की आवश्यकता है, जो हमें हमारे स्थानीय भंडारण के सभी लापता संशोधनों को खींच लेगा। फिर, यह ध्यान देने योग्य है कि यह कार्रवाई किसी भी तरह से हमारी फाइलों को प्रभावित नहीं करेगी। उनमें से किसी को नहीं बदला जाएगा। यह कमांड केवल इतिहास में उन परिवर्तनों की एक सूची को जोड़ता है जो हमारे पास नहीं थे। इस प्रकार, यदि आप भंडार में वर्तमान स्थिति के दृश्य को देखते हैं, तो हम देखेंगे कि हमने कई प्रमुखों का गठन किया है। स्थानीय भंडारण में पॉलीहेड्रॉन डरावना नहीं है। आखिरकार, हमने खुद इसे बनाया। यह अधिक खतरनाक है अगर हम रिमोट स्टोरेज पर समान स्थिति बनाते हैं और कोई व्यक्ति उसे मनाने के लिए प्रबंधन करता है। यह व्यक्ति अब यह नहीं समझ पाएगा कि कौन सा संस्करण सबसे अधिक प्रासंगिक है और उनके साथ कैसे काम करना है। वह दौड़ना, चीखना और कोसना शुरू कर देगा कि यह सब बहुत जटिल और समझ से बाहर है। इसलिए, हमें वर्तमान स्थिति में कभी भी धक्का नहीं देना चाहिए (Mercurial केवल hg push --force कमांड का उपयोग करके हमें ऐसा करने की अनुमति देगा, जो कि कभी नहीं किया जाना सबसे अच्छा है)। इस प्रकार, हमें दो लक्ष्यों का विलय करना होगा और एक प्राप्त करना होगा जो मर्क्यूरियल को दूरस्थ सर्वर पर सुरक्षित रूप से अपलोड कर सकता है।
और अब यह महत्वपूर्ण क्यों हो सकता है। यदि किसी कारण से किसी अन्य डेवलपर ने कुछ सामान्य घटक (तर्क, इंटरफ़ेस, या कुछ और) को बदल दिया, और आपको इसके बारे में पता नहीं था, तो svn के मामले में, दूरस्थ रिपॉजिटरी में गलत या गैर-संकलन कोड भी हो सकता है। उसी समय, इस तरह के पहले जंब को काफी जल्दी पता लगाया जा सकता है (फिर भी, हम समय-समय पर svn अपडेट करते हैं और संकलन शुरू करते हैं, ठीक है?), लेकिन दूसरे जांब की खोज परीक्षणों पर खींच सकती है। मर्क्यूरियल का तर्क आपको तुरंत बदलाव के बारे में जानने और मर्ज के साथ एक बार में सभी जांच करने की अनुमति देता है। बेशक, अगर आपने अपने काम के समानांतर समानांतर में क्या बदला है, तो आपने इसमें दिलचस्पी नहीं ली, तो आप svn के साथ उसी स्थिति में रहने का जोखिम उठाते हैं, लेकिन एक अंतर के साथ - पहले मामले में आपको इस बारे में पता भी नहीं था, और दूसरे में आपने स्कोर किया। ।
यह तर्क दिया जा सकता है कि यदि कोई व्यक्ति svn प्रतिबद्ध कमांड से पहले svn अपडेट कमांड नहीं बनाता है और कोड की जांच नहीं करता है, तो वह दोषी है और यहां कोई प्लस नहीं है, लेकिन यह एक गलत राय है। Svn में अद्यतन / प्रतिबद्ध आदेशों का गुच्छा परमाणु नहीं है, और hg पुश एक परमाणु संचालन है, जो जीवन को बहुत सरल करता है।
2. पुल, मर्ज कमांड के साथ, आप अपना राज्य नहीं खोते हैं, जिसे आपने अभी तक रिमोट सर्वर पर स्थानांतरित करने में कामयाब नहीं किया है, svj अद्यतन के विपरीत।
यह पहले ही उल्लेख किया गया है - पुल के साथ, आपको बस फाइलों को बदलने के बिना इतिहास में पहले से अज्ञात परिवर्तनों का एक सेट मिलता है। और चूंकि मर्क्यूरियल में मर्ज स्थानीय रूप से किया जाता है और स्थानीय संशोधनों के साथ, ये संशोधन कहीं खो नहीं जाते हैं। और यदि आप चाहें, तो आप हमेशा मर्ज परिणाम को हटा सकते हैं और इसे फिर से कर सकते हैं, या पूरी तरह से उस रिपॉजिटरी के संस्करण में वापस रोल कर सकते हैं जो सभी पुल / मर्ज से पहले था। Svn में, यह अवास्तविक है। अपनी वर्किंग कॉपी से svn अपडेट को अंजाम देने के बाद, आपको अपरिवर्तित, नई, स्वचालित रूप से सन्निहित फ़ाइलें, संघर्ष फ़ाइलें और आपके द्वारा परिवर्तित की गई सामान्य फ़ाइलों का एक हॉज मिल जाता है। इस मामले में, svn अद्यतन से पहले आपके पास उस रिपॉजिटरी राज्य में लौटना असंभव है। कोई रास्ता नहीं।
3. एक और छोटा बन - सेकंड में मर्क्यूरियल में भंडार के किसी भी संस्करण में रोलबैक। केवल सीमा यह है कि आपकी स्थानीय प्रतिलिपि साफ होनी चाहिए (बिना किसी परिवर्तन के)। यह hg अपडेट का उपयोग करके और वांछित संशोधन को निर्दिष्ट करके किया जा सकता है। उसी समय, आपको दूरस्थ सर्वर से कनेक्ट करने की आवश्यकता नहीं है, क्योंकि आपके पास स्थानीय रूप से संपूर्ण इतिहास है। Svn में, यह केवल एक दूरस्थ सर्वर के साथ किया जा सकता है और केवल वांछित संशोधन में फिर से रिपॉजिटरी डाउनलोड करके।
4. अक्सर ऐसा होता है कि आपको आवेदन के साथ तत्काल कुछ करने की आवश्यकता होती है। उदाहरण के लिए, वे आपके पास दौड़ते हुए आए और तुरंत एक बिल्ड प्राप्त करना चाहते हैं (क्योंकि मैं मोबाइल विकास में लगा हुआ हूं, ऐसा होता है, हालांकि एक बिल्ड सर्वर है)। और आपकी परियोजना पूरी तरह से बर्बाद हो गई है, क्योंकि आप किसी प्रकार की सुपर सुविधा काट रहे हैं। Svn में, आपको या तो अंतिम संशोधन से सभी प्रकारों को डाउनलोड करना होगा, या कोड को अधिक या कम कार्यशील स्थिति में वापस करने का प्रयास करना होगा, या कहें कि अब आप ऐसा नहीं कर सकते। सभी विकल्प बहुत सारे हैं और आमतौर पर बहुत समय लगता है। किसी भी विकेंद्रीकृत संस्करण नियंत्रण प्रणाली में, आप एक स्थानीय कमिट कर सकते हैं, और फिर कोड के किसी भी कार्यशील संस्करण में वापस आ सकते हैं और परियोजना का निर्माण कर सकते हैं। इस मामले में, उसके बाद आप उस रिपॉजिटरी की स्थिति में वापस आ जाएंगे जिसमें आप परेशान थे!
5. एक अन्य सामान्य घटना एक पुस्तकालय परियोजना का विकास है। और अगर आपको अप्रत्याशित रूप से एक परियोजना बनाने के लिए कहा गया था जो लंबे समय से लिखा गया था और एक पुस्तकालय का उपयोग किया गया था जो बाहरी svn द्वारा जुड़ा हुआ था, तो आपको बड़ी समस्याएं हो सकती हैं। यह बस इकट्ठा नहीं किया जा सकता है, क्योंकि इसमें पुरानी लाइब्रेरी का उपयोग किया गया था, जिसे वे फिर से लिखना, पुनर्निर्माण करना और इतने पर कामयाब रहे। एकमात्र तरीका यह है कि जिस संशोधन के साथ इस परियोजना ने काम किया है, उसकी तलाश करें और पुस्तकालयों को कॉपी-पेस्ट करें। हम पुस्तकालय के नए संस्करण का समर्थन करने के लिए परियोजना के एक मामूली खत्म होने के साथ विकल्प पर विचार नहीं करते हैं, क्योंकि बढ़ती समय के साथ इस तरह की संभावना तेजी से घट जाती है। मर्क्यूरियल में एक उप-रिपॉजिटरी की अवधारणा है, जो न केवल रिपॉजिटरी को संदर्भित करता है, बल्कि इसके विशिष्ट संस्करण को भी दर्शाता है। इस प्रकार, आप हमेशा जानते हैं कि परियोजना किस पुस्तकालय के किस संस्करण के साथ काम कर रही है और आप इसके परिवर्तनों से डर नहीं सकते।
6. मैंने पहले ही hg में शाखा का उल्लेख किया है। यह याद रखने योग्य है कि svn में शाखाएं कैसे कार्यान्वित की जाती हैं। ये रिपॉजिटरी की पूरी कॉपी के साथ सिर्फ फोल्डर हैं। संस्करण 1.5 से शुरू होकर, ऐसी फ़ाइलों का एक इतिहास दिखाई दिया, हालांकि, ये केवल फ़ोल्डर और फाइलें हैं। उनके साथ काम करने के लिए, आपको नामकरण और सामग्री के लिए विशेष नियमों का पालन करना होगा। भाड़े में, शाखाएँ रिपॉजिटरी और उसके परिवर्तनों की नामित अवस्था हैं। और जब शाखाओं के साथ काम करते हैं, तो सब कुछ ठीक उसी तरह होता है जैसे एक ही शाखा में काम करते समय। यह बहुत सरल है।
7. इसी तरह 6 बिंदु पर, हम टैग के बारे में बात कर सकते हैं।
8. अंत में, मैं कमिट्स के इतिहास के बारे में कहना चाहता हूं। यदि svn में यह पूरी तरह से सीधा है और यह कहना असंभव है कि आप वास्तव में संशोधन 2 पर आधारित थे, 10 नहीं, और यह पता नहीं था कि 3 से 10 तक क्या हो रहा है, हालांकि आपकी प्रतिबद्धता 11 वें नंबर पर होनी चाहिए ... मर्क्यूरियल में यह स्पष्ट रूप से दिखाई देगा आपने संस्करण 2 रिपॉजिटरी के साथ काम किया है और कमिट 3 'बनाया है और उसके बाद ही आपके परिवर्तन 3' में संशोधन 10 के साथ किया है। यदि आप कुछ महत्वपूर्ण घटनाओं का पता लगाना चाहते हैं तो ऐसा डेटा महत्वपूर्ण है।
लेख को सारांशित करते हुए, मैं यह नोट करना चाहता हूं कि जब भी मैं मर्क्यूरियल के साथ काम कर रहा हूं, तब तक इसके मंत्रों का नाम नहीं लिया जा सकता। कुछ इसकी गति पर पाप करते हैं, कुछ कमिट / पुश करने की जटिलता पर सर्वर में परिवर्तन करने के लिए आदेश देते हैं। मेरे लिए, यह कोई समस्या नहीं है, क्योंकि मैंने गति में कोई विशेष देरी नहीं देखी थी (निश्चित रूप से, रिपॉजिटरी के विशाल आकार के साथ, लेकिन ये जीवन की छोटी चीजें हैं), और दूसरा आदत का विषय है।
सामान्य तौर पर, सूचीबद्ध मर्क्यूरियल के कुछ लाभों को अन्य विकेन्द्रीकृत संस्करण नियंत्रण प्रणालियों में स्थानांतरित किया जा सकता है। और इस लेख के साथ, मैं मर्क्यूरियल के आधार पर, इस तरह के सिस्टम का उपयोग करने के सभी मुख्य लाभों को इकट्ठा करना चाहूंगा, एक उदाहरण के रूप में जिसके साथ मुझे खुद अनुभव था। मुझे उम्मीद है कि यह लेख उपयोगी होगा यदि आपको पसंद की पीड़ा का अनुभव करना है।
ps अंत में, हमने गिट = पर स्विच करने का फैसला किया