2010-06-14 6 views
9

हमारी प्रोजेक्ट फाइलों में, यदि बाइनरी फाइलें हैं, जैसे कि .doc, .xls, .jpg, और हम अपने पिछले संशोधन को नहीं रखना चुनते हैं (केवल नवीनतम संस्करण रखना ठीक है) क्या इन फ़ाइलों के लिए या किसी विशेष फ़ोल्डर के लिए संशोधन को छोड़ने के लिए एसवीएन, गिट, या मर्कुरियल या कुछ अन्य टूल बताने का कोई तरीका है?क्या कोई संस्करण नियंत्रण प्रणाली जैसे एसवीएन, गिट, या मर्कुरियल आपको "नवीनतम संस्करण रखना" है, लेकिन संशोधन नहीं? (जैसे बाइनरी फाइलों के लिए)

कहें, एक 4 एमबी। डॉक फ़ाइल है जिसे मुझे सौ बार जांचने की ज़रूरत है, लेकिन मुझे वास्तव में इसके पिछले संस्करणों के बारे में बहुत कुछ परवाह नहीं है। तो अगर प्रणाली इसके 100 संशोधन रखती है, तो यह पहले से ही 400 एमबी है ... 300 बार जांचना मतलब है कि 1 फाइल के लिए 1.2 जीबी और यह अच्छा नहीं है। केवल नवीनतम संस्करण अच्छा है ताकि हर कोई इसे सिंक कर सके। इसके अलावा मैं नहीं चाहता कि अन्य लोग परियोजना की जांच करें और 20 जीबी सामान की जांच करनी हों। (क्या गिट और मर्कुरियल प्रत्येक व्यक्ति के स्थानीय भंडार में सभी संशोधन रखेंगे?)

+8

निश्चित रूप से, उनमें से बहुत से: उन्हें "फाइल सिस्टम" कहा जाता है। :-) – Ken

+2

आप पिछले संशोधन के बारे में क्यों परवाह नहीं करेंगे? जब तक यह स्वचालित रूप से जेनरेट की गई फ़ाइलें न हो, और तब कोई तर्क हो कि वे संस्करण नियंत्रण में नहीं हो सकते हैं। –

+1

लेकिन फाइल सिस्टम आपको फाइलों को हटाने, इसके अलावा, फ़ाइलों का स्वचालित नाम बदलने के लिए सिंक नहीं करेगा। यह फ़ोल्डरों के किसी भी संरचना में बदलाव के लिए भी समन्वयित नहीं होगा। निष्कर्ष के लिए –

उत्तर

2

मुझे पता है कि यह ऐसा करता है, लेकिन आपको उत्तर पसंद नहीं है।

इसका विजुअल सोर्सएफ़। फ़ाइल पर ध्वज 'स्टोर केवल नवीनतम संस्करण' की जांच करें और यह इतिहास को रोकना बंद कर देता है।

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

1

संस्करण नियंत्रण प्रणाली की प्राथमिक ज़िम्मेदारी परिवर्तनों का इतिहास रखना है, इसलिए मुझे नहीं लगता कि यह संभव है। जब आप केवल नवीनतम संस्करण चाहते हैं तो संस्करण नियंत्रण का उपयोग क्यों करें?

0

सामान्य रूप से, नहीं: एक वीसीएस पूरे इतिहास को रखने का इरादा रखता है। हालांकि, अंतरिक्ष मोर्चे पर सब खो नहीं है; आपके द्वारा नामित सभी सिस्टम प्रत्येक संशोधन के लिए बाइनरी diffs स्टोर करेंगे, पूरी फ़ाइल की पूरी प्रति नहीं। इसका मतलब है कि आवश्यक स्थान अक्सर बहुत कम होगा।

17

ध्यान दें कि यह काफी जवाब नहीं है।

अगर मैं पोस्टरिटी के लिए फ़ाइल के सही संस्करण को न रखने के बारे में चर्चा करता हूं, तो मैं कम से कम आपके प्रश्न के एक हिस्से पर टिप्पणी करूंगा, जो आपको फाइल के सभी संशोधन को भंडार में नहीं रख सकता है।

संस्करण नियंत्रण प्रणाली आमतौर पर संपूर्ण फ़ाइल को प्रत्येक नए संशोधन पर संग्रहीत नहीं करती है, वे परिवर्तनों को संग्रहित करते हैं। सिस्टम के आधार पर, आपको कभी-कभी फ़ाइल की पूरी प्रतिलिपि हो सकती है, लेकिन अधिकांश परिवर्तन केवल परिवर्तन ही होंगे।

उदाहरण के लिए, मर्क्युरियल में, मैं इस कोशिश की: http://download.microsoft.com/download/3/8/8/388e7205-bc10-4226-b2a8-75351c669b09/CSharp%20Language%20Specification.doc

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

तब मैं फ़ाइल खोला, और 4.0 (उद्धरण के बिना) के साथ 3.0 की सभी आवृत्तियां बदल गया है, और VB साथ C# की सभी आवृत्तियां, और बचा लिया। फिर मैंने एक एकल अक्षर टिप्पणी के साथ नया संस्करण किया। प्रतिबद्धता के बाद भंडार का आकार अब 3.497.9 84 बाइट है। अंतर 512 केबी है (भंडार में शामिल कुछ खंड हैं, इसलिए आकार सटीक 512 केबी मूल्य है।)

यदि अब मैं फ़ाइल को फिर से खोलता हूं, तो शीर्षक पृष्ठ VB को वापस सी # में बदलें, सहेजें, और फिर से प्रतिबद्ध करें , भंडार का आकार 276 केबी तक बढ़ता है, 3.780.608 बाइट तक।

जैसा कि आप देख सकते हैं, परिवर्तन फ़ाइल की पूरी प्रतिलिपि नहीं करते हैं, लेकिन यह देखते हैं कि मतभेद "10 केबी" श्रेणी में नहीं हैं।

आइए मान लें कि प्रत्येक फ़ाइल का औसत आकार अकेले इस फ़ाइल के लिए कुछ हद तक होगा, मान लें कि दो मानों के बीच औसत 50% है। इसका मतलब यह है कि इस फ़ाइल में बदलावों की 300 चीजें हैं, औसत 394 केबी औसत 115 एमबी है।यह बहुत कुछ नहीं है

मेरे सुझाव इस प्रकार है:

cheapskates
  • बंद किया जा रहा है, डिस्क स्थान सिरदर्द जब कोई कहते हैं, "मैं वास्तव में चाहते हैं कि मैं क्या जानता था कि तुम होगा की तुलना में सस्ता है, फ़ाइल को दूषित करने से पहले पिछले हफ्ते की तरह लग रहा था "।
+0

+1! काम पर –

+1

, जब हार्ड डिस्क स्थान शायद ही कभी उपयोग किया जाता है, मुझे लगता है कि इससे कोई फर्क नहीं पड़ता। यदि यह घर का कंप्यूटर है, तो मैं वास्तव में 20 जीबी, 30 जीबी या 60 जीबी बर्बाद नहीं करना चाहता हूं क्योंकि प्रत्येक घर कंप्यूटर पर समय बीतता है। अगर कंप्यूटर में 300 जीबी हार्ड ड्राइव है, तो मैं इसकी देखभाल करने की वजह से इसका 10% बर्बाद कर रहा हूं। –

+0

भी, लास टेक्स्ट फ़ाइल को देख रहा था, लेकिन मैं बाइनरी फाइलों के बारे में बात कर रहा हूं। –

4

हार्ड ड्राइव की कीमतों की त्वरित जांच 1 टेराबाइट (टीबी) आंतरिक ड्राइव लगभग $ 75 अमरीकी डालर रखती है। अपने गणित का उपयोग करना, यह आपकी 4 एमबी फ़ाइल की 250,000 प्रतियां, या प्रति प्रति $ 0.0003 प्रतियां है। एक घंटे के लिए एक प्रोग्रामर के लिए विशिष्ट ओवरहेड लगभग $ 100 है।

और क्या खर्च होता है: उस फ़ाइल के सभी संस्करणों को रखते हुए, या एक पुराने संस्करण को फिर से बनाने के लिए प्रोग्रामर का भुगतान करना यदि आपको कभी भी उस प्रतिलिपि की आवश्यकता है?

+1

मैं आपकी राय दोहराता हूं, लेकिन: मुख्य लागत हार्ड ड्राइव नहीं है लेकिन (टेप) बैकअप है। –

+1

यह भी आसान है: बाहरी हार्ड ड्राइव पर बैकअप लें। टेप परिवर्तक और सभी मीडिया की कीमत में कारक होने के बाद वे टेप से तेज़ और अधिक विश्वसनीय होते हैं। –

+0

ध्यान रखें कि * $ 75 अमरीकी डालर "उपभोक्ता" हार्डड्राइव के लिए है, यदि आप "SAN" हार्डड्राइव के बारे में बात कर रहे हैं, तो मैंने उन्हें प्रति टीबी लगभग $ 1k USD में वजन सुना है .... (यह जानकारी शायद पुराने/आदि हो लेकिन आपको विचार मिल गया) – Pharaun

2

आपकी विशिष्ट आवश्यकता के लिए, जहां भी आप चाहें पिछले संस्करणों को हटा सकते हैं, एक वीसीएस (Version Control System, पर बनाया गया कोई संस्करण खोना) उपयुक्त नहीं है।

रिपोजिटरी प्रबंधक (जो फाइल सिस्टम पर एक साधारण साझा पथ से अधिक उन्नत समाधान है) वह है जिसे आप ढूंढ रहे हैं।
(E.g Nexus Sonatype, केवल एक का उल्लेख करने के लिए)

3

यह वीसीएस के लिए नौकरी नहीं है, लेकिन फाइल सिस्टम के लिए, केन ने कहा।

हालांकि, अगर आपको वास्तव में ऐसी 'फीचर' की ज़रूरत है, तो आप इतिहास से फ़ाइल के पिछले संस्करण (कहें, 3 से अधिक पुराने) संस्करणों को हटाने के लिए हुक तंत्र का उपयोग कर सकते हैं।

0

यदि आप चाहते हैं कि कंप्यूटर पर फ़ाइलों को सिंक करना है, तो Dropbox का उपयोग करें।

यदि आप संस्करण नियंत्रण का उपयोग कर रहे हैं, तो देखें कि लास वी। कार्ल्सन ने क्या लिखा, डिस्क स्थान सस्ता है।

2

क्यों सभी स्रोत फ़ाइलों के लिए बाइनरी फ़ाइलों और एक डीवीसीएसएस के लिए एसवीएन का उपयोग नहीं करते? इस तरह, आप सभी संशोधन सर्वर-साइड रखते हैं लेकिन केवल एक कॉपी क्लाइंट पक्ष .. और अन्य स्रोतों के लिए, आपको वास्तविक वीसीएस होने का लाभ मिलता है।

मैं समझता हूँ कि हम एक बाइनरी फ़ाइल के सभी संशोधन कहीं रखने के लिए, लेकिन हर "पुल" हर डेवलपर्स के लिए मूल्य का भुगतान नहीं हर क्लोन वे .. यही कारण है कि अपमानजनक हो सकता है पर करना चाहते हैं ..

2

लाज़िमी कर सकते हैं तुम्हारे लिए करू।

Check file types:

+ एस केवल सिर संशोधन संग्रहीत किया जाता है पुराने संशोधनों को नए संशोधन प्रस्तुत करने पर डिपो से पर्ज कर रहे हैं। निष्पादन योग्य या .obj फ़ाइलों के लिए उपयोगी।

-या-

+ Sn केवल सबसे हाल n संशोधन जमा हो जाती है, जहां n 1 से 10, या 16, 32, 64, 128, 256, या 512 पुराने संशोधनों के लिए एक नंबर है एन नए संशोधन से अधिक जमा करने पर डिपो से शुद्ध किया गया है, या यदि आप मौजूदा + एसएन फ़ाइल की एन को अपने वर्तमान मूल्य से कम संख्या में बदलते हैं। विवरण के लिए, कमांड संदर्भ देखें।

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

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