क्यों स्रोत नियंत्रण प्रणाली अभी भी ज्यादातर फ़ाइलों के साथ समर्थित हैं?

Question

ऐसा लगता है कि अधिक स्रोत नियंत्रण प्रणाली अभी भी फ़ाइलों को संस्करण डेटा संग्रहीत करने के साधन के रूप में उपयोग करती है। वॉल्ट और टीएफएस एसक्यूएल सर्वर को अपने डेटा स्टोर के रूप में उपयोग करते हैं, जो मुझे लगता है कि डेटा स्थिरता के साथ-साथ गति के लिए बेहतर होगा।

तो ऐसा क्यों है कि एसवीएन, मेरा मानना ​​है कि जीआईटी, सीवीएस, आदि अभी भी फाइल सिस्टम का अनिवार्य रूप से डेटाबेस के रूप में उपयोग करते हैं, (मैं यह सवाल इसलिए पूछता हूं क्योंकि हमारे एसवीएन सर्वर के पास सामान्य डेटाबेस सॉफ़्टवेयर के बजाय केवल एक सामान्य प्रतिबद्धता के दौरान ही भ्रष्ट था) MSSQL, Oracle, Postgre, आदि)?

संपादित करें: मुझे लगता है कि मेरा सवाल पूछने का एक और तरीका यह है कि "वीसीएस डेवलपर्स एक एक्सिसिटिंग का उपयोग करने के बजाय अपने स्वयं के संरचित डेटा स्टोरेज सिस्टम को क्यों रोल करते हैं?"

Comments

आपको क्या लगता है कि अधिकांश डेटाबेस अपने मूल समर्थन के रूप में उपयोग करते हैं? अधिकांश फाइलें (हालांकि कुछ हार्ड डिस्क तक सीधी पहुंच का उपयोग करती हैं)। आपके पास "बस फाइलों" का उपयोग करके डेटाबेस की सभी विशेषताएं हो सकती हैं।

— जोकिम सॉउर

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

@JoachimSauer हां, मुझे एहसास है कि, लेकिन DBM सिस्टम के पास यह सुनिश्चित करने के तरीके हैं कि असंगत डेटाबेस में कुछ भी नहीं मिलता है। जब तक ये फ़ाइल आधारित रिपॉजिटरी ट्रांसेक्शनल एनटीएसएफ जैसी किसी चीज का उपयोग नहीं कर रहे हैं, तब तक भ्रष्ट होने का एक आधार है। और मैं एक वास्तविक डेटाबेस पर भरोसा करता हूं, जितना कि मैं डेवलपर्स का एक सेट अनिवार्य रूप से पहिया का फिर से आविष्कार कर रहा हूं, क्योंकि मुझे लगता है कि हम सहमत हो सकते हैं कि स्रोत नियंत्रण प्रणालियों को डेटा अखंडता की आवश्यकता होती है।

— एंडी

@ डायलेन लेन-देन का समर्थन और आंतरिक स्थिरता। हम अब टेप b / c से हमारे SVN रिपॉजिटरी को बहाल कर रहे हैं SVN सर्वर ने उन सभी फाइलों को ठीक से नहीं लिखा था जिन्हें यह माना जाता था। इसके अलावा भारी मात्रा में डेटा की खोज। मेरा कहना है, पहिया का फिर से आविष्कार करने का प्रयास क्यों करें।

— एंडी

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

— ग्लेनपेटर्सन

Answer 1

TL; DR: कुछ संस्करण नियंत्रण प्रणाली एक डेटाबेस का उपयोग करते हैं क्योंकि यह आवश्यक नहीं है।

एक सवाल के जवाब के लिए एक सवाल के रूप में, वे क्यों नहीं करेंगे? "वास्तविक" डेटाबेस सिस्टम इस संदर्भ में एक फ़ाइल सिस्टम पर क्या लाभ प्रदान करता है?

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

मान लें कि Git (तर्क के लिए) ने डेटा को संग्रहीत करने के लिए अपने बैक-एंड के लिए BDB या SQLite DB का उपयोग किया है। उस बारे में अधिक विश्वसनीय क्या होगा? जो कुछ भी सरल फ़ाइलों को भ्रष्ट कर सकता है वह डेटाबेस को भी भ्रष्ट कर सकता है (क्योंकि यह एक अधिक जटिल एन्कोडिंग वाली सरल फ़ाइल है)।

प्रोग्रामर के प्रतिमान से जब तक इसकी आवश्यकता न हो, तब तक अनुकूलन न करें, यदि संशोधन नियंत्रण प्रणाली पर्याप्त रूप से तेज है और मज़बूती से काम करती है, तो अधिक जटिल प्रणाली का उपयोग करने के लिए पूरे डिज़ाइन को क्यों बदलें?

Comments

TLDR? आप उत्तर दो बार लंबे थे और यह सवाल वास्तविक था जैसा कि यह छोटा था!

— ब्रैड

@ ब्रैड निम्नलिखित तीन शब्द TL;DRउत्तर के संक्षिप्त संस्करण हैं, यह कथन नहीं कि प्रश्न बहुत लंबा है और उसने उत्तर देने से पहले इसे नहीं पढ़ा।

@Andy Mercurial में "इतिहास में grep" भी है, और git के पास भी इसकी संभावना है। यह पहले से तेज़ बिजली भी है। विशेषज्ञों की बातों को छोड़ने के लिए: VCS को विकसित करने वाले लोग विशेषज्ञ होते हैं ।

बस इसमें जोड़ना चाहता हूं कि मुझे आपकी बात दिखाई देती है; यदि VCS खराब डेटा लिखता है, तो यह महत्वपूर्ण नहीं है कि उसका डेटा किसी फ़ाइल या डेटाबेस में लिखा जाए। हालांकि दूसरा पक्ष यह है कि फ़ाइल आधारित रिपॉज शायद एक समय में एक से अधिक फ़ाइल को लिख रहे हैं और आम तौर पर इसके लिए कोई लेन-देन का समर्थन नहीं है, इसलिए यदि कोई फ़ाइल लिखता है, लेकिन दूसरी विफल हो जाती है, तो आपका वीसीएस अब भ्रष्ट है, बनाम डेटाबेस तालिका एक डेटाबेस के भीतर लिखता है लेनदेन एक इकाई के रूप में असफल होने के लिए प्रतिबद्ध होगा। मुझे लगता है जैसे डेटाबेस निर्माण सॉफ्टवेयर के देवों के एक समूह के पास एसवीएन लिखने वाले लोगों की तुलना में अधिक अनुभव है ... लेकिन शायद मैं गलत हूं।

— एंडी

Git की आपकी पसंद "तर्क के लिए" एक महत्वपूर्ण बिंदु है: git के पास अपनी वस्तुओं को लिखने के लिए एक बहुत अच्छा मॉडल है, लेकिन कई उपकरण नहीं हैं। गिट के साथ, यदि कंप्यूटर कमिट के बीच में संचालित होता है, तो आपने कुछ ऑब्जेक्ट्स को फाइलसिस्टम में लिखा होगा और वे केवल अप्राप्य होंगे। अन्य VCSs के साथ, आपने परिवर्तनों को आधी फ़ाइलों में जोड़ा है (और भ्रम पैदा कर सकता है।) आप यह तर्क दे सकते हैं कि अन्य संस्करण नियंत्रण उपकरण खराब तरीके से डिजाइन किए गए हैं (और आप सही होंगे), लेकिन जब आप VCS लिख रहे हैं, तो यह बहुत आसान है बस एक SQL लेनदेन का उपयोग करें और इसे सही काम करने दें।

— एडवर्ड थॉमसन

Answer 2

आप बहुत सारी धारणाएं बनाते दिख रहे हैं, संभवतः एसवीएन और सीवीएस के साथ आपके अनुभव के आधार पर।

Git और Mercurial मूल रूप से SVN और CVS जैसे हैं

Git और CVS की तुलना करना iPad और Atari की तुलना करने जैसा है। सीवीएस वापस बनाया गया था जब डिनोउर पृथ्वी पर घूमते थे । तोड़फोड़ मूल रूप से सीवीएस का एक उन्नत संस्करण है। यह मानते हुए कि आधुनिक संस्करण नियंत्रण प्रणाली जैसे कि git और Mercurial उनके जैसे काम बहुत कम समझ में आता है।

एकल-उद्देश्य डेटाबेस की तुलना में एक रिलेशनल डेटाबेस अधिक कुशल है

क्यूं कर? संबंधपरक डेटाबेस वास्तव में जटिल हैं, और एकल-उद्देश्य डेटाबेस के रूप में कुशल नहीं हो सकते हैं। मेरे सिर के ऊपर से कुछ अंतर:

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

रिलेशनल डेटाबेस सुरक्षित हैं

फिर, क्यों? आपको लगता है कि क्योंकि डेटा फ़ाइलों में संग्रहित है, संस्करण नियंत्रण प्रणाली जैसे git और Mercurial में परमाणु आवागमन नहीं है , लेकिन वे ऐसा करते हैं। रिलेशनल डेटाबेस भी फाइल के रूप में अपने डेटाबेस को स्टोर करते हैं। यहाँ यह उल्लेखनीय है कि CVS परमाणु आवागमन नहीं करता है, लेकिन इसकी संभावना है क्योंकि यह अंधेरे युग से है, इसलिए नहीं कि वे संबंधपरक डेटाबेस का उपयोग नहीं करते हैं।

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

मैं तर्क दूंगा कि वितरित नियंत्रण प्रणाली (जैसे git और Mercurial) आपके डेटाबेस को केंद्रीकृत संस्करण नियंत्रण से बचाने के लिए बेहतर हैं, क्योंकि आप किसी भी क्लोन से पूरे रेपो को पुनर्स्थापित कर सकते हैं। इसलिए, यदि आपका केंद्रीय सर्वर अनायास combusts, अपने बैकअप के सभी के साथ, आप इसे चलाकर बहाल कर सकते हैं git init, तो नए सर्वर पर git pushसे किसी भी डेवलपर के मशीन ।

पहिए को फिर से खराब करना बुरा है

सिर्फ इसलिए कि आप किसी भी भंडारण समस्या के लिए एक रिलेशनल डेटाबेस का उपयोग कर सकते हैं इसका मतलब यह नहीं है कि आपको चाहिए । आप रिलेशनल डेटाबेस के बजाय कॉन्फ़िगरेशन फ़ाइलों का उपयोग क्यों करते हैं? जब आप किसी रिलेशनल डेटाबेस में डेटा स्टोर कर सकते हैं तो फाइल सिस्टम पर छवियों को क्यों स्टोर करें? जब आप एक रिलेशनल डेटाबेस में यह सब स्टोर कर सकते हैं तो अपना कोड फाइलसिस्टम पर क्यों रखें?

"यदि आपके पास एक हथौड़ा है, तो सब कुछ एक नाखून जैसा दिखता है।"

तथ्य यह भी है कि जब भी यह सुविधाजनक होता है, तो ओपन-सोर्स प्रोजेक्ट्स व्हील को फिर से मजबूत करने का जोखिम उठा सकते हैं , क्योंकि आपके पास उसी प्रकार के संसाधन की कमी नहीं है जो वाणिज्यिक प्रोजेक्ट करते हैं। यदि आपके पास एक स्वयंसेवक है जो डेटाबेस लिखने में एक विशेषज्ञ है, तो उनका उपयोग क्यों न करें?

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

कुछ वाणिज्यिक संस्करण नियंत्रण प्रणाली एक संबंधपरक डेटाबेस का उपयोग क्यों करते हैं?

निम्नलिखित में से कुछ के संयोजन की संभावना:

• कुछ डेवलपर्स डेटाबेस लिखना नहीं चाहते हैं ।
• वाणिज्यिक संस्करण नियंत्रण प्रणालियों के डेवलपर्स में समय और संसाधन की कमी होती है, इसलिए जब वे पहले से ही कुछ चाहते हैं, तो वे एक डेटाबेस लिखने का जोखिम नहीं उठा सकते हैं। इसके अलावा, डेवलपर्स महंगे हैं, और डेटाबेस डेवलपर्स (जैसा कि, जो लोग डेटाबेस लिखते हैं) शायद अधिक महंगे हैं, क्योंकि ज्यादातर लोगों के पास उस तरह का अनुभव नहीं है।
• व्यावसायिक संस्करण नियंत्रण प्रणालियों के उपयोगकर्ताओं को संबंध स्थापित करने और चलाने के ओवरहेड के बारे में परवाह करने की संभावना कम होती है, क्योंकि उनके पास पहले से ही एक है।
• वाणिज्यिक संस्करण नियंत्रण प्रणाली के उपयोगकर्ता अपने पुनरीक्षण डेटा का समर्थन करने के लिए एक रिलेशनल डेटाबेस चाहते हैं , क्योंकि यह उनकी प्रक्रियाओं को बेहतर तरीके से एकीकृत कर सकता है (उदाहरण के लिए बैकअप)।

Comments

एक बात: SVN प्रतिबद्ध हैं परमाणु। वास्तव में, यह एक प्रमुख विक्रय बिंदु है (या कम से कम, वापस जब उन्हें सीएसवी उपयोगकर्ताओं को स्विच करने के लिए राजी करना था)।

@delnan - वहाँ के बीच एक बड़ा अंतर है ध्यान दें कि सैद्धांतिक atomicity आप के साथ मिलता है svn, जहां अपने काम करने निर्देशिका में अलग निर्देशिका अलग हो सकता है svnसंशोधन और सच भंडार विस्तृत atomicity आप के साथ मिलता है gitया hg।

— मार्क बूथ

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

— मोनिका

इसी तरह, एक मूल पत्रिका को लागू करना भी जटिल नहीं है। (१) नई कमेटी को फाइल में लिखें। (2) पुरानी इंडेक्स फाइल को कॉपी करें। (3) एक नई सूचकांक फ़ाइल लिखें। (4) पुरानी इंडेक्स फाइल की कॉपी को डिलीट करें। यदि आप चरण 1, 2 या 4 में विफल रहते हैं, तो आपको बस आपके द्वारा बनाई गई नई फ़ाइलों को साफ करने की आवश्यकता है। यदि आप चरण 3 में विफल हो जाते हैं, तो आपको बस पुरानी इंडेक्स फ़ाइल को वापस कॉपी करने की आवश्यकता है। कोई व्यक्ति जो फाइलसिस्टम को बेहतर समझता है, वह शायद इसका अधिक कुशल संस्करण बना सकता है, लेकिन यदि आप की जरूरत है तो आप हमेशा SQLite के सोर्स कोड का संदर्भ ले सकते हैं।

— मोनिका

@ ब्रेडनलॉन्ग ग्रेट पॉइंट्स। चर्चा की सराहना करें। बस स्पष्ट होने के लिए, मुझे लगता है कि दोनों प्रकार के बैकिंग स्टोर के फायदे और नुकसान हैं, मुझे विश्वास नहीं है कि सिर्फ एक सही उत्तर है। हालाँकि, मैं थोड़े आश्चर्यचकित था कि लगता है कि केवल तीन (चार अगर आप वॉल्ट और वर्सिटी को अलग-अलग गिनते हैं) जो कि SQL का उपयोग करते हैं और विशाल बहुमत नहीं थे, यह सब है।

— एंडी

Answer 3

असल में svnरिपॉजिटरी के लिए BDB का इस्तेमाल किया जाता था। यह अंततः छुटकारा पा लिया गया क्योंकि यह टूटने का खतरा था।

एक और VCS जो वर्तमान में DB (SQLite) का उपयोग करता है fossil। यह बग ट्रैकर को भी एकीकृत करता है।

वास्तविक कारण पर मेरा अनुमान है कि VCSes बहुत सारी फाइलों के साथ काम करता है। फाइलसिस्टम केवल एक अन्य प्रकार का डेटाबेस है (पदानुक्रमित, CLOB / BLOB भंडारण दक्षता पर केंद्रित)। सामान्य डेटाबेस उस अच्छी तरह से संभाल नहीं है क्योंकि वहाँ कोई कारण नहीं है - filesystems पहले से मौजूद हैं।

Comments

BDB बिल्कुल विश्वसनीय के रूप में नहीं गिना जाएगा - जैसे SQLite यह एक प्रक्रिया डेटाबेस है। मैंने कहा, मुझे लगता है कि Oracle / MSSQL / MySQL / Postgres की विश्वसनीयता, आप उन्हें कैसे कॉन्फ़िगर करते हैं, इस पर निर्भर करता है कि फाइलसिस्टम से बहुत अलग नहीं है। मुख्य समस्या यह है कि RDBMS उन पदानुक्रमित और ग्राफ़ संरचनाओं के लिए नहीं बनाया गया है जो VCSes आमतौर पर काम करते हैं। और उस स्थिति में, फाइलसिस्टम ही जीतते हैं।

— माइक लार्सन

@ ऑंडी: जीवाश्म SQLite के निर्माता द्वारा बनाया गया था। यह वास्तव में आश्चर्य की बात नहीं है :-)

— Jörg W Mittag

@Andy: मैं SQLite पर भरोसा करता हूँ बहुत ओरेकल या MSSQL से अधिक है। यह कोई आश्चर्य नहीं है कि यह एक बड़े मार्जिन से वहाँ सबसे अधिक उपयोग किया जाने वाला SQL डेटाबेस है। इसके अलावा, यह सबसे अलग आर्किटेक्चर के लिए एक पोर्ट है, हर एक के पास चुनौतियों का एक सेट है, जो साझा कोड को अविश्वसनीय रूप से बुलेट-प्रूफ बनाता है।

— जेवियर

@ जेवियर मुझे एसक्यूएलइट पर उतना भरोसा नहीं होगा, जितना कि एमएसक्यूएल या ओरेकल में; जैसा कि माइक ने कहा कि इन-प्रोसेस पार्ट मुझे डराता है, जैसे कि आपका ऐप मर जाता है जो अब आपके डीबी को दूषित कर सकता है। एक क्लाइंट / सर्वर डेटाबेस के साथ, क्लाइंट मरने से लेनदेन को रोक देता है। सीएस डीबी को भ्रष्ट होने के लिए असंभव नहीं कहना चाहिए, लेकिन मुझे लगता है कि आवेदन के साथ डीबी इंजन के संयुक्त होने की तुलना में इसकी संभावना कम है।

— एंडी

@ और, यही लेनदेन के लिए है। कोई फर्क नहीं पड़ता कि आप एक अच्छे DB इंजन को किस बिंदु पर मारते हैं, एक दिया गया लेनदेन या तो प्रतिबद्ध है या नहीं। SQLite का परमाणु आवागमन का कार्यान्वयन ( sqlite.org/atomiccommit.html ) विशेष रूप से परिष्कृत है।

— जेवियर

Answer 4

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

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

3. क्रॉस-प्लेटफ़ॉर्म आवश्यकताएँ डेटाबेस को अधिक चुनौतीपूर्ण उपयोग करती हैं।

   अधिकांश संस्करण नियंत्रण उपकरण कई प्लेटफार्मों पर चलाने के लिए बनाए गए हैं। केंद्रीकृत संस्करण नियंत्रण उपकरणों के लिए, यह केवल सर्वर घटक को प्रभावित करता है, लेकिन अभी भी एकल डेटाबेस सर्वर पर भरोसा करना मुश्किल है क्योंकि यूनिक्स उपयोगकर्ता Microsoft SQL सर्वर स्थापित नहीं कर सकते हैं और विंडोज उपयोगकर्ता PostgreSQL या MySQL को स्थापित करने के लिए तैयार नहीं हो सकते हैं। फाइलसिस्टम कम से कम सामान्य भाजक है। हालांकि, कई उपकरण हैं जहां सर्वर को विंडोज मशीन पर इंस्टॉल किया जाना चाहिए, और इस प्रकार SQL सर्वर की आवश्यकता होती है, उदाहरण के लिए SourceGear वॉल्ट और Microsoft टीम फाउंडेशन सर्वर ।

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

   1. उन प्लेटफार्मों के सबसेट तक सीमित है जहां एक विशेष डेटाबेस मौजूद है
   2. एक एकल डेटाबेस बैकएंड को टारगेट करता है जो क्रॉस-प्लेटफ़ॉर्म (उदाहरण के लिए, SQLite) है।
   3. एक प्लग करने योग्य भंडारण बैकएंड को टारगेट करता है, ताकि कोई भी डेटाबेस का उपयोग कर सके जो वे चाहते थे (संभवतः फाइलसिस्टम सहित)।

   अधिकांश वितरित संस्करण नियंत्रण प्रणाली, इसलिए, केवल फ़ाइल सिस्टम का उपयोग करें। एक उल्लेखनीय अपवाद SourceGear की है सच्चाई है, जो एक SQLite डेटाबेस में स्टोर कर सकते हैं (स्थानीय खजाने के लिए उपयोगी) या SQL सर्वर की तरह एक संबंधपरक डेटाबेस (एक सर्वर के लिए संभवतः उपयोगी।) उनकी बादल की पेशकश की मेजबानी कर सकते हैं अमेज़न SimpleDB की तरह एक गैर संबंधपरक भंडारण बैकेंड का उपयोग , लेकिन मैं यह नहीं जानता कि यह सच है।

Comments

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

— mikebabcock

Answer 5

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

कई कंपनियां हैं जो एक svn / git / etc इंटरफ़ेस के साथ RDBMS बैक एंड की पेशकश करती हैं, इसलिए जो आप पूछ रहे हैं वह मूल रूप से पहले से मौजूद है।

Answer 6

मैं यह कहूंगा कि संस्करण नियंत्रण प्रणाली की प्राथमिक डेटा संरचना एक डीएजी है, जो बहुत खराब डेटाबेस में मैप करती है। बहुत सारा डेटा कंटेंट एड्रेस करने योग्य भी होता है, जो बहुत खराब तरीके से डेटाबेस में मैप भी करता है।

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

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

इसके अलावा, यह डीवीसीएस का एक कारण है, लेकिन डेटाबेस का उपयोग न करना इसे बेहद पोर्टेबल बनाता है। मैं अपने स्रोत के पेड़ को एक अंगूठे ड्राइव पर कॉपी कर सकता हूं और डेटाबेस सर्वर प्रक्रिया को कॉन्फ़िगर किए बिना किसी भी मशीन पर इसका पुन: उपयोग कर सकता हूं।

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

Comments

"डेटाबेस में बहुत खराब नक्शे" फिर भी वॉल्ट और टीएफएस ऐसा करते हैं। "डेटा अखंडता केवल वीसीएस की चिंता नहीं है, वे संस्करण इतिहास अखंडता से भी चिंतित हैं, जो डेटाबेस बहुत अच्छे नहीं हैं।" मैं यह देखने में विफल रहता हूं कि कैसे स्टोरिंग संस्करण इतिहास डेटाबेस में फाइलों में खुद को उधार देता है खासकर जब से मैंने उन उत्पादों का नाम लिया है जो बस करते हैं। "दोनों में भ्रष्टाचार बहुत कम हैं, लेकिन वे होते हैं।" पहले पृष्ठ में उन परिणामों में से कोई भी वॉल्ट सर्वर डेटाबेस के भ्रष्ट होने की बात नहीं करता है। एक लिंक जो वॉल्ट सॉफ़्टवेयर के बारे में बात करता है वह समस्या है डब्ल्यूसी भ्रष्ट हो गया है।

— एंडी

"सभी इरादों और उद्देश्यों के लिए, वीसीएस डेटा स्टोर एक डेटाबेस है।" खैर ... यह मेरी बात है। सिर्फ अपना रोल करने के बजाय डेटा को असली डेटाबेस सिस्टम में क्यों न चिपकाएँ?

— एंडी

@ और हां, यह एक डेटाबेस है, लेकिन सभी डेटाबेस एक दूसरे के लिए प्रतिस्थापन योग्य नहीं हैं। प्रत्येक डेटाबेस का दुनिया पर एक निश्चित दृष्टिकोण है (उदाहरण के लिए, SQL DBs मूल रूप से रिलेशनल मॉडल को लागू करते हैं)। इस उत्तर के विवरण के रूप में, डेटा वीसीएस स्टोर करता है और जिस तरह से डेटा का उपयोग किया जाता है वह रिलेशनल मॉडल में फिट नहीं होता है। मुझे यकीन नहीं है कि अगर कुछ NoSQL db बेहतर करता है, लेकिन वे नए हैं और अभी तक अपनी श्रेष्ठता साबित करने के लिए हैं (मुझे कुछ के लिए गंभीर अखंडता मुद्दों की रिपोर्ट याद है)। और उसके बाद अन्य सभी मुद्दे हैं।

DAG का उपयोग केवल DVCS में किया जाता है (जब तक कि आप रेखीय इतिहास को एक असाधारण साधारण DAG नहीं मानते हैं, जो कि यह है, लेकिन यह वास्तव में एक सहायक अमूर्त नहीं है।) जब आपका इतिहास रैखिक है, तो मोनोटोनिक रूप से बढ़ते हुए परिवर्तनों के साथ, SQL डेटाबेस बहुत अधिक अर्थ देता है। ।

— एडवर्ड थॉमसन

नीरस रूप से बढ़ते संस्करण संख्या VCSes के लिए बहुत मायने नहीं रखते हैं। मैं उनमें से एक उचित संख्या का उपयोग किया है, और केंद्रीकृत संस्करण संख्या (CVS और SVN 2 मैं सबसे परिचित हूँ) के साथ विलय करने के लिए एक दर्द हो जाते हैं। और यहां तक ​​कि वे डीएजी का उपयोग करते हैं जब वे विलय करने का प्रयास करते हैं। सिर्फ इसलिए कि उनका भंडारण प्रतिनिधित्व इसके आधार पर नहीं है इसका मतलब यह नहीं है कि इसका उपयोग नहीं किया गया है।

— माइक लार्सन

Answer 7

• बेहतर आपदा वसूली (सबसे खराब स्थिति: हम इसे पुराने समय की तरह आँख से देख लेंगे)

• ऐसी आपदाओं पर नज़र रखना और डिबग करना, संभवतः VCS प्रणाली के दोषों के कारण आसान है।

• निर्भरता की संख्या कम करना। (चलो उन प्रणालियों में से एक को कर्नेल को नहीं भूल रहे हैं , और दूसरे को माना जाता था)

• एक पाठ-संपादक हमेशा उपलब्ध होता है। (एमएस SQL ​​सर्वर लाइसेंस ... इतना नहीं)

Comments

यह उत्तर सिर्फ बुरा है। केवल वास्तव में सही बिंदु निर्भरता की संख्या को कम कर रहा है। दोनों बैकिंग सिस्टम बराबर होने चाहिए क्योंकि आपको उचित बैकअप देना चाहिए, डीबी अनुप्रयोगों को डीबग करना फ़ाइलों को लिखने वाले डिबगिंग अनुप्रयोगों की तुलना में अधिक कठिन नहीं है, और पाठ संपादक हमेशा उपलब्ध है? मुझे यह भी पता नहीं है कि आपकी बात क्या है, क्योंकि VCS स्वयं एक टेक्स्ट एडिटर का उपयोग करने वाला नहीं है, और वहाँ से बाहर अन्य DB सर्वर हैं (Sqlite, Postgre, MySql, आदि) ताकि यदि आप एक चाहते थे db सर्वर की db समर्थित समाधान कमी एक कारक नहीं होनी चाहिए।

— एंडी

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

— ZJR

@Andy पाठ फ़ाइलों sqliteका एकमात्र संभव विकल्प है, जो वितरित परिदृश्यों की विशाल मात्रा को देखते हुए आधुनिक DVCS सेवा प्रदान करता है। (आईडीके, शायद आपने डीवीसीएस के "वितरित" भाग को याद किया होगा) कुछ भी बहुत अधिक बोझिल होगा (कॉन्फ़िगरेशन + फ़ायरवॉलिंग + लाइसेंस) या यहां तक ​​कि मूर्खतापूर्ण वितरित करने के लिए । तब फिर से एक साइक्लेइट के लिए सबसे खराब स्थिति में पोस्टमॉर्टम करना कठिन साबित हो सकता है।

— ZJR

@ जेडजेआर: मुझे नहीं लगता कि मूल प्रश्न कभी वितरित वितरित नियंत्रण निर्दिष्ट करता है, यह सामान्य रूप से संस्करण नियंत्रण प्रणालियों के बारे में पूछता है। इसके अलावा, आपका पाठ संपादक तर्क थोड़ा सपाट है, क्योंकि बहुत सारे सिस्टम सिर्फ फ्लैट पाठ फ़ाइलों को संग्रहीत नहीं करते हैं। यहां तक ​​कि गिट में बहुत सारे बाइनरी फाइल फॉर्मेट (ढीली वस्तुएं, पैक फाइलें आदि) हैं जो आपके टेक्स्ट एडिटर को बेकार कर देते हैं।

— एडवर्ड थॉमसन

@ZJR एक पाठ संपादक में एक वीसीएस के समर्थन स्टोर में कोड को कैसे संपादित किया जाता है? क्या आप मैन्युअल रूप से संपादन का सुझाव दे रहे हैं, SVN का डेटाबेस? इसके अलावा मेरा सवाल डीवीसीएस तक ही सीमित नहीं है, इसलिए मुझे नहीं पता कि आप इस पर नुकसान क्यों कर रहे हैं।

— एंडी

Answer 8

जीवाश्म एक उत्कृष्ट वितरित संस्करण नियंत्रण प्रणाली (DVCS) है और भंडारण के लिए SQLite का उपयोग करता है, कोई सादा-पाठ फ़ाइलें नहीं।

मुझे वास्तव में यह पसंद है कि यह एकीकृत है: बग ट्रैकिंग, विकी और यह वास्तव में वितरित किया गया है। मेरा मतलब है कि आप वास्तव में ऑफ़लाइन काम कर सकते हैं और बग को ठीक कर सकते हैं।

Fossil Sqlite का उपयोग करता है क्योंकि यह अनुप्रयोग फ़ाइल स्वरूप है। PgCon में मुख्य वक्ता के रूप में डॉ। रिचर्ड हिप्प बताते हैं कि एक एप्लिकेशन फाइल सिस्टम के रूप में sqlite का उपयोग करने के क्या फायदे हैं, और फाइलसिस्टम के रूप में डेटाबेस का उपयोग करने के लाभों का एक बहुत ही ठोस तर्क देता है।

दूसरा मुख्य विषय यह था कि SQLite को एक एप्लीकेशन फाइल फॉर्मेट के रूप में देखा जाना चाहिए - खुद के फाइल फॉर्मेट का आविष्कार करने या ZIPped XML का उपयोग करने का विकल्प। बयान "SQLite PostgreSQL के लिए एक प्रतिस्थापन नहीं है। SQLite फोपेन () "नाखून" (स्लाइड 21) के लिए एक प्रतिस्थापन है। अंत में, रिचर्ड ने इस तथ्य पर बहुत जोर दिया कि SQLite आपके डेटा (क्रैश सुरक्षित, ACID) का उपयोग करता है-

अब डॉ। हिप्प ने एक डेटाबेस पर कोड बचाने पर चिंताओं को संबोधित किया है

• फ़ॉसिल एक वितरित NoSQL डेटाबेस के बजाय SQLite पर आधारित क्यों है?

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