2009-04-14 14 views
10

मुझे 300,000 से अधिक फ़ाइलों में svn: 30Gb में एक एकल प्रोजेक्ट मिला है। वहां एक छवि फ़ोल्डर में ज्यादातर बाइनरी फाइलें हैं। पूरे प्रोजेक्ट को अपडेट करने जैसे ऑपरेशंस नाटकीय रूप से धीमे हो सकते हैं।एक बड़े एसवीएन प्रोजेक्ट के लिए सर्वोत्तम अभ्यास

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

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

क्या किसी ने इतनी बड़ी भंडार ट्यून करने की कोशिश की है और सलाह दे सकते हैं? क्या कोई भी सर्वोत्तम प्रथा है जो मैं बड़े भंडारों के साथ काम करने के लिए कार्यान्वित कर सकता हूं जिसे मैं हर किसी को आसानी से कर सकता हूं?

पीएस बाहरी एक अच्छा विचार प्रतीत नहीं होता है और SVN optimizations to keep large repositories responsive यहां लागू नहीं होता है क्योंकि मैं एक परियोजना से निपट रहा हूं

पी.पी.एस. यह वर्तमान में भी देखा जा रहा है: http://www.ibm.com/developerworks/java/library/j-svnbins.html

+0

इस मुद्दे पर कोई खबर है? मुझे हमारी परियोजना पर एक समान समस्या का सामना करना पड़ रहा है। –

उत्तर

8

सबसे पहले, क्लाइंट और सर्वर दोनों पर एसवीएन 1.6 में अपग्रेड करें। latest release नोट्स बड़ी फ़ाइलों (r36389) के लिए एक गति का उल्लेख करते हैं।

दूसरा, यह आपके लिए बहुत उपयुक्त नहीं हो सकता है यदि आपके पास अपनी कार्यशील प्रतिलिपि में पूरी परियोजना होनी है, लेकिन sparse directories का उपयोग करें। हम अपने बड़े रेपो के लिए ऐसा करते हैं, क्लाइंट द्वारा पहली बार शीर्ष स्तर की निर्देशिका को चेकआउट करना है, फिर अधिक डेटा प्राप्त करने के लिए, वांछित निर्देशिका पर जाने के लिए रेपो ब्राउज़र का उपयोग करें और "इस संशोधन में अपडेट करें"। यह TortoiseSVN पर अद्भुत काम करता है। 1.6 में उन निर्देशिकाओं को निकालने के लिए 'गहराई गहराई' विकल्प भी है जिन पर आपको अब काम करने की आवश्यकता नहीं है।

यदि यह आपके लिए नहीं है, तो भी आप कामकाजी प्रति के हिस्सों पर एक अद्यतन कर सकते हैं। अद्यतन आपके पास जितनी अधिक फाइलें धीमा हो जाता है (विंडोज़ पर, एनटीएफएस विशेष रूप से अद्यतन करने के लिए उपयोग की जाने वाली लॉकिंग रणनीति के साथ खराब है। Bert Huijben noticed this और 1.7 रिलीज के साथ एक फिक्स - टीबीए का सुझाव दिया, लेकिन आप अपने वर्तमान कोड को पुनर्निर्माण कर सकते हैं अपने 'त्वरित सुधार'

एक वैकल्पिक अपने फाइल सिस्टम को बदलने के लिए, यदि आप पुन: फ़ॉर्मेट कर किया जा सकता है, तो आप ext2 IFS driver की कोशिश कर सकते हैं, लेकिन मुझे यकीन है कि आप इस बात का सतर्क हो जाएगा हूँ

अंतिम विकल्प। - .svn firectories के लिए अपने वायरस स्कैनर को बंद करें, और सर्वर पर रिपॉजिटरी के लिए भी बंद करें। यदि आप सर्वर पर अपाचे चला रहे हैं, तो सुनिश्चित करें कि आपने थोड़े समय के लिए जीवित रहें (पुनः प्रमाणीकरण होने से रोकने के लिए)। अपनी कार्यशील प्रतिलिपि निर्देशिकाओं पर अनुक्रमण भी बंद करें और छाया प्रतिलिपि भी। (आखिरी मदद नहीं करता है, लेकिन आप बेहतर सुधार देख सकते हैं जो मैंने किया था, सर्वर पर एवी बंद करने के बाद मेरे एसवीएन प्रतिक्रिया 10x को बढ़ाया)।

+0

सभी सुझावों के लिए धन्यवाद। मुझे यह देखने के लिए प्रोफाइल करना होगा कि कौन सा सबसे अच्छा काम करता है। – Talesh

+0

@ तलेश - आपने कैसे प्रोफाइल किया? http://stackoverflow.com/questions/2684893/is-there-an-svn-benchmark – ripper234

2

बोझल आकार के साथ सौदा करने के लिए, मैं किसी अन्य शाखा में विभाजित बंद बाइनरी डेटा (या यहां तक ​​कि पूरी तरह से निकाल इसे कहीं और संग्रहीत करने के लिए), कोड से अलग करने पर विचार होगा। यह कम से कम चीजों को गति देना चाहिए, खासकर यदि डेटा अक्सर नहीं बदलता है।

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

1

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

विशेष रूप से विकास कोड (सभी कामकाजी कोड !!!!) उत्पादन के उत्पादन में वापस विलय कर दिया गया था और ग्राहक को जारी किया गया था।

+0

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

+0

क्षमा करें, प्रश्न का उत्तर देने के बारे में क्षमा करें। यह वही है जो हमने आपके द्वारा वर्णित एक ही स्थिति को हल करने के लिए किया था। कुछ हफ्तों के भीतर यह दुर्लभ था कि हमारे पास एक स्थिति थी जैसा आपने वर्णन किया था। – Mark

4

हमारे पास दो भंडार हैं, हमारे कोड के लिए एक (अक्सर बदलता है) और दूसरा हमारे बाइनरी डेटा (बहुत बड़ा, बार-बार बदलता है) के लिए। यह कभी-कभी दर्द होता है, लेकिन कोड के साथ काम करते समय बेहतर गति के लायक है।

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

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

जब हम डेटा भंडार में परिवर्तन करते हैं, तो हम आम तौर पर केवल उन सभी को बताते हैं जिन्हें उन्हें अद्यतन करने की आवश्यकता होती है (हम सभी एक ही कमरे में बैठते हैं)। अन्यथा, हम आमतौर पर डेटा को मैन्युअल रूप से अपडेट नहीं करते हैं; हम बस दैनिक अद्यतन स्क्रिप्ट इसे ताजा रखने दें।

0

क्या परियोजना को छोटी परियोजनाओं में तोड़ना संभव है जिसे किसी प्रकार की प्लग-इन प्रणाली से जोड़ा जा सकता है?

1

मैं इसे संक्षिप्त रखेंगे: नवीनतम संस्करण (1.6.x) को

  • अपग्रेड। 1.5.x में गति अनुकूलन भी था।
  • सुनिश्चित करें कि हर कोई TortoiseSVN का एक ही संस्करण उपयोग कर रहा है जो सर्वर के सटीक संस्करण के विरुद्ध बनाया गया है। लोगों के साथ हमें कई समस्याएं थीं और फिर अजीब समस्याएं आ रही थीं।
  • बाहरी एक ही रेपो पर सर्वर, रिपॉजिटरीज और फ़ोल्डर्स के बीच काम करते हैं। तो आप बाइनरी को दूसरे रिपो/सर्वर पर पूरी तरह से ले जा सकते हैं और बस उन्हें बाहरी से लिंक कर सकते हैं।
  • फ़ोल्डर को पुन: स्थापित करें ताकि आप परियोजना को चेकआउट कर सकें और फिर भी उत्पादक रूप से काम करने में सक्षम हो सकें। असल में हर कोई शीर्ष फ़ोल्डर्स + बच्चों को केवल तभी चुनता है जब वे पूरी तरह चेकआउट करने के लिए आवश्यक फ़ोल्डरों को "संशोधन में अपडेट करें" चुनते हैं।
  • निर्यात करने वाली स्क्रिप्ट बनाएं, फिर प्रतिबद्ध करें (या प्रतिबद्ध करने के लिए संकेत दें)। मेरे उपयोग के लिए मेरे पास ऐसी स्क्रिप्ट हैं। काम करने से पहले, मैं स्क्रिप्ट चलाता हूं और यह मेरे डब्ल्यूसी निर्यात करता है और फिर बनाता है। नोट: यह पूर्ण डब्ल्यूसी की प्रतिलिपि बनायेगा!तो यह स्पैस चेकआउट के साथ उपयोगी है जहां डेटा का आकार छोटा है (एर)।
  • रेपो के बाइनरी को स्थानांतरित करने पर विचार करें (मैं इसकी अनुशंसा नहीं करता हूं, लेकिन यह उत्पादकता को फिर से प्राप्त करने का सबसे अच्छा समाधान हो सकता है)।
  • याद रखें, निर्यात एक डब्ल्यूसी नहीं बनाता है, जिसका अर्थ है कि आप चेकआउट की तुलना में 50% डिस्क स्पेस बचाते हैं। इसलिए यदि आप इस तरह के बाइनरी को पुन: स्थापित करते हैं और बार-बार अपडेट किए गए आइटम चेकआउट के बजाय निर्यात किए जा सकते हैं, तो यह अधिक लोगों को "पूर्ण चीज़ प्राप्त करने" के लिए प्रोत्साहित करेगा और इसमें से कुछ को स्किम करने का प्रयास नहीं करेगा।
संबंधित मुद्दे