2009-11-24 13 views
6

फाइलों के टाइमस्टैम्प को संरक्षित करते समय एक मर्कुरियल रिपोजिटरी का बैक अप लेने का कोई तरीका है?टाइमस्टैम्प को संरक्षित करते समय एक मेरकोरियल रिपोजिटरी का बैक अप लेना

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

समस्या यह है कि hg clone वर्तमान समय में सभी फ़ाइलों के टाइमस्टैम्प को बदलता है, इसलिए बैकअप प्रोग्राम (जिसे मैं नहीं बदल सकता) सोचता है कि सब कुछ संशोधित किया गया है।

उत्तर

5

मैं hg clone के बजाय hg pull का उपयोग करने का सुझाव देता हूं। तो आप अपने सर्वर पर रिपॉजिटरी का दर्पण रखेंगे और इसे समय-समय पर hg pull के साथ अपडेट करेंगे। फिर आप अपने बैकअप प्रोग्राम को का बैकअप लेने दें। जब आप hg pull का उपयोग करते हैं तो आप नवीनतम इतिहास को स्थानांतरित कर देंगे और केवल .hg/store/data के अंतर्गत फ़ाइलों को बदल देंगे जो वास्तव में पुल से प्रभावित होते थे।

यहां मैंने दो फाइलों के साथ एक छोटा रेपो बनाकर इसका परीक्षण किया: a.txt और b.txt। मैंने hg clone --noupdate का उपयोग करके "सर्वर पर" भंडार को क्लोन किया। यह सुनिश्चित करता है कि हमारे पास सर्वर पर कोई कार्यशील प्रतिलिपि नहीं है - इसे केवल .hg में मिले इतिहास की आवश्यकता है।

timestamps क्लोन के बाद इस तरह देखा:

 
% ll --time-style=full .hg/store/data 
total 8.0K 
-rw-r--r-- 1 mg mg 76 2009-11-25 20:07:52.000000000 +0100 a.txt.i 
-rw-r--r-- 1 mg mg 69 2009-11-25 20:07:52.000000000 +0100 b.txt.i 

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

 
% ll --time-style=full .hg/store/data 
total 8.0K 
-rw-r--r-- 1 mg mg 159 2009-11-25 20:08:47.000000000 +0100 a.txt.i 
-rw-r--r-- 1 mg mg 69 2009-11-25 20:07:52.000000000 +0100 b.txt.i 

सूचना कैसे a.txt.i के लिए टाइमस्टैम्प अपडेट कर दिया गया है, जबकि b.txt.i के लिए टाइमस्टैम्प अकेला छोड़ दिया गया है (मैं सिर्फ अपने लिए प्रतिबद्ध में a.txt छुआ): changeset खींच के बाद मैं इन टाइम स्टांप मिला है।

यदि आपका बैकअप सॉफ़्टवेयर स्मार्ट है, तो यह भी ध्यान देगा कि Mercurial ने केवल a.txt.i पर डेटा जोड़ा है। इसका मतलब है कि नई a.txt.i फ़ाइल पुरानी a.txt.i फ़ाइल के समान कुछ बिंदु तक समान है - इसलिए बैकअप प्रोग्राम को केवल फ़ाइल के अंतिम भाग की प्रतिलिपि बनाना चाहिए। रुनैक एक बैकअप प्रोग्राम का एक उदाहरण है जो इसे नोटिस करेगा।

6

योजना: स्रोत और गंतव्य निर्देशिका एक ही फाइल सिस्टम पर निवास करते हैं, hg clone -U बस अपने सभी फ़ाइलों को भंडार में, timestamps बदले बिना hardlink होगा। यह दृष्टिकोण काफी तेज़ और हमेशा सुरक्षित है (फाइलों को लिखे जाने पर आलसी रूप से अनलिंक किया जाता है)।

यदि आपको आवश्यकता है, तो आप पहले उसी फ़ाइल सिस्टम पर क्लोन कर सकते हैं, और उसके बाद इस नए क्लोन को किसी अन्य फ़ाइल सिस्टम पर rsync कर सकते हैं।

प्लान बी: ​​ यह rsync या कोई अन्य फ़ाइल आधारित तुल्यकालन उपकरण का उपयोग करने आमतौर पर सुरक्षित है। Mercurial डिस्क पर जादुई कुछ भी स्टोर नहीं करता है, बस सादे फाइलें।

एक दौड़ हालत, नहीं है जब आप एक ही समय जब rsync चल रहा है पर इस भंडार के लिए प्रतिबद्ध होता है, लेकिन मुझे लगता है कि यह नगण्य है, क्योंकि एक "hg rollback" अगर आप से बहाल अपने ऐसे विसंगतियों को साफ करने में सक्षम होना चाहिए एक टूटा बैकअप। ध्यान दें, रोलबैक नहीं हो सकता है यदि आपके पास rsync विंडो में एकाधिक अलग-अलग लेन-देन (जैसे एकाधिक "पुश" या "प्रतिबद्ध" कमांड) थे, या इतिहास के साथ छेड़छाड़ करने वाले विनाशकारी संचालन चलाएं (जैसे रीबेस, hg strip, और कुछ एमक्यू कमांड)।

+0

हाँ, यह दौड़ की स्थिति है जिसके बारे में मुझे चिंता है। क्या आप यह बताने में सक्षम होंगे कि 'एचजी रोलबैक' की आवश्यकता कब होगी? –

+0

'hg verify' आपके भंडार में सभी चेकसम/संशोधन हैश की जांच करेगा और आपको त्रुटियों के बारे में बताएगा। – intgr

+0

इस पर एक और टिप्पणी (आप जोड़ना चाहेंगे): 'एचजी क्लोन-यू' जाने का तरीका है, क्योंकि क्लोन की काम करने वाली प्रतिलिपि में कठोर लिंक नहीं हैं। बस भंडार करता है। –

संबंधित मुद्दे

 संबंधित मुद्दे