2011-11-23 17 views
23

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

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

गेरिट तुलना कैसे करता है? क्या यह रेपो इंडेक्स करता है?

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

मैं अन्य कोड समीक्षा टूल के लिए भी खुला हूं, न केवल गेरिट।

+1

बस यह इंगित करना चाहता था कि आपको हमेशा एक पुल अनुरोध दर्ज करने के अंत तक इंतजार नहीं करना पड़ेगा। गिटहब ने एक पोस्ट लिखा कि वे उनका उपयोग कैसे करते हैं, और वे जल्दी ही अनुरोध बनाते हैं: https://github.com/blog/1124-how-we-use-pull-requests-to-build-github। फिर भी आपके पास अन्य मुद्दों को ठीक नहीं करता है। – jszakmeister

+1

अंत में, हमने बस पुल अनुरोधों का उपयोग करने के साथ जाने का फैसला किया; पुल अनुरोध खोले जाते हैं और फिर हमारी टिकट प्रणाली पुल अनुरोध यूआरएल के साथ अपडेट की जाती है। यह विलय नहीं हुआ है जब तक क्यूए ने परिवर्तनों की पुष्टि नहीं की है, और फिर वे विलय करते हैं। –

उत्तर

20

मैंने काम पर गेरिट का उपयोग करना शुरू कर दिया है (6 की छोटी टीम, घर में, कोई गिथब)। इसे किसी भी चीज़ को "इंडेक्स" करने की आवश्यकता नहीं है, लेकिन गेरिट "मास्टर" रिपोजिटरी को पकड़ना पसंद करता है। तो एक नया डेवलपर सीधे गेरिट से क्लोन होगा।

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

कई प्रकार के अनुमति विकल्प हैं जो कि गेरिट के साथ स्थापित हो सकते हैं, जो कुछ उपयोग करने में लगते हैं। यदि आवश्यक हो, तो आप कॉन्फ़िगर कर सकते हैं कि कौन से उपयोगकर्ता प्रति-शाखा आधार पर कौन सी कार्रवाइयां कर सकते हैं।

हमारे पास एक बड़ी भंडार (20+ वर्षीय कोड बेस) है, लेकिन केवल 2 साल के प्रतिबद्धता इतिहास (पिछले वीसीएस से माइग्रेट किया गया) है। कोई प्रदर्शन समस्या नहीं है और जिस तरह से गेरिट काम करता है, मुझे उम्मीद नहीं है कि रिपोजिटरी बढ़ती जा रही है।

[मैं क्रूसिबल उपयोग नहीं किया है।]

+0

क्या आपके मानक वर्कफ़्लो में विषय/फीचर शाखाएं शामिल हैं? हम मास्टर (अनिवार्य रूप से) रिलीज करने योग्य रखना चाहते हैं, इसलिए सभी बग और एन्हांसमेंट विभिन्न शाखाओं में जाते हैं। –

+0

हां, सभी विकास शाखाओं (और शाखा पर समीक्षा) पर किया जाता है, फिर एक और कदम शाखा में मास्टर को मर्ज करना है। मर्ज चरण भी गेरिट के माध्यम से जाता है ताकि मास्टर में सुविधा को शामिल करने से सुविधा के विकास से अलग से अनुमोदित किया जा सके। गेरिट का वर्तमान संस्करण मर्ज कमेट्स की विशेष रूप से अच्छी तरह से समीक्षा की संभाल नहीं करता है, लेकिन अधिक जानकारी के लिए http://code.google.com/p/gerrit/issues/detail?id=665 देखें। –

2

आप वास्तव में अलग कांटे पुल अनुरोधों को जारी करने के लिए नहीं है, आप एक ही रेपो करने से हर किसी को है और GitHub के लिए सुविधा शाखाओं धक्का कर सकते हैं, उसके बाद ग्रे से अनुरोध करें "से 'फीचर -1-' से 'मास्टर'"

+0

ठीक है, मुझे पता है, लेकिन अलग-अलग कांटे को विशेषताओं के स्वामित्व को इंगित करना और साथ ही यह सुनिश्चित करना अच्छा है कि हम मुख्य रेपो में अनाथ शाखाओं के समूह के साथ समाप्त न हों। –

4

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

मुझे विश्वास नहीं है कि आपके पास कोई प्रदर्शन समस्या होगी - Google और अन्य बड़ी कंपनियों में आंतरिक रूप से अधिकांश एंड्रॉइड दुकानों और अन्य स्थानों द्वारा गेरिट का उपयोग किया जाता है। हजारों रिपॉजिटरीज़ को धक्का देने वाले सैकड़ों डेवलपर्स असामान्य नहीं हैं।

यदि आप वर्तमान में github पर होस्टिंग कर रहे हैं, तो आपको अपना खुद का हार्डवेयर प्रदान करने की आवश्यकता होगी, जिसे कुछ हद तक बीफ़ी होना चाहिए। गेरिट खुशी से उन सभी मेमोरी का उपयोग करेगा जो आप इसे दे सकते हैं ... मेरा मानना ​​है कि कुछ जगहें 64 जीबी या अधिक रैम का उपयोग करती हैं, लेकिन कुछ सौ डेवलपर्स के लिए $ DAYJOB लगभग 16 जीबी के साथ आता है।

विषय शाखाएं गेरिट पर काफी अच्छी तरह से काम करती हैं और हर समय बेहतर होती जा रही हैं।

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

मुझे संदेह है कि गेरिट आपकी आवश्यकताओं को पूरा करेगा। मैं आपको सलाह देता हूं कि आप इसे आज़माएं!

5

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

समीक्षा बोर्ड और गिट के साथ मामूली समस्याएं रेपो की शुरुआत के बाद से प्रत्येक प्रतिबद्धता की समीक्षा करने की कोशिश करने जैसी कुछ विषम स्थितियों को शामिल करती हैं - मैंने पाया कि आम तौर पर ऐसे मामलों में मुझे खुद को अलग करना था और इसे देने के बजाय इसे अपलोड करना था समीक्षा बोर्ड की postreview.py स्क्रिप्ट इसे संभाल लें।

ध्यान दें कि बहुत कम कोड समीक्षा उपकरण वास्तव में क्रूसिबल द्वारा जिस तरह से भंडार को अनुक्रमित करते हैं। उनमें से अधिकांश पैच पर भरोसा करते हैं, चाहे कुछ उपकरण जैसे postreview.py या प्रतिबद्धता को देखकर और आंतरिक रूप से भिन्नता उत्पन्न कर रहे हों।

+0

गेरिट? सुंदर? * उलझन में हंसी * – SyntaxRules

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