2009-06-16 5 views
27

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

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

Git क्योंकि कारणों की तस्वीर के लिए आता है।

लेकिन वेब में कुछ प्रारंभिक शोध के बाद, मुझे कुछ निराशाजनक तथ्यों का पता चला जो हमारे आवेदन पर लागू होते हैं - हमारे जैसे बड़े सिस्टम के लिए गिट का उपयोग करना दर्दनाक (चेकआउट, क्लोन, मर्ज, पुश, पुल) और कमांड जटिल हैं ("geeky" अधिक उपयुक्त होगा) एक डेवलपर बेस के लिए जो DVCS अज्ञानी और अधिकतर विंडोज उपयोगकर्ता है।

गिट के लिए कोई निश्चित मानसिकता नहीं है, लेकिन अगर मुझे केंद्रीकृत दृष्टिकोण (वास्तव में सर्वश्रेष्ठ मामले में) के लिए जाना है तो सीवीएस & एसवीएन अलग होना चाहिए)। मैंने पर्सफोर्स को एक स्थिर होने के बारे में पढ़ा है और Google में भी इसका उपयोग किया जाता है (मुझे यहां कुछ ब्रश की उम्मीद है !!)।

कृपया अपने विचार साझा करें, गाइड करें और टिप्पणी करें। मुझे वास्तव में उनकी आवश्यकता है।

+7

गिट ऐसे बड़े भंडारों के लिए डिज़ाइन नहीं किया गया था (हालांकि बड़ी फ़ाइलों और बड़े भंडारों के लिए यह बेहतर व्यवहार करने पर काम चल रहा है) ... लेकिन मुझे लगता है कि आपको किसी भी संस्करण नियंत्रण प्रणाली के प्रदर्शन में समस्या होगी जो नहीं ऑपरेशन प्रति-फ़ाइल तरीका (जिसका स्वयं का गंभीर नुकसान होता है), या आंशिक चेकआउट का समर्थन नहीं करता है। क्या आपको वास्तव में कोड के साथ उन बड़ी फ़ाइलों को वर्जन नियंत्रित करने की आवश्यकता है? –

+0

मैंने बस एक डीएनसीएस के बारे में पढ़ा [मोनोटोन] (http://www.monotone.ca)। आपके लिए एक विकल्प हो सकता है। –

+0

मैं वर्तमान में एक विशाल भंडार से निपट रहा हूं। मैं यह देखने के लिए सबमिड्यूल का शोध कर रहा हूं कि क्या चीजों में सुधार होता है या नहीं। –

उत्तर

24

मैं बस एक मिनट पहले this blog post पढ़ रहा था। यह गिट की स्केलेबिलिटी के बारे में थोड़ा सा है।

संपादित करें: आठ साल बाद, और गिट में Large File Storage (एलएफएस) है, और माइक्रोसॉफ्ट Git Virtual File System (जीवीएफएस) खोल रहा है ताकि वे विंडोज विकसित करने के लिए गिट का उपयोग कर सकें।

+0

अच्छी पोस्ट :) हम्म उन मुद्दों को सुलझाने योग्य हैं या शायद यह गिट का डिज़ाइन है जो गलती में है? –

+0

हल करने योग्य? मुझे नहीं पता। लिनक्स लिनक्स स्रोत कोड पेड़ को संभालने के लिए गिट डिज़ाइन किया गया है, यह एक नौकरी बहुत अच्छी तरह से करता है। लेकिन यह बहुत सारी टेक्स्ट फाइलें है। मेरे कंप्यूटर पर 2 जीबी से कम भंडार, चेकआउट और निर्मित ऑब्जेक्ट्स। – pgs

+4

लिंक यहां स्थानांतरित हो गया है: http://stevehanov.ca/blog/index.php?id=50 – krubo

-2

मैंने स्कूल प्रोजेक्ट (ज़ेंड फ्रेमवर्क के साथ PHP साइट) के लिए केवल एक बार गिट का उपयोग किया।

हमने गिट का उपयोग किया लेकिन शिक्षक को एक एसवीएन रेपो पर अंतिम रिलीज की आवश्यकता थी।

चेकआउट आकार तुलना:

Git चेकआउट SVN चेकआउट के एमबी के आधे आकार था।

मेरे दो सेंट।

+1

बेशक, और यह हमेशा होगा क्योंकि एसवीएन आपकी कार्यशील प्रतिलिपि (.svn फ़ोल्डर में) के अंदर एक बेस कॉपी रखता है। इसका मतलब है कि diffs, reverts, आदि को नेटवर्क की आवश्यकता नहीं है। एसवीएन कम बैंडविड्थ कॉमर्स (सोच डायलअप) को संभालने के लिए बनाया गया था। – si618

+5

गिट अलग-अलग रहता है - यह संस्करण नियंत्रण प्रणाली वितरित किया जाता है ताकि आपको काम करने में सक्षम होने के लिए नेटवर्क की आवश्यकता न हो – stefanB

+3

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

16

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

हालांकि, मुझे लगता है कि आप चीजों को गलत तरीके से देख रहे हैं। असल में, आपके पास ऐसी सामग्री है जो अक्सर बदल जाएगी और जो ब्लॉग्स द्वारा बहुत आसानी से संपादन योग्य होने की आवश्यकता है, और कोड जो कोडर द्वारा कम बार संशोधित किया जाएगा। पारंपरिक समाधान वास्तविक सीएमएस (उदाहरण के लिए Alfresco, SugarCRM, Drupal इत्यादि या वैकल्पिक प्लग-इन के साथ विकी (MediaWiki, MoinMon इत्यादि) का उपयोग करना है। ध्यान रखें, विकिस (और अधिकांश सीएमएस) संस्करण की अनुमति देते हैं सामग्री, "उपयोगकर्ता के अनुकूल" तरीके से।

भले ही आपको अपना इन-हाउस कोड रखना चाहिए, मुझे लगता है कि आपको अभी भी सामग्री को निकालना चाहिए ताकि उनका अलग से इलाज किया जा सके। एक बार आपके पास कोड और सामग्री हो अलग, आपका भंडार एक और उचित आकार होगा। फिर, आप जो भी वीसीएस चाहते हैं उसका उपयोग कर सकते हैं (हालांकि मुझे सच में यकीन नहीं है कि आप सही हैं कि गिट बड़े रिपो के लिए स्वाभाविक रूप से खराब है)।

+4

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

+0

इवान, मुझे अभी तक इसका उपयोग करने का अवसर नहीं मिला है। हालांकि, यह लोकप्रिय TortoiseSVN पर आधारित है, और यह सक्रिय रूप से बनाए रखा है। इस प्रकार, मुझे निश्चित रूप से लगता है कि यह प्रयोग योग्य है। –

+3

मैंने अपने कार्यस्थल पर बहुत संक्षेप में टोर्टोइज गिट के साथ प्रयोग किया क्योंकि हम वैकल्पिक स्रोत नियंत्रण प्रणाली का मूल्यांकन कर रहे थे। मेरे गैर-तकनीकी परीक्षण उपयोगकर्ता पूरी तरह से उलझन में थे और उलझन में थे, और कुछ घंटों के भीतर सक्रिय रूप से शत्रुतापूर्ण थे। – Crashworks

8

क्या एसवीएन वास्तव में इतना बुरा विकल्प है?

पेशेवरों:

  • बड़े खजाने को संभाल कर सकते हैं जैसे कि कई linux distro के लिए इसका इस्तेमाल भी अपाचे, Sourceforge
  • अच्छा जीयूआई सामने TortoiseSVN के साथ समाप्त अपने विंडोज़ उपयोगकर्ताओं को खुश रखने के लिए
  • के साथ खिड़कियां एकीकृत प्रमाणीकरण इस्तेमाल किया जा सकता व्यवस्थापक खुश रखने के लिए
  • कई अलग अलग बैकअप रणनीति को अपनाया जा सकता है आपकी आवश्यकताओं के आधार पर (svnadmin हॉटकॉपी या डंप, svnsync, पोस्ट-प्रतिबद्ध हुक) विफलता चिंता के अपने एकल बिंदु को कम करने में मदद के लिए।

कान्स:

  • केन्द्रीकृत VCS

अस्वीकरण: मैं लाज़िमी उपयोग नहीं किया है और एक सुखी SVN व्यवस्थापक और ~ 6 साल (v0.29 के बाद से)

के लिए उपयोगकर्ता किया गया है
+0

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

+0

मैं शॉन से सहमत हूं, लेकिन यदि वह वीसीएस समाधान चाहता है तो किसी भी प्रकार की फ़ाइल के बजाय स्रोत कोड के लिए डिज़ाइन की गई प्रणाली का चयन क्यों करें? – si618

+0

+1 अतिरिक्त con: विलय के साथ इतना अच्छा नहीं है। एसवीएन अभी भी वास्तव में एक अच्छा उपकरण है, हालांकि, ऐसा कुछ नहीं है जिसे मनमाने ढंग से बाहर निकाला जाना चाहिए "इसके लायक नहीं।" – jpmc26

10

गिट बड़े भंडारों के लिए स्केल नहीं करता है। यह जगह नहीं है, यह फाइलों की संख्या है। कृपया मेरे blog article को पढ़ें जिसे मैंने कुछ समय पहले लिखा था।

मेरे अनुभव में, यदि आप एक स्केलेबल, तेज़, केंद्रीकृत स्रोत नियंत्रण प्रणाली चाहते हैं, तो P4 जाने का तरीका है।

+0

इस विशिष्ट मुद्दे पर बल इतना अच्छा है। पिक्सार प्रत्येक फिल्म के हर फ्रेम को पर्सफोर्स में करता है। यह बहुत कम डेटा है। यह लिंक पर्सफोर्स प्रचार का एक सा है लेकिन आप बताई गई संख्याओं के साथ बहस नहीं कर सकते हैं। यह बहुत अच्छी तरह से तराजू। https://www.perforce.com/blog/140924/pixars-templar-big-data-asset-management-built-scale –

4

git-split नामक उपयोगिता स्क्रिप्ट है जो इसे अधिक कुशल बनाने के लिए एक गिट रेपो को चॉप करती है।

2

माइक्रोसॉफ्ट ने अभी गिट वर्चुअल फाइल सिस्टम (जीवीएफएस) जारी किया है विशेष रूप से गिट के साथ बड़े कोड बेस को संभालने के लिए। More details here at msdn

इसके अलावा Microsoft hosts the Windows source in a monstrous 300GB Git repository

मैं GVFS का उपयोग कर किसी भी अनुभव नहीं है।

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