दिलचस्प पोस्ट
यूनिट टेस्ट बनाम फंक्शनल टेस्ट दो अलग-अलग डेटा के साथ दो अलग-अलग जगहों को वापस करने की आवश्यकता है जहां खंड PHP में JSONP Resultset निकालें कमांड को पूरा करने के लिए बिना shell_exec का उपयोग करने का कोई तरीका क्या है? IOS में कस्टम UIActivity कैसे बना सकता हूं? मैं सी में दो स्ट्रिंग कैसे जोड़ूं? पैरामीट्रैक्ड क्वेरी एसक्यूएल इंजेक्शन से कैसे मदद करते हैं? .myd, .myi, .frm फ़ाइलों से MySQL डाटाबेस कैसे पुनर्प्राप्त करें I एक डेटा.फ्रेम में प्रति समूह का मतलब मैं इसे कैसे कस्टम ऑब्जेक्ट के साथ एक NSMutableArray सॉर्ट कर सकता हूँ? MVC रिटर्न आंशिक दृश्य JSON के रूप में कई 'if else' स्टेटमेंट को क्लीनर दृष्टिकोण में परिवर्तित करना CURLOPT_POSTFIELDS के लिए पोस्ट प्रारूप कर्ल करें एंड्रॉइड: सटीक ऊंचाई कैसे प्राप्त करें? JSP / Servlet में कैस्केडिंग ड्रॉपडाउन सूचियों की गणना

क्लीअरकेज़ फायदे / नुकसान

क्योंकि मैं वर्तमान में आईबीएम रेशनल क्लियर सीज़ सीखने के लिए संघर्ष कर रहा हूं, मैं आपकी पेशेवर राय सुनना चाहता हूं।

मैं अन्य संस्करण-नियंत्रण-प्रणालियों जैसे उपवर्सन या जीआईटी की तुलना में फायदे / नुकसानों में विशेष रूप से रूचि रखता हूं।

वेब के समाधान से एकत्रित समाधान "क्लीअरकेज़ फायदे / नुकसान"

आप अपने SO उत्तर में ClearCase और Git के बीच एक अच्छी तुलना पा सकते हैं:
" मुख्य डेवलपर्स को क्या पता होना चाहिए कि मूलभूत साफ़-साफ़ संकल्पना क्या हैं? ", कुछ प्रमुख अंतर (और साफ़-साफ़ की कुछ कमियों को दर्शाते हुए)


फ़ाइल केंद्रित परिचालन

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

फाइल-प्रति-फ़ाइल संचालन का अर्थ है: मंद पुनरावर्ती संचालन (जैसे पुनरावर्ती चेकआउट या पुनरावर्ती "स्रोत नियंत्रण में जोड़ें" , यहां तक ​​कि clearfsimport द्वारा)।
उस चीटमय प्रोटोकॉल के दुष्प्रभाव को कम करने के लिए एक तेज़ लैन अनिवार्य है।

केंद्रीय VCS

अन्य पहलू को ध्यान में रखते हुए इसका केंद्रीकृत पहलू है (भले ही इसे बहु-साइट दोबारा वीओबी सुविधा के साथ "वितरित किया जा सकता है")
यदि नेटवर्क वीओबी तक पहुंच की अनुमति नहीं देता है, तो डेवलपर्स निम्न कर सकते हैं:

  • अभी भी स्नैपशॉट दृश्यों के भीतर काम करते हैं (लेकिन अपहृत फ़ाइलें केवल)
  • नेटवर्क की बहाली के लिए इंतजार अगर वे गतिशील विचारों का उपयोग कर रहे हैं

महंगे वितरित वीसीएस विकल्प

आप Vob की नकल करके कुछ वितरित VCS सुविधा प्राप्त कर सकते हैं।
परंतु:

  • आपको इसे एक्सेस करने के लिए एक विशेष प्रकार के लाइसेंस की आवश्यकता है
  • यह लाइसेंस महंगा है और नियमित लाइसेंस की लागत में बढ़ोतरी
  • दोहराए गए vob (व्यवस्थापक vob, admin pvob, …) का उपयोग करने वाले किसी भी शब्द को भी दोहराया जाना चाहिए (जिसका अर्थ है कि वितरित विकास के साथ सीधे संबंधित नहीं होने वाले कुछ परियोजनाओं को अब भी बहु-साइट लाइसेंस देना होगा …)

पुराने और उपयोगकर्ता के अनुकूल जीयूआई नहीं

  • जीयूआई बहुत पुराना स्कूल और अव्यावहारिक है (मध्य 9 0 के एमएफसी लुक, पूरी तरह से तुल्यकालिक जीयूआई, जिसका अर्थ है कि आपको कहीं और क्लिक करने से पहले एक ताज़ा करने की प्रतीक्षा करना पड़ता है): बेसलाइन ब्राउज़ करते समय, आप विशेष रूप से एक के लिए जल्दी से नहीं देख सकते
  • यूनिक्स पर जीयूआई बिल्कुल विंडोज पर नहीं है (नवीनतम 7.1 संस्करण बेहतर है लेकिन अभी तक नहीं है)
  • स्थापना प्रक्रिया काफी जटिल है (हालांकि CC7.1 द्वारा शुरू की गई नवीनतम इंस्टालर प्रबंधक अब विंडोज या यूनिक्स पर एक सुसंगत जीयूआई है और यह प्रक्रिया को सरल करता है)
  • केवल वास्तविक अमीर आवेदन केवल सीसीआरसी (रिमोट क्लाइंट) के लिए विकसित किया गया है

यूसीएम विसंगतियां और एकजुटता में

जैसा कि " क्लीयर सीज़ की सुविधाओं का लाभ उठाने के तरीके " में उल्लेख किया गया है, गतिशील विचार महान होते हैं (डिस्क के प्रति उन्हें प्रतिलिपि किए बिना नेटवर्क के माध्यम से डेटा देखने का एक तरीका), लेकिन मुख्य विशेषता UCM रहती है : यदि आपके पास यह वास्तविक संपत्ति हो सकती है जटिल कार्यप्रवाह के साथ बड़ी परियोजना

उस मोर्चे पर कुछ कमियों:

  • घटकों के बीच निर्भरता अच्छी तरह से एक गहराई से बेहतर नहीं है (" परजीवी आधार रेखा " की बग के कारण)
  • यूसीएम के पास अब भी कुछ सुसंगतता और विसंगतियां हैं, जैसा कि सीएम चौराहे में प्रलेखित है

बेस साफ़ कैस के साथ सीमित नीतियां

यूसीएम इस्तेमाल किए बिना ClearCase का उपयोग करने का मतलब है कि एक नीति को परिभाषित करना:

  • शाखा बनाएं (अन्यथा कोई भी शाखा बना सकता है, और आप मर्ज वर्कफ़्लो दुःस्वप्न के साथ, उनमें से एक गज़िलन के साथ समाप्त होते हैं)
  • लेबल्स डाल (अन्यथा आप कुछ फाइलों को लेबल करना भूल जाते हैं, या आप एक लेबल डालते हैं जहां आप नहीं चाहते थे, या आप एक बटन से दूसरे संस्करण को "ले जाएँ" (गपशप) करते हैं: कम-से-कम यूसीएम बेसलाइंस नहीं जा सकते हैं)
  • परिवर्तनों को परिभाषित करें ChangeSets केवल यूसीएम गतिविधियों के साथ मौजूद हैं आधार ClearCase के साथ, आप चालाक " cleartool find " अनुरोधों में कम हो …

कोई एप्लिकेशन अधिकार नहीं

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

कोई उन्नत API नहीं

  • केवल सीएलआई पूर्ण है (" cleartool " क्लीअरकेस कमांड लाइन इंटरफेस है), जिसका अर्थ है कि किसी भी स्क्रिप्ट (पर्ल या अन्य भाषा में) उन cleartool कमांडों के आउटपुट को पार्स करने में शामिल है)
  • ClearCase स्वचालन पुस्तकालय (सीएएल) मौजूद है, लेकिन काफी सीमित है
  • जावा एपीआई मौजूद है, लेकिन केवल सीसीआरसी ग्राहक के लिए वेब दृश्य के लिए।

भंडार को आसानी से केंद्रीकृत / बैक अप नहीं देखें

देखें स्टोरेज सबवेर्सियन के "एसएसएन" के समतुल्य हैं, एक सबवेर्सन वर्कस्पेस की सभी निर्देशिकाओं में कई .svn के बजाय केवल एक "दृश्य संग्रह" प्रति दृश्य है। यह अच्छा है।

बुरी बात यह है कि प्रत्येक ऑपरेशन एक दृश्य (एक सरल " ls ", चेकआउट, चेकिंग, …) के तहत एक नेटवर्क अनुरोध को ट्रिगर करेगा view_server प्रक्रिया जो आपके व्यू सर्वर का प्रबंधन करता है
2 विकल्प:

  • अपने वर्कस्टेशन पर अपना दृश्य भंडारण घोषित करें: स्केलेबिलिटी के लिए महान, आपके पास लैन पर टैक्स के बिना जितने चाहें उतने दृश्य हो सकते हैं: सभी संचार आपके वर्कस्टेशन पर सीधे किए जाते हैं। लेकिन अगर उस मशीन पर आप मर जाते हैं, तो आप अपना विचार हटा देते हैं
  • आपके व्यू संचय को एक केंद्रीकृत सर्वर पर घोषित करें: इसका अर्थ है कि सभी दृश्य-प्रक्रिया प्रक्रिया वहां बनाएगी और किसी भी उपयोगकर्ता द्वारा किसी दृश्य पर सभी कार्रवाइयां उस सर्वर से संचार करनी होंगी। यदि बुनियादी ढांचा "सही" (विशेष हाई-स्पीड लैन, समर्पित सर्वर, निरंतर मॉनिटरिंग) है, तो यह किया जा सकता है, लेकिन व्यवहार में, आपका लैन इस मोड का समर्थन नहीं करेगा।

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


गतिशील दृश्यों के बारे में साइड चर्चा:

"गतिशील दृश्य" पहलू को जोड़ने के लिए, इसका एक फायदा (यह गतिशील है) और एक कमी (यह गतिशील है)।
एक छोटी सी टीम के बीच एक छोटे से विकास को तेजी से साझा करने के लिए एक सरल माहौल बनाने के लिए डायनामिक दृश्य महान हैं: एक छोटे से विकास प्रयास के लिए, एक डायनामिक दृश्य 2 या 3 डेवलपर्स को एक दूसरे के साथ लगातार संपर्क में रहने में मदद कर सकता है, तुरन्त देख रहा है कि किसी के टूटने के बाद दूसरे विचारों में कुछ
अधिक जटिल विकास प्रयासों के लिए, स्नैपशॉट दृश्य द्वारा प्रदान की जाने वाली कृत्रिम "अलगाव" बेहतर है (आप केवल तभी ताज़ा देखते हैं- या "अपडेट" – आपका स्नैपशॉट दृश्य)
वास्तविक भिन्न विकास प्रयास या पाठ्यक्रम के लिए, सच कोड अलगाव को प्राप्त करने के लिए एक शाखा को अभी भी आवश्यक है (कुछ बिंदुओं पर विलय की आवश्यकता होगी, जो साफ़-साफ़ कसौटी बहुत अच्छी तरह से संभालती है, यद्यपि धीरे-धीरे फ़ाइल-प्रति-फ़ाइल)

मुद्दा यह है, आप सही कारणों के लिए दोनों का उपयोग कर सकते हैं।

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

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

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

  • इसमें सभी के साथ एक स्नैपशॉट दृश्य
  • इसमें डीएलएल या जार या एक्सई के साथ एक स्नैपशॉट दृश्य (फ़ाइलें जो हर पांच मिनट में बदलती नहीं हैं: प्रति दिन एक अपडेट), और केवल दृश्यमान स्रोतों के साथ गतिशील दृश्य

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

यह सच है कि पूर्णकालिक नानी की आवश्यकता के लिए यह बहुत जटिल है, यह भी चिंता का विषय है।

एक प्रणाली का एक पूर्ण दुःस्वप्न यह मुझे इच्छा थी कि हम वापस वीएसएस में जा सकते हैं! (कभी भी किसी भी आधुनिक स्रोत-नियंत्रण प्रणाली को उपवर्तन या गिट जैसे दिमाग में नहीं रखें!)

  • यह slooooow है
  • यदि आप गतिशील विचारों का उपयोग करते हैं और नेटवर्क नीचे जाता है तो आप स्रोत की आपकी कार्यशील प्रतिलिपि तक पहुंच नहीं सकते हैं । आप कुछ भी नहीं कर सकते हैं बस बैठकर प्रतीक्षा कर सकते हैं।
  • यदि आप स्नैपशॉट दृश्य का उपयोग करते हैं, जो आप विरोध में चलते हैं और "अपहृत" फ़ाइलों को हर समय दिखते हैं, तो आपकी कार्यशील प्रतिलिपि में फ़ाइलें स्रोत रिपॉजिटरी में जितनी ही समान होंगी
  • जब भी आप किसी बड़े अपडेट का प्रयास करते हैं या आपरेशन देने की कोशिश करते हैं तो यह हमेशा एक कारण या किसी अन्य के लिए असफलता से विफल रहता है , आपके क्लियरसीज़ गुरु को इसे कुछ घंटे / दिन खर्च करने की आवश्यकता होती है। ओह, हाँ, आपके पास एक समर्पित, पूर्णकालिक क्लियर सीज़ गुरु होना चाहिए !
  • जब यह असफल हो जाता है तो आप अक्सर ऑपरेशन वापस रोल नहीं कर सकते , या तो, आप प्रगति में एक ऑपरेशन के साथ फंस रहे हैं और डेवलपर्स अवरुद्ध हैं
  • जब आप सुंदर (?) चिह्नों को देखते हैं, तो जीयूआई बहुत खराब है – पूरी फाइल पथ देखने के लिए खिड़कियां का आकार बदलने में असमर्थ होने जैसी चीजों के नीचे!
  • उनका समर्थन कर्मचारी कुछ भी ठीक करने के लिए अनिच्छुक हैं। उनका पहला जवाब हमेशा " यह डिज़ाइन से होता है " और "क्या आप इसके आसपास काम कर सकते हैं?" यदि वे अंततः एक फिक्स प्रदान करते हैं (बहुत बहस के बाद) यह सबसे तत्काल समस्या के लिए सबसे बुनियादी संभव तय होगा

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

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

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

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

परिवर्तनों के बिना अद्यतन धीमे हो सकते हैं जब आप किसी स्नैपशॉट दृश्य के साथ अपडेट करते हैं, प्रत्येक फ़ाइल अपडेट, न केवल संशोधित फाइलें। मैंने 20,000 ++ फ़ाइलों के साथ एक परियोजना पर काम किया मैं अपने काम मशीन में दूरस्थ होगा, अद्यतन शुरू, फिर काम करने के लिए ड्राइव; कॉफी ले आओ; मेरे डेस्क पर जाने के समय यह खत्म हो गया था। यह एक अतिशयोक्ति की तरह लग सकता है, लेकिन यह दुख की बात नहीं है।

जब तक आप एक बहुत छोटी टीम में नहीं हैं, तब तक गतिशील विचार भयानक होते हैं और अगर यह मामला है, तो आपके पास भी ClearCase क्यों है? मैंने देखा है कि अनगिनत लोगों के विचारों को रोक दिया गया है क्योंकि किसी ने ऐसी फाइलों में चेक किया है जो हर किसी के विचारों को तोड़ा। आपको हमेशा अपने स्वयं के दृश्य पर किसी भी टकराव को अद्यतन और मर्ज करना चाहिए। इस तरह, परिवर्तन केवल आपको प्रभावित करते हैं एक गतिशील दृश्य के साथ, आप बैक अप को आगे बढ़ाने से पहले मर्ज नहीं कर सकते; आप केवल प्रतिबद्ध और आशा करते हैं

मुझे पता है कि लागत शायद एक बड़ी चिंता का विषय नहीं है, लेकिन डेवलपर्स जो कंपनी के लिए पैसा कमाते हैं, वे मजे की घटनाओं या नए उपकरणों ($ 50k- $ 100k खर्च करते हैं (साफक्वेस्ट लाइसेंस के आधार पर, जो कि आम आमदनी है) कुर्सियाँ, मॉनिटर, आदि)। आईबीएम ने क्लियरसीज़ जा रहा रखने के लिए कर्मचारी होने की सलाह दी है। क्यों नहीं उन लोगों को कंपनी के लिए राजस्व उत्पन्न करने के लिए फिर से प्रयोजन, यह सुनिश्चित करने के बजाय कि चीजों को क्रैश और जला नहीं?


कुछ कारण जो मैंने स्विचन के लिए नहीं सुना है:

  • सीखना समय और धन ले जाएगा
    • सीखना एसवीएन या मर्कुरियल को एक दिन से ज्यादा नहीं लेना चाहिए। केवल क्लियरकेस डेवलपर्स के लिए व्यवस्थापक का एक निश्चित अनुपात होने का सुझाव देता है।
  • प्रवासन दर्ददायक होगा
    • यही कारण है कि उपकरण मौजूद हैं: cc2svn
    • यह मर्कुरियल के साथ आसान नहीं है
  • सुरक्षा
    • एसवीएन एएफएआईके में कोई ज्ञात अंतराल छेद नहीं है, और विकास दल जल्दी से पाया जाता है जो कुछ भी तय करने के लिए समर्पित है रक्षा विभाग एसवीएन के साथ ठीक लगता है
  • कोई वास्तविक उत्पादकता लाभ बाद में नहीं
    • बिना किसी बदलावों के बग्स को ट्रैक करने का प्रयास करना हमेशा के लिए लगता है मुझे जब तक मैं बग नहीं देख सकता वापस रोल करने में सक्षम होने से प्यार करता हूँ आप ऐसा नहीं कर सकते ClearCase में
  • एकाधिक साइट
    • वन्दस्को उस समस्या को हल करता है यह हालांकि मुक्त नहीं है।

केवल एक चीज है जो कि साफ़-सीज बाकी की तुलना में बेहतर करती है, वहीं दूसरी शाखाओं को एक दूसरे ट्रैक के रूप में रखते हुए व्यक्तिगत फाइलें बांटती हैं।

सब कुछ मैंने स्पष्ट रूप से किया है हमेशा मुश्किल लगता है । जबकि, मुझे कभी अन्य प्रणालियों के साथ ऐसा प्रभाव नहीं पड़ा है (इस अवसर पर सीवीएस को छोड़कर)

मैंने एसवीएन, सीवीएस, क्लीयरकेस, और मेर्क्यूरियल का उपयोग किया है

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

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

ClearCase के लिए किसी भी क्षमता से संबंधित सभी अनुभव मैंने अक्षम, बदसूरत, अति जटिल, धीमी, भ्रामक, महंगी और असुविधाजनक है I

ऐसा लगता है कि प्रबंधकों और इंजीनियरों को आकर्षित किया जा रहा है जो अभी तक सभी गलत हैं

अरे, आईबीएम और तर्कसंगत लोगों को इस तरह के भद्दा उत्पाद बेचने के लिए शानदार बिक्री होनी चाहिए।

हम यहां दिए गए कई कारणों के लिए सिर्फ गिट पर सीसी को पलायन कर रहे हैं। मैं सीसी या किसी अन्य वाणिज्यिक स्रोत नियंत्रण प्रणाली से दूर रहने के लिए एक कारण जोड़ना चाहता हूं।

आपके महत्वपूर्ण व्यापारिक डेटा को ClearCase में बंधक बना दिया गया है। आप इसे बाहर नहीं कर सकते

आपका महत्वपूर्ण व्यावसायिक डेटा कोड है, इसका संस्करण इतिहास और सभी मेटाडेटा जैसे टिप्पणी करना, जिन्होंने चेक इन किया है और कब।

सभी सॉफ़्टवेयर में एक सीमित उपयोगी जीवन होगा। आपको हमेशा अपने आप से पूछना चाहिए कि जब आप एक नई प्रणाली पेश करते हैं जो महत्वपूर्ण व्यावसायिक डेटा निगलती है, चाहे वह कोड, कीड़े, ग्राहक डेटा या क्या न हो: मैं अपना डेटा कैसे पुनः प्राप्त करूं? यदि आप उस प्रश्न का उत्तर नहीं दे सकते हैं, तो आपको उस सिस्टम को पेश नहीं करना चाहिए।

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

यह किसी उपद्रव के बीच कहीं और छोटी से मध्यम अवधि तक हमारे लिए एक समस्या होगी। कुछ सालों में, यह अब ज़रूरी नहीं है, लेकिन शायद 1-3 साल के लिए यह बात होगी

(सीसी को अन्य एससीएम में स्थानांतरित करने के लिए वाणिज्यिक उपकरण हैं, लेकिन उन्हें हमारी जरूरतों के लिए पर्याप्त समझा नहीं गया है, और मुझे संदेह है कि यह संभव होगा। न्यूनतम निर्यात हमने काफी समय लिया।

यह सबक सीखा है: स्वामित्व प्रणालियों के लिए महत्वपूर्ण व्यवसाय डेटा को कभी भी न डालें।

कोई परमाणु नहीं करता है

एक बार जब आप फाइलों में जाँच लें तो एक निश्चित स्थिति में लौटना बहुत मुश्किल है, क्योंकि परमाणु कमिट समर्थित नहीं हैं। जब एकाधिक फाइलों में जांच हो जाती है, प्रत्येक फाइल को एक नया संशोधन (सीवीएस के समान) मिलता है और चेक-इन पर ही नहीं मुझे लगता है कि यह एक महत्वपूर्ण विशेषता है, क्योंकि आप एक ही फाइल को वापस नहीं लौटना चाहते हैं, लेकिन कार्य को पूरा करें (जो कार्य करना चाहिए)। ClearCase के साथ आप केवल कुछ राज्यों को लेबल का उपयोग करके वापस कर सकते हैं। हर चेक-इन के लिए क्लियर केज़ लेबल का प्रयोग करते हुए ओवरकिल होता है और ऐसा नहीं किया जाता है।

भद्दा उपयोगकर्ता इंटरफ़ेस

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

उच्च प्रशासन प्रयास

क्लियर सीज़ जानवरों को नियंत्रित करना स्पष्ट या हल्के से दूर है (अन्य सीसीएम प्रणालियों जैसे सीवीएस, उपक्रम या जीआईटी में अंतर) कुछ समर्पित क्लियरर्स विशेषज्ञों को रखने के लिए बस इसे चलते रहने के लिए।

भयानक प्रदर्शन

एससीएम-उपकरण के साथ इंटरफेस करते समय अपने डेवलपर्स की प्रतीक्षा करते हुए कुछ भी बुरा नहीं है, यह हाथ ब्रेक सक्षम होने के साथ-साथ ड्राइविंग की तरह है। यह आपके मस्तिष्क को धीमा कर देती है और आपका काम भी अपने स्नैपशॉट दृश्य में नई नई फ़ाइलें प्राप्त करना 10K कलाकृतियों के लिए 30 मिनट लगते हैं। उसी राशि के लिए एक अपडेट (कोई कलाकृतियों को बदलना नहीं) लगभग 5 मिनट लगते हैं। जब बहुत कुछ प्रयोग किया जाता है और विभिन्न अप-टू-डेट दृश्यों के बीच कूद होता है तो बहुत इंतजार का मतलब है यह भी बदतर हो जाता है, जब आप फ़ाइलों पर काम कर रहे हैं और आप इन्हें चेक-इन या अपडेट करना चाहते हैं। चेक आउट, चेक-इन और स्रोत नियंत्रण चक्रों में जोड़ने से लगभग 10-15 सेकंड लगते हैं जो स्पष्ट रूप से एक दुःस्वप्न है जब आप पुनः नामकरण / चलती प्रकार या विधियों (कई फाइलें प्रभावित हो सकते हैं) को पुन: लागू करने पर यह बहुत परेशान हो जाता है।

वितरित विकास के समर्थन की कमी

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

वैकल्पिक के रूप में गिट

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

यह जानकारी http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/ से ली गई है

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

क्लीयरकेस के डाउनसाइड्स – यहां सबसे गहराई से पोस्ट करने के लिए एक अतिरिक्त।

  1. मर्ज टूल उपयुक्त नहीं है यह आपकी सहायता करता है, आपके द्वारा किए गए कोई भी निर्णय याद नहीं रखता है, इसकी सिर्फ एक महिमा है

  2. मर्ज टूल को जांचने के लिए निर्देशिकाओं को भी जांचना होगा ताकि उन्हें मर्ज की आवश्यकता हो। यह थोड़ा पागल है

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

  4. सभी जीयूआई टूल में विलंबता का एक टन की आवश्यकता होती है यहां तक ​​कि किसी फ़ाइल पर क्या किया जा सकता है यह देखने के लिए उच्च गति कनेक्शन की आवश्यकता होती है तो घर से काम कर रहे फाइल पर क्लियर सीज़ टूल में राइट-क्लिक करने से नेटवर्किंग आवश्यकताओं की अत्यधिक मात्रा के कारण उच्च गति वाले इंटरनेट में एक या दो मिनट लग सकते हैं

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

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

  7. ClearCase सिर्फ एक बात नहीं है जो आपको न कहता है। यह चींटियों से पीड़ित एक घर में रहने की तरह है प्रत्येक चींटी सिर्फ एक छोटी सी असुविधा होती है, परन्तु आप पागल हो जाते हैं।

मैं एक वास्तविक पोस्ट में कुछ टिप्पणियों को मजबूत करने की कोशिश कर रहा हूं। मैं वास्तव में यहाँ नहीं हूं कि आपको एक दूसरे के मुकाबले बेहतर करना है, कुछ बिंदुओं को बनाने के अलावा:

  • यदि आप git और ClearCase की तुलना कर रहे हैं, तो मैं सम्मानपूर्वक सबमिट करता हूं कि आपको अपनी आवश्यकताओं को बेहतर ढंग से परिभाषित करने की आवश्यकता है – अगर आप "अच्छे" कारण के लिए ClearCase पर विचार कर रहे हैं, तो git शायद समीकरण में भी नहीं है – यह विश्वास करने के लिए बहुत नया है एंटरप्राइज़ स्तरीय स्रोत नियंत्रण के लिए, आईएमओ
  • ClearCase संस्करण नियंत्रण स्थान में बहुत सारे अवधारणाओं को प्रस्तुत करता है जो अन्य सिस्टमों के पास नहीं है, इसलिए यह बहुत चुनौतीपूर्ण और भ्रामक हो सकता है। खासकर यदि आपके पास एकमात्र अनुभव है जो दस्तावेज़ीकरण पढ़ रहा है, जैसा कि कुछ लोगों के लिए मामला प्रतीत होता है
  • ClearCase निश्चित रूप से डेवलपर्स द्वारा समर्थित विशाल कोड अड्डों के लिए अनुकूल नहीं है जो एक VOB सर्वर के साथ लैन पर नहीं हैं। आप दूरस्थ डेवलपर्स के करीब पहुंचने के लिए कई प्रतिकृति (बहु-साइट) VOB सर्वरों को प्राप्त कर सकते हैं, लेकिन यह आवश्यक नहीं है कि यदि ये दूरस्थ साइटें केवल एक डेवलपर हैं
  • क्या आप फ़ाइल संस्करण या रिपॉज़िटरी संस्करण चाहते हैं? यह एक बहुत ही महत्वपूर्ण सवाल है, और जो कि आवश्यक रूप से उपकरणों का एक पूरा सेट बाहर कर देगा, जिससे आपका काम आसान हो जाएगा। रिपॉज़िटरी वर्जनिंग में कई फायदे हैं (और यह "नया" नहीं है, जैसे कुछ पोस्टर का दावा किया गया है – प्रबलबल जैसे वाणिज्यिक उपकरण एक दर्जन से ज्यादा वर्षों तक रहे हैं, और वहां ऐसे उपकरण हो सकते हैं जो प्रफोर्स से पहले भी रिपॉज़िटरी संस्करण थे), लेकिन यह एक रामबाण नहीं है
  • किसी भी स्रोत नियंत्रण प्रणाली की पर्याप्त रूप से बड़ी स्थापना के साथ, आपको सहायता की आवश्यकता होगी When considering tools, you need to consider how easy it will be to find people to help you (either job applicants who have experience, or consultants who will be there at a moments' notice to address any issues). There's no such thing as a maintenance-free SCM system, and assuming you have one will get you into more trouble than picking one that requires "too much" administration.
  • Don't pay too much attention to people who talk about how bad "dynamic views" are – bad SCM policies are bad, regardless of the tool you're using. Your configuration management policies and practices have to be separate from your choice of tool – no tool will stop people from smashing all over your codebase if you don't define sensible branching and merging policies. If someone suggests that having developers directly commit onto /main is ever a sensible idea, you might want to walk away from that conversation.

ClearCase is a fine tool, but it is a complicated tool. There is no getting around this – it does not have an "easy install" mode. 🙂 From a technical standpoint, there's nothing that git or SVN can do that ClearCase cannot (although often the terminology is different, since Open Source projects tend to just invent new taxonomy where there already existed one), but some things are definitely easier/harder for a given system, depending on their design. ClearCase "snapshot" views are basically the same thing you would have if you checked out a repository from SVN or CVS – it's a local copy of the source code on your machine, with pointers back into the central server for tools to query version history, etc. You can work with these views without any network connection to the ClearCase server at all once they have been created, and you can "recycle" them to avoid downloading your entire repository again when you want to move to work on another branch, for example. "Dynamic Views" are basically a ClearCase invention, and the standard operating mode for a LAN. They appear the same as checking out an SVN repository, but they don't actually copy any files until you make changes. In this way the view is available immediately, but it obviously cannot be worked with if the main clearcase server is unavailable, and is unpleasant to work with over a high-latency connection. They also have the convenience of being able to be mounted as a network drive on any machine with access to the server on which they were created, so if your windows workstation dies, you can just log onto another one, mount your view, and get back to work, since all the files are stored either in the VOB server (for files you haven't modified on this branch), or the view_server (for files you have created or modified just in this view).

Also, and this deserves its' own paragraph….clearmerge is nearly worth the price of admission alone. It's hands down the best merge tool that I've ever used in my life. I firmly believe a lot of bad practice in SCM has developed because of a lack of high-quality merge tools, so CVS users never learned to use branches properly and this fear of branching has propagated to the current day for no particularly good reason.

Ok, all that being said, if you're looking for reasons not to use ClearCase, they're not hard to find, although I think that's the wrong way to go about it. Really you should need to come up with good reasons TO use ClearCase, not reasons for NOT using ClearCase. You should come into any SCM situation assuming that ClearCase is too much tool or too complicated a tool for the job, and then see if you have some situation that encourages you to use it anyhow. Having IBM or Rational logos is not a good reason.. 🙂

I would not even consider ClearCase unless you could say yes to all the following statements:

  • You do now, or will eventually have, more than 50 developers working on the same codebase.
  • Most of those developers are centrally located, or have high-throughput low-latency connections to a central location.
  • You have a set of SCM policies and can identify how to use ClearCase to enforce those policies (really you should consider this for any tool)
  • Money really is no object

My experience is mostly limited by CC, CVS and SVN. In principle, CC is technologically capable, enterprise ready and comparable by features with any modern VCS. But it has several flaws that make it unusable in any people-oriented environment. For process oriented environments it is probably more appropriate, though I doubt that such environments are appropriate by themselves. Maybe, in military, cosmic or medical software, I don't know. Anyway, I believe that even for these domains there are appropriate and still more friendly tools.

Beside being technically capable VCS, CC has several distinctive advantages:

  • Dynamic views
  • Nice version tree
  • ट्रिगर
  • Good merge versioning, including renames

In my opinion, their use is limited excepting last one; and they don't compensate flaws. Dynamic view nice in theory, but not always available in practice. Version tree has much less use in other VCS, while necessary in CC because of proliferation of branches (see 6). Triggers, as I know, very detailed and capable, but I think that for most practical tasks SVN hooks are good enough. And now about disadvantages that mostly concerns usability:

  • CC totally fails in sense of usability for main user group: for developers. And that is the main reason why I think that it should never be used in any environment, be it enterprise or not. Even if it were free, it would nevertheless suck your company's money by wasting time of your developers and frustrating them. This point is composed from:
    1. "Check out-Check In" with strict locking approach – it is counter-productive, refactoring unfriendly, and dangerous in repository organizations with single development branch for multiple developers. Meanwhile, the advantages of strict locking are negligible.
    2. Poor performance and high load
    3. It effectively cannot be used remotely without multi-site (due to 2). Multisite is expensive too. ClearCase Remote client is very limited. It don't even have cleartool (before version 7.1), leaving alone dynamic views.
    4. It can hardly be used offline. Dynamic views are just not work. Snapshot views are effectively read only, because you cannot check out without access to repository (see 1). Hijack is poor option which in fact means that CC gives up any responsibility for hijacked file. And CC cannot show you difference with previous revision when offline. SVN is able to show difference with previous revision even being offline.
    5. Overly complicated model, especially with UCM: VOBs, PVOBs, Projects, streams, branches, views, deliver, update, load, restore, rebase, merge, baseline, check in, check out. I think that half of this concepts are just superfluous and doesn't add value, while increasing both technical and conceptual complexity. Few developers understand even basic stuff about CC.
    6. Proliferation of branches. For example, repository often organized with stream per developer (due to 1). It just has no sense in SVN or most other VCSs.
    7. No repository wide revisions. Well, there are such revisions as understand, they called baselines. But when I see some file revision and want to get repository snapshot at the moment of that file revision, I will get some problems. I will need to do black magic with config spec to create a snapshot view, or find somehow through dynamic view if it is available.
    8. Crappy user GUI. Version tree, even being nice, has mediocre usability. Merge tool is just a pity. Other "features": not resizeable windows, absence of incremental search in some places, mouse-centric interface, look and feel in 1995 style, strange work flow distributed between Client and Project Explorer etc.
    9. CC provokes rare and vast check ins. You all know, that check ins must be small and frequent. But developers usually refrains from additional interactions with CC, hijack files and work in local VCS or even without VCS at all (which is more often, unfortunately). And then, after two weeks of development they begin commit comlex feature that adds 20 files and affects another 20 files. It lasts for a day or two, because they hijacked files and now need to perform manual merge with all new changes from repo and resolve all conflicts and discrepancies. During that process, code lies not compilable, because several files successfully got checked in and others do not. And after that it still lies not compilable because they forgot to add another 2 files to CC.
  • It is very expensive
  • It is very complex in terms of infrastructure and requires dedicated administrators

ClearCase seems extremely powerful, from the outside. But really, it's just that the number of commands and options you need to use for basic workflow is so high that these get hidden behind a few aliases or scripts, and you end up with something less powerful than CVS, with the usability of Visual Source Safe. And any time you want to do something a little more complicated than your scripts allow, you get a sick feeling in your stomach.

Compare this with Git, which seems complicated from the outside, but after a week working with it you feel completely in control. The repository model is simple to understand, and incredibly powerful. Because it's easy to get at the nuts and bolts, it's actually enjoyable to dig below the surface of your daily workflow.

For example, figuring out a trivial task such as how to just view a non-HEAD version of a file in a snapshot view took me a couple of hours and what I ended up with was a complete hack . Not the enjoyable sort of hack either.

But in Git, figuring out a seemingly complicated task such as how to interactively commit only some changes, (and leave the rest for later) was great fun, and all the time I have the feeling that the VCS is allowing me to organise code and history in a way that suits me, rather than history being an accident of how we used the VCS. "Git means never having to say 'you should have'" .

At my work, I use Git for all sorts of lightweight tasks, even within ClearCase. For instance, I do TDD, and I commit to Git whenever a bunch of tests pass and I'm about to refactor. When the task's eventually done, I check in to ClearCase, and Git helps me review exactly what I'm changing. Just try to get ClearCase to produce a diff across a couple of files – it can't! Use Google to find out the various hacks people have tried to work around this. This is something version control should do out of the box, and it should be easy! CVS has had this for decades!

  • Nightmare to administer in secure environments
  • Outdated technology
  • Non-intuitive GUI
  • Expensive
  • Resource monster
  • Sellout to Microsoft

In my opinion? Only reason to have it? If you are religiously following RUP.

The support is terrible. We've had tickets open for years. Our eclipse guru actually fixed a bug in their eclipse plugin locally in about 30 minutes by disassembling the java file. But the ticket still hasn't got past level one support. Every so often they either try to sneakily close it or ping it back to us 'to try on the latest version' (even though we sent them a reproduction recipe which they could try for themselves.).

Do not touch with a barge pole.

प्रदर्शन।

ClearCase is powerful, stable (IF properly maintained and supervised) but it's slow. Geological sometimes.

Dynamic views views lead to horrible build times, snapshot views can take ages to update (lunch break for large projects) or checkout (go home for the day).

  • The developers will spend 1/2 their time figuring out clearcase before doing any work and once they've figured it out they'll install git locally and only push to the clearcase repo as needed.

  • You'll have to employ a dedicated Clearcase admin.

I would suggest SVN for toolset and Git for scaling/workflow. I'd also suggest avoiding CC where possible. (Not counting money, the fact it is such a pain to use that is requires a full time admin is a total joke)

I recently had to wrangle with a similar situation. Maybe you can learn from my story.

The team I was newly assigned to was using a heavyweight tool in an convoluted, error-prone manner. I first attempted to sell them on my tools and processes of choice. This attempt failed miserably. I was flabbergasted that they would pick such a burdensome environment over one that was both easier and more effective. Turns out that they wanted to be disciplined, and using a painful process felt disciplined to them. It sounds wierd, but it's true. They had a lot of other misconceptions too. After I figured out what they were after, we actually stuck with the same tool suite (Serena), but massively changed how it was configured.

My advice to you is to figure out what matters to your team. Ripping on ClearCase won't get you anywhere unless you speak to their interests. Also, find out why they don't want to use alternatives. Basically do a little requirements gathering and fit your tool choices to your needs. Depending on your options, who knows, Clear Case may end up being the best option after all.

I'm not totally against ClearCase ( it does have it's advantages ), but to list out the disadvantages:

  • License Limitations – I can't easily work from home, because I don't have access to the license server. Even with a snapshot view on my laptop I have to play tricks because I can't get a license. There is a special remote client, but adds tons of its own limitations to the mix
  • License Limitations again – Only so many seats to go around, and then no one can use it.
  • Unix tools out of date – ClearCase seems to run best on Unix systems, but the GUI tools suck there. Windows/Unix integration of ClearCase introduces all sorts of its own pains.

The biggest downfall for me is both the performance (especially if your VOB is multisite or offsite), and potentially lengthy downtimes.

If you're like me and work in a relatively small office as part of a large company (with no onsite IT), Clearcase servers going down can cost you the better part of a workday in non-productivity as well as getting the right people to get it fixed.

Bottom line, use it only if you really need it for what you are doing and make sure you have a beefy IT budget to maintain it.

ClearCase is perfectly usable if your willing to also use another version control system on top of it! personally I find using mercurial ontop of CC to work quite well.

  1. no atomic checkins

As of the new version of version 7.1 CC provides atomic checkin as functionality IF you like that. Personally I would really not want it but apparently some people see that as "an essential feature". I NEVER would want one big bulk in one go as a sort of massive version. Then again… if you want it just turn it on.

so… no longer an argument.

We used UCM ClearCase integrated with ClearQuest (DR Tracking/change request system) for the last 4 years with more than 50 developers. We have over 50 UCM projects over thousand of streams that handled over 35K DRs and change requests. During this period we have officially made over 600 integration deliveries and while having up to 6 concurrent development and release efforts.

I am the main CM/ClearCase guy with a backup who is able to perform the regular delivery/merge and integration builds. The network and servers are supported by the IT team. All I can say is we have had virtually no problems coming from the CM side of this huge development effort and were never a show stopper. Our developers where trained with just the basic stuff and a simple steps were given to them whenever a new project (branch) was created at the request from the project management.

Too many developer complained about ClearCase because they lack the proper CM/IT/ClearCase/Process/Management support. Developers should focus on development not SCM or be a tool specialist. For a large software development, at least 5-7% of the budget should be spent on CM and tool support.

Running a JDK from a VOB in Linux.

Try it, you need to play with the LD_PRELOAD variable (I know!)

the point of "it needs a dedicated person" and "it is complicated" etc….

The core issue here with finding this a problem is that you have to define if you want to have configuration management performed in your organization (which is NOT version management). Configuration Management is like Project Management: even without a tool you still can do project managment and without a tool you can do Configuration Management. Lots of people have a hard time understanding this and lots of people think Configuration Management is equal to a tool which versions sources of software or something…… (therefore comparisons with subversions or other VERSION management systems)

ClearCase is a solution that is build for usage in a Configuration Management environment ERGO: there is a configuration manager (just like "there is a project manager").

So… if in your perception that dedicated person is there to manage a tool I think there is something very wrong. In my perception there is a dedicated person who does configuration management who from an end-user perpective only shows up when there is a problem with the tool but regards this as only 1% of his job.

So what you need to do (like in any other software project) go back to your requirements and put a list of requirements together on what your organisation wants with configuration management. AND YES like in any other software project you will have users (like eg developers) who totally not agree with other users (like eg management) on certain requirements. There lies the key imho on some reactions I read here.

And IMHO if you have the organization list of requirements AND a configuration manager in the mix…. the choice is pretty clear (see also the forum on http://www.cmcrossroads.com)

ClearCase is not a tool only for end-users entering their sources under version control like subversion or git. That is only 1% of why a configuration manager really wants a mature configuration management tool.

And… I think the choice of a CM system should never lay with developers equal to choosing the right project management tool or the right CRM system. Developers are end-users of a certain part of the functionality of the tool.

I will be maybe alone here, but ClearCase is not that bad as everyone says. It can handle huge repositeories. Dynamic view are pretty cool and powerful feature too. It is reliable, can be customized by adding triggers and constraints on a pef file basis, permissions, etc.

Unfortunatelly, it comes with a price, big price. It is costly, and to operate properly needs to be properly configured and maintained by dedicated IT team. It makes it really good for BigCo, but not so wise choice for SmallFirm.

I'm a big fan of DVCS and git, but can understand why would BigCo choose ClearCase over SVN and Git. What I can't understand why would anyone choose SVN over Git ;>

Dynamic Views. Must admire a fully functional translucent file system.

One big benefit is that the Intellectual Property is always in the corporate network. A laptop can be lost/stolen and no source code in jeopardy.

Another is the instant access to source code and changed files, no time is ever spent downloading anything.

It serves well for the purpose it has.