इस सेटअप के लिए एक अच्छा Mercurial उपयोग पैटर्न क्या है?

Question

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

मैं दो बंद नेटवर्क डेवलपर्स में से एक हूं, हमें "मास्टर" स्थान पर विचार करें।

समूह के लिए सबसे अच्छा Mercurial सेटअप/पैटर्न क्या है? रिमोट डेवलपर्स में/से परिवर्तनों को ट्रेस करने का सबसे अच्छा तरीका क्या है? जैसा कि मैं प्रभारी हूं, मुझे लगा कि मुझे कम से कम एक मास्टर रेपो रखना होगा जिसमें एक और स्थानीय रिपो है जिसमें मैं विकसित कर सकता हूं। एक दूसरे व्यक्ति को सिर्फ मास्टर के क्लोन की आवश्यकता होनी चाहिए। क्या यह सही है? मुझे लगता है कि यह मुझे विलय के लिए ज़िम्मेदार बनाता है?

जैसा कि आप देख सकते हैं, मैं अभी भी वितरित संस्करण नियंत्रण के आसपास अपने सिर को लपेटने की कोशिश कर रहा हूं। मुझे नहीं लगता कि कनेक्टिविटी की स्थिति के साथ ऐसा करने का कोई और तरीका है।

Answer 1

नेटवर्क के बाहर उपयोगकर्ता patches बना सकते हैं, और/या email का उपयोग मुख्य रिपो या किसी को अपडेट भेजने के लिए करते हैं, जैसे कि उन्हें मर्ज करने के लिए। अन्य आंतरिक लोगों में स्थानीय प्रतियां हो सकती हैं, जैसे कि आप विलय करते हैं - लेकिन यदि आप इन्हें नेटवर्क पैच से बाहर कर रहे हैं, तो यह बेहतर हो सकता है कि एक व्यक्ति उनके साथ सौदा करे ताकि कोई भी भ्रमित न हो, लेकिन ऐसा कुछ है जो आपको करना होगा स्वयं विचार करो।

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

ये मेरे एकमात्र सुझाव हैं - बिलकुल स्पष्ट, उन्हें एक वीपीएन कनेक्शन प्राप्त करें! मुझे यह सुनना अच्छा लगेगा कि यह कैसे जाता है, साप्ताहिक नाली, एट कैटेरा में क्या योजनाएं स्थिर होती हैं।

Answer 2

सही। बंद नेटवर्क पर इसे किसी भी तरह से बनाता है फ्लैश ड्राइव के माध्यम से।

Answer 3

पैच एक साधारण और बहुमुखी समाधान हैं।

परिवर्तनों के बड़े समूहों (विशेष रूप से बाइनरी परिवर्तन और विलय) के चारों ओर जाने के लिए, Mercurial बाइनरी बंडल प्रदान करता है। एक बंडल मूल रूप से बाइनरी सामान होता है जो नेटवर्क पर भेजा जाता है जब आप hg push करते हैं, लेकिन यहां इसे फ़ाइल में कैद किया जाता है।

चलो कल्पना करें कि मुझे किसी भी तरह से क्लोन मिला है (फ्लैश ड्राइव, डीवीडी, आदि द्वारा)। इसे upstream पर कॉल करें। मैं फिर दूसरा क्लोन बना देता हूं, इसे devel पर कॉल करें। मैं devel में अपना पूरा विकास करता हूं और बहुत सारे काम करता हूं, विलय करता हूं, आदि। Mercurial वितरित होने के बाद से मैं यह सब ऑफ़लाइन कर सकता हूं।

देखने के लिए जो changesets upstream में याद कर रहे हैं मैं

% hg outgoing ../upstream 

जब मैं कुछ है भेजने के लिए, मैं

% hg bundle changes.hg ../upstream 

उपयोग कर सकते हैं एक द्विआधारी संपीडित फ़ाइल जो सभी सहित changesets शामिल पाने के लिए उनके मेटा डेटा। मैं फिर इस फाइल को एक सीडी पर जला सकता हूं और इसे मेल द्वारा भेज सकता हूं ...

बंडल के प्राप्तकर्ता

% hg incoming changes.hg 

changeset सूची और

% hg pull changes.hg 

खोल और उसके भंडार के लिए changesets जोड़ने के लिए देखने के लिए कर सकते हैं। उसके बाद उसे सबसे अधिक विलय करना होगा - यह बिल्कुल वैसा ही है जैसे उसने सीधे आपके भंडार से HTTP या SSH पर खींच लिया था।

नोट, upstream भंडार केवल यह याद रखने के लिए सुविधाजनक तरीका के रूप में उपयोग किया जाता है कि अपस्ट्रीम रिपोजिटरी में कौन से बदलाव पहले ही पाए गए हैं। आप बेससेट (सामान्य) परिवर्तन निर्दिष्ट करने के लिए बंडल करते समय भी परिवर्तन आईडी को कम कर सकते हैं और hg bundle --base का उपयोग कर सकते हैं। hg help bundle या look in the wiki देखें।