2010-08-30 13 views
5

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

मैं अभी भी मौसम पर अनिश्चित हूं कि ClearCase स्वयं का उपयोग करें या सबवरिसन का उपयोग करके अपना खुद का भंडार स्थापित करें। यह दो या अधिकतम तीन व्यक्ति डेवलपर टीम होगी। जिन लोगों से मैंने सुना है, मुझे यह धारणा मिली है कि क्लीयरकेस जटिल है और सीखने योग्य नहीं है क्योंकि यह उत्पादकता में वृद्धि नहीं कर सकता है। क्या यह सच है या यह गलत है?

धन्यवाद ...

उत्तर

4

मान लें कि आप दो संस्करण नियंत्रण प्रणाली (VCSs) आप का उल्लेख किया, सबवर्सन (SVN) होगा करने के लिए सीमित कर रहे हैं लगभग हर सम्मान में स्पष्ट, आसान और बेहतर समर्थन प्राप्त करें, जब तक आप उस बिंदु तक नहीं पहुंच जाते जहां आपको कई शाखाओं का समर्थन करना होगा।

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

अनुभव

मैं एक व्यक्ति के बीच के साथ ClearCase का उपयोग किया है (मुझे) और 400 से अधिक लोगों को, यह कई दिन के लिए दिन के खीज, प्रयोज्य मुद्दों और दोष है, लेकिन यह लगातार प्राप्त करने के लिए हमें की अनुमति देता है काम एक साथ किया। हर समय ClearCase स्थापना पूर्णकालिक प्रशासकों को समर्पित किया था।

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

एसवीएन समानांतर विकास और शाखाओं का समर्थन करने में गरीब क्यों है?

एसवीएन विकास की समांतर रेखाओं के समर्थन में विफल रहता है क्योंकि इसकी शाखाओं को एक साथ विलय करने के लिए बहुत ही कमजोर स्वचालित समर्थन है। इसके विपरीत, मेरे द्वारा लिखे गए सभी अन्य वीसीएस में शाखाओं को एक साथ विलय करने के लिए अच्छा समर्थन है; आम मामलों के लिए यह एक शून्य प्रयास ऑपरेशन है।

ब्रांचिंग मानव जीवन में संस्करण नियंत्रण प्रणाली मॉडल समेकन का तरीका है (उदाहरण के लिए दो डेवलपर समानांतर में दो अलग-अलग मुद्दों पर काम करते हैं, या एक डेवलपर जिसके पास एक ही समय में कई समस्याएं खुलती हैं)। लेकिन ब्रांचिंग बेकार है यदि आप आसानी से सभी के काम को एक सुसंगत रूप से संयोजित नहीं कर सकते हैं!

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

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

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

अन्य VCSs में आप एक शाखा बग समाधान या अन्य विभिन्न शाखाओं में एक सुविधा युक्त विलय करने के लिए VCS पूछ सकते हैं। दिन के अंत में इन सभी शाखाओं (जिसमें स्वयं अन्य शाखाओं की सामग्री होती है) को फिर मुख्य शाखा में विलय कर दिया जा सकता है। अधिक बार नहीं इस का सबसे VCS द्वारा स्वचालित रूप से और सही ढंग से नियंत्रित किया जाएगा की तुलना में, SVN स्वचालित लचीलापन इस तरह की होने और समानांतरवाद लगभग अकल्पनीय है के साथ है, जबकि।

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

फ्लिप पक्ष पर, आसान ब्रांचिंग और विलय का नकारात्मक पक्ष यह है कि आपको नियमित अंतराल पर एक साथ परिवर्तन विलय करने के बारे में संगठित और कठोर होना चाहिए क्योंकि यह स्वचालित रूप से और नहीं होता है।

अन्य विकल्प

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

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

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

यदि आप बीजेडआर या जीआईटी जैसे डीवीसीएस के साथ जाना चुनते हैं तो आपको शायद जिस DVCS का उपयोग शुरू करना है, उस पर आपको बहुत लटका पाने की आवश्यकता नहीं है। व्यापक रूप से प्रयुक्त सिस्टम सभी एक-दूसरे के बीच निर्यात और आयात का समर्थन करते हैं और कम से कम एसवीएन से आयात कर सकते हैं।

+0

क्यों लगता है कि सबवर्सन उन परिदृश्यों के लिए अच्छा नहीं है जहां मुझे समांतर विकास और शाखा की आवश्यकता होगी? – Manoj

+0

मनोज: मैंने आपके प्रश्न को आजमाने और कवर करने के लिए अपना जवाब अपडेट कर दिया है। – Jared

+0

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

4

मैं उपversण के लिए जाना चाहता हूं। इसमें एक क्लीनर इंटरफ़ेस है और ClearCase से अधिक सहज है। मेरी कंपनी में लोग अक्सर सीखने के लिए संघर्ष करते हैं ClearCase और टीमें svn में माइग्रेट कर रहे हैं। Svn का उपयोग करने का एक और अच्छा कारण यह है कि यह मुफ्त है।

3

इससे दूर रहें! इसमें कुछ विशेषताएं हैं जो svn गायब है (गतिविधियों की तरह) लेकिन निश्चित रूप से आपकी टीम के 3 लोगों के लायक नहीं है।

3

नवंबर 2011 अपडेट करें: एक साल बाद, मैं वास्तव में ClearCase के विरुद्ध सलाह दूंगा।

यह अब स्पष्ट है, Rational ClearCase has been bought by IBM (2003) के बाद से, कि 25+ वर्ष पुराने उत्पाद में कोई बड़ा विकास नहीं होगा।
नवीनतम सुविधाओं में अभी भी थोड़ा सुधार हो सकता है (release notes for 7.1.1 देखें), और atomic checkinsउत्पाद के भाग भाग हैं, लेकिन क्लाइंट और सर्वर के बीच अंतर्निहित संचार प्रोटोकॉल अभी भी धीमा है और स्केल करने में असमर्थ है।

दरअसल, साफ़केस को स्क्रैच से फिर से लिखा गया है और कहा जाता है, Rational Team Concert उत्पाद का हिस्सा।
वह नया संस्करण (आरटीसी 3.x) वास्तव में बहुत अच्छा है, साफ़केस की तुलना में बहुत तेज़ है, और निजी विकास के लिए अनुमति देने, किसी के विकास को अलग करने का एक दिलचस्प तरीका प्रदान करता है।

आज, गीट जैसे डीवीसीएस भी एक अच्छा विकल्प हैं, लेकिन I have detailed in this question के रूप में, यह एक बड़े उद्यम के लिए एक छोटी सी प्रक्रिया नहीं है।


प्रारंभिक जवाब: अगस्त 2010:

ClearCase जटिल नहीं है, लेकिन यह SVN से काफी अलग है। और काफी धीमी;)
ClearCase introduction देखें।

मैंने स्नैपशॉट व्यू के भीतर पहले ही other repos working tree working directly का प्रबंधन किया है।

जटिल विलय वर्कफ़्लो के साथ बड़ी परियोजनाओं के लिए, ClearCase (विशेष रूप से ClearCase UCM) इसके लायक हो सकता है।
एक सरल परियोजना (मर्ज वर्कफ़्लो की अवधि में) के लिए, एसवीएन पर्याप्त है।

यह भी देखें:

+0

"वर्कफ़्लो मर्ज करें": http://stackoverflow.com/questions/216212#216228 – VonC

1

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

+0

वास्तव में यह सच है! क्या आप एक संदर्भ उद्धृत कर सकते हैं? – Manoj

+0

मैं नहीं कर सकता। आरटीसी प्रशिक्षक (आईबीएम पक्ष से) ने यही कहा है। लेकिन इसे गूगल करने का प्रयास करें। मुझे यकीन है कि बहुत सारे लिंक होंगे :) –

-4

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

+9

मुझे इस बात का परेशान है कि इस जवाब को नॉनोबजेक्टिव कैसे लगता है। उत्कृष्टता के कई दावे हैं, लेकिन इसे वापस करने के लिए कोई पदार्थ नहीं है। – Flexo

2

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

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

सीसी प्रभावी ढंग से उपयोग किया जा सकता है, लेकिन .. मैं कहूंगा कि यह शायद ही कभी अतिरिक्त प्रयास के लायक है। एसवीएन बस अधिकांश परिदृश्यों के लिए आसानी से काम करता है, जो संभवतः जीआईटी और मर्कुरियल के साथ काम करने का कारण है।