यह प्रश्न पारदर्शी प्रतिकृति के बारे में पूछता है , और मुझे संदेह है कि अभी तक कोई जवाब नहीं है क्योंकि लोगों को पारदर्शिता पर लटका दिया जा सकता है। मैं क्षण भर के लिए प्रतिकृति पर ध्यान केंद्रित करने के लिए एक तरफ पारदर्शिता स्थापित करने की स्वतंत्रता लूंगा। मैं बाद में (या चालाकी) पारदर्शिता से निपटूंगा, और वास्तव में मुझे नहीं लगता कि यह डीवीसीएस में महत्वपूर्ण है।
सबसे पहले, मुझे DVCS में रिपॉजिटरी काम करने के तरीके के बारे में कुछ मुख्य बिंदुओं को चलाने दें। (मैं मर्क्यूरियल से सबसे ज्यादा परिचित हूं, इसलिए मैं उदाहरणों के लिए इसका इस्तेमाल करूंगा, लेकिन मेरा मानना है कि मैं जो कुछ भी कहता हूं वह भी सच है।)
A. एक DVCS में, किसी भी क्लोन में मूल के रूप में एक ही फ़ाइल सामग्री और इतिहास होता है।
आपको रिपॉज को ठीक से सिंक में रखना, इसका मतलब है कि आप प्रतिकृति प्रणाली के निर्माण के लिए साधारण डीवीसीएस परिवर्तन प्रसार संचालन (क्लोन, पुश, पुल) और साधारण रिपोज का उपयोग कर सकते हैं।
B. नए बदलावों का प्रचार नहीं किया जाना चाहिए कि वे कहां से आए हैं।
विशेष रूप से, अगर मुझे किसी विशेष रेपो से परिवर्तन प्राप्त करने थे, और अपने स्वयं के कुछ परिवर्तन जोड़ने थे, तो मेरे परिवर्तनों को उस विशेष रिपो में वापस नहीं जाना है। वे कहीं और जा सकते हैं। इस की उपयोगिता मुझे नीचे दिखाए गए उदाहरणों से स्पष्ट हो जानी चाहिए।
C. परिवर्तन को पुश या पुल के माध्यम से प्रचारित किया जा सकता है।
एक केंद्रीकृत प्रणाली में, नए बदलाव बहुत ज्यादा हो सकते हैं (मुझे लगता है) केवल रेपो में धकेल दिया जाएगा। एक डीवीसीएस में, कई प्रकार के परिवर्तन प्रसार टोपोलॉजी स्थापित करना संभव है, जिनमें से कुछ में केवल पुलिंग शामिल है। यह सेटअप में अधिक लचीलापन देता है।
उदाहरण
चर्चा के लिए मान लें कि आपकी वितरित टीमें डोमेन में सिस्टम का उपयोग करती हैं duke.de, duke.us, duke.cn, और duke.mx, और आगे यह कि ड्यूक.डॉ हम "धन्य" रेपो चाहते हैं। इन मान्यताओं को देखते हुए, आप ऊपर स्थापित तीन प्रमुख डीवीसीएस बिंदुओं को ध्यान में रखते हुए विभिन्न टोपोलॉजी के कई उदाहरण प्रस्तुत कर सकते हैं।
0. केंद्रीकृत पुश मॉडल
Hg.duke.de पर एक ही रेपो रखें और सभी स्थानों में डेवलपर्स को क्लोन करें और यहां से खींचें और यहां परिवर्तनों को धक्का दें। यह जर्मनी में लोगों के लिए काम कर सकता है, लेकिन यह शायद दुनिया के बाकी हिस्सों में लोगों के लिए एक समस्या होगी। सभी क्लोन, पुल और पुश ऑपरेशन धीमे लंबे-पतले नेटवर्क लिंक पर जाएंगे। यह एक केंद्रीकृत प्रणाली की तरह ही DVCS का उपयोग कर रहा है। यह वह समस्या है जिसे आप हल करने का प्रयास कर रहे हैं।
1. प्रतिकृति के साथ केंद्रीकृत पुश
Hg.duke.de पर धन्य रेपो लें और hg.duke.cn, hg.duke.mx और hg.duke.us पर प्रतिकृतियां रखें। डेवलपर्स अपनी स्थानीय प्रतिकृति से क्लोन करते हैं और hg.duke.de में परिवर्तन धक्का देते हैं। जब भी hg.duke.de में नए परिवर्तन दिखाई देते हैं, एक हुक चलता है जो उन्हें प्रतिकृतियों में प्रसारित करता है। प्रतिकृतियां अन्यथा केवल पढ़ी जाती हैं, इस प्रकार कभी कोई विलय या टकराव नहीं होगा।
उदाहरण के लिए, यदि मैं मेक्सिको में एक डेवलपर हूं, तो मैं hg.duke.mx से क्लोन करूंगा लेकिन परिवर्तन को hg.duke.de पर धकेलूंगा। यदि अन्य परिवर्तन hg.duke.de में धकेल दिए जाते हैं तो इससे पहले कि मैं अपने परिवर्तनों को धक्का दे सकूं, मेरा धक्का अवरुद्ध हो जाएगा। अन्य परिवर्तनों को hg.duke.mx पर दोहराया जाएगा, इसलिए मैं इन परिवर्तनों को स्थानीय रूप से खींचूंगा, मर्ज करूंगा, और फिर hg.duke.de पर फिर से धकेलने का प्रयास करूंगा।
यह कुछ फायदे प्रदान करना चाहिए, क्योंकि बड़े क्लोन ऑपरेशन सभी स्थानीय स्तर पर किए जाते हैं। केंद्रीय रेपो को किसी अन्य स्थान पर पुश करना बहुत बुरा नहीं हो सकता है, क्योंकि परिवर्तन को अपेक्षाकृत रूप से धक्का दिया जाता है, वृद्धिशील परिवर्तन आम तौर पर काफी छोटे होते हैं। (विशेष रूप से अनिवार्य रूप से संपीड़ित भिन्नताएं भेजता है, संपूर्ण फाइलें और उनके इतिहास नहीं।)
मर्क्यूरियल में, आप .hg/hgrcफ़ाइल में निम्नलिखित की तरह कुछ डालकर एक स्थान से खींचने के लिए एक स्थानीय रेपो सेट कर सकते हैं और दूसरे को धक्का दे सकते हैं :
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. सरल खींचो मॉडल
धन्य रेपो के रूप में hg.duke.de और दूसरों के साथ प्रतिकृतियों के रूप में जारी रखते हुए, हम पुश के बजाय पुल के माध्यम से परिवर्तन का प्रचार कर सकते हैं। डेवलपर्स क्लोन और हमेशा की तरह अपनी स्थानीय प्रतिकृति से खींचते हैं। जब कोई परिवर्तन तैयार होता है, तो एक डेवलपर कुछ केंद्रीय सेवा के लिए एक पुल अनुरोध सबमिट करता है, जो डेवलपर के रेपो से hg.duke.de में खींचता है। मर्जों के लिए एक नीति स्थापित करने की आवश्यकता होगी। उदाहरण के लिए, यदि मर्ज संघर्ष हैं, तो अनुरोध को अस्वीकार कर दिया जा सकता है, जिसके लिए डेवलपर को स्थानीय प्रतिकृति से खींचने की आवश्यकता होती है, मर्ज करें, और पुल अनुरोध को पुनः सबमिट करें।
इस दृष्टिकोण का लाभ डेवलपर को इंतजार नहीं करने का है जबकि परिवर्तनों का प्रचार किया जा रहा है। बेशक, अभी भी देव को पुल के अनुरोध पर इंतजार करना पड़ता है, लेकिन कम से कम वह इस समय के दौरान अतिरिक्त बदलावों पर काम कर सकते हैं।
बदलाव
विविधताओं का एक समूह है जिन्हें लागू किया जा सकता है।
एक पुल अनुरोध प्रस्तुत करना कोड समीक्षा के लिए एक सही समय है। परिवर्तन प्रकाशित किए गए हैं, इस अर्थ में कि वे सभी के लिए उपलब्ध हैं, लेकिन वे अभी तक धन्य रेपो में एकीकृत नहीं हुए हैं।
पुल अनुरोधों को मैन्युअल रूप से या कुछ स्वचालित प्रणाली द्वारा कार्य किया जा सकता है। पुल अनुरोध को संसाधित करने से धन्य रेपो में सीधे परिवर्तन नहीं हो सकते हैं, लेकिन इसके बजाय एक अस्थायी मंचन क्षेत्र में जहां एक निर्माण और परीक्षण चक्र किया जाता है। सभी परीक्षणों को पारित करने के बाद ही बदलाव को रेपो रेपो में एकीकृत किया जाएगा।
एक पुश मॉडल के साथ और अधिक आरामदायक प्रत्येक स्थान में एक स्थानीय स्टेजिंग रेपो स्थापित करना चाह सकते हैं, प्रतिकृति के साथ, जैसे- hg-stage.duke.mx, hg-stage.duke.cn, आदि। इसके लिए थोड़ा और काम करने की आवश्यकता है। हालांकि, डेवलपर्स के रूप में न केवल अन्य स्थानीय परिवर्तनों के खिलाफ विलय करना है, लेकिन किसी को स्टैपिंग रिपोज से धन्य रेपो में विलय के लिए जिम्मेदार होना है। यह सही परिस्थितियों में काम कर सकता है, हालांकि, और स्वचालन द्वारा सहायता प्राप्त की जा सकती है।
"पारदर्शिता"
अब पारदर्शी प्रतिकृति के मुद्दे पर।
उपरोक्त परिदृश्यों को देखते हुए मुझे वास्तव में पारदर्शी प्रतिकृति की आवश्यकता नहीं है। सभी रेपो हर किसी को दिखाई देते हैं, और स्थानीय प्रतिकृति से खींचने / क्लोनिंग करने और एक धन्य रेपो या एक स्थानीय स्टेजिंग क्षेत्र में धकेलने के लिए कन्वेंशन हैं।
यदि आप पारदर्शिता चाहते हैं, तो आप लोग अपने स्थान के अनुसार DNS खोज डोमेन सेट कर सकते हैं। स्थानीय प्रतिकृति और स्टेजिंग रिपोस को बस "hg" और "hg-stage" के रूप में संदर्भित किया जाएगा और DNS सेटअप इन्हें hg.duke.cn और hg-stage.duke.cn के लिए चीन में डेवलपर्स के लिए हल करेगा, और इसके लिए अन्य स्थानों में डेवलपर्स। लेकिन यह थोड़ा सा जादू है और भ्रामक हो सकता है, और मुझे नहीं लगता कि यह बहुत जोड़ता है।
हम उम्मीद करते है कि यह आपके सवाल का जवाब दे देगा। मैंने प्रतिक्रिया के साथ कई स्वतंत्रताएं लीं, लेकिन मुझे लगता है कि आपकी स्थिति को ऊपर बताई गई तकनीकों के उपयोग के माध्यम से फिर से बनाया जा सकता है।