मुझे आश्चर्य है कि किसी भी विशेष शाखा से ट्रंक में बहुत छोटा बदलाव करने में कितना समय लगता है; पाठ की कुछ पंक्तियों में विलय करने के लिए 1-2 मिनट जो एक पाठ फ़ाइल में बदल गए हैं जो केवल 2k लंबा है।एसवीएन 1.6 मर्ज ऑपरेशन की गति निर्धारित करता है
मैं, यदि संभव हो, तो बहुत तेज़ नरक विलय करने के लिए, लेकिन यह नहीं पता कि कहां से शुरू करना है। मैं एक त्वरित गूगल किया है और धीमी गति से मर्ज के लिए संभावित कारणों किसी भी और निम्न में से सभी को शामिल करने लगते हैं: -
- बड़े रेपो आकार (दोनों डिस्क और संशोधन की संख्या पर आकार की दृष्टि से)।
- बड़े स्रोत पेड़
- SVN सर्वर/ग्राहक के संस्करण
- बहुत बड़े (कई एमबी) फ़ाइलें (जाहिरा तौर पर SVN आदेश परिवर्तन बाहर काम करने में पेड़ के नीचे क्रॉल करने के लिए है) (हम बहुत बड़ी नहीं है एकल फ़ाइलों तो मुझे शक है यह हमें प्रभावित करते हैं)
मुझे लगता है कि मैं वास्तव में पता लगाने के लिए जो ऊपर अंक के मर्ज इतनी धीमी गति से कर रहे हैं जानना चाहते हैं।
अभी मैं अंधेरे में हूं कि यह क्लाइंट पर काम करता है या सर्वर पर काम करता है जो सबसे अधिक समय ले रहा है (मुझे संदेह है कि यह ग्राहक है क्योंकि CPU उपयोग सर्वर पर भारी नहीं है)। मैंने सोचा था कि यह बड़ी मात्रा में मर्जिनोफो हो सकता है जिसने 100 से अधिक विलय जमा किए हैं, लेकिन मैंने एक परीक्षण किया है जहां मैंने दो शाखाओं से सभी विलय जानकारी हटा दी है और फिर विलय किया और उसी धीमेपन को पाया।
तो मैं क्या पूछना चाहता हूं: - * एसवीएन गतिविधि का निदान/प्रोफाइलिंग करने के बारे में कोई कैसे होगा? * नीचे दी गई जानकारी के आधार पर, क्या वास्तव में कुछ स्पष्ट है जो खराब प्रदर्शन का कारण बन जाएगा?
धन्यवाद
क्रिस
यहाँ कुछ तथ्य हैं/हमारे SVN स्थापना के बारे में आंकड़े
- हमारे SVN भंडार के आसपास 32000 संशोधन है। डिस्क पर
- रेपो का आकार: 8.3GB
- हमारी विकास शाखाओं प्रत्येक लगभग 1400 संस्करणीकृत फ़ोल्डर (19,000 versioned फ़ाइलों)
- SVN सर्वर है: 1.6.6 (r40053) (अपाचे में होस्ट Ubunto स्पष्ट लिंक्स पर चल रहा है)
- मैं Win7 पर कछुए 1.6.9 का उपयोग कर रहा हूं (हालांकि टीम के अन्य सदस्य SmartSVN का उपयोग करते हैं और वे उसी तरह की गति की रिपोर्ट करते हैं)।
संपादित
यह भी कहा कि जब हम शाखा/मर्ज, हम ट्रंक से शाखा और हमेशा पूरी शाखा ट्रंक में वापस विलय के लायक हो सकता है। तो सभी mergeinfo ट्रंक (और शाखाओं) फ़ोल्डर पर है।
निष्कर्ष
मेरे मामले में, यह डिस्क पहुँच कि मर्ज प्रक्रिया में अड़चन था प्रतीत होता है - जब मैं अपने एसएसडी करने के लिए अपने HDD से मेरे स्रोत पेड़ चले गए, एक ही मर्ज 50 से चला गया +/- 5 से 7 +/- 1 एस।
विलय के दौरान प्रक्रिया एक्सप्लोरर में कछुए एसवीएन प्रक्रिया को देखकर काफी कह रहा था: जबकि मेरे एचडीडी पर एक विलय करने के दौरान I/O बाइट्स अधिकांश अवधि के लिए 500kb/s और 3Mb/s के बीच था। एसएसडी पर आई/ओ बाइट 10-20 एमबी/एस तक था। [इसके बावजूद, मेरे एचडीडी पर कुछ विलय तुलनीय गति के थे (और आई/ओ बाइट्स समान थे) मेरे एसएसडी पर - इन मामलों में, मुझे लगता है कि बहुत सी फाइलें पढ़ी जा रही हैं जो पहले से ही विंडोज फाइल कैश में थीं ]।
मैंने पाया सब वृद्धि हुई मर्ज गति
- & से एक फ़ोल्डर स्रोत पदानुक्रम नीचे गहरा करने के लिए विलय के बाद: यह नहीं वास्तव में "वास्तविक जीवन" में करने के लिए हमारे लिए एक विकल्प है मर्ज ट्रैकिंग लगभग हो जाता है क्योंकि असंभव अगर "ट्रंक-स्तर" फ़ोल्डर में दर्ज नहीं किया गया है लेकिन यह दिखाता है कि बहुत छोटे पेड़ विलय करने से प्रक्रिया बहुत तेज हो जाती है।
- काम करने वाले सेट के आकार को कम करने में मदद करने के लिए विलय किया जा रहा है (बशर्ते कि आप "काम करने वाले सेट" गहराई मर्ज विकल्प का उपयोग करें और पूरी तरह से रिकर्सिव नहीं) - इसलिए फ़ोल्डर्स को हटाकर (ट्रंक के नीचे मेरे काम करने वाले सेट से) गति में वृद्धि ।
ऐसा डिस्क एक्सेस प्रतीत होता है जो मेरे विलय के साथ अधिकतर समय लेता है इसलिए छोटे पेड़ों को विलय करना तेज होता है - मेरे प्रश्न –