ClearCase的优点/缺点

Question

因为我目前正在努力学习IBM Rational ClearCase,所以我想听听你的专业意见.

与其他版本控制系统(如Subversion或Git)相比,我对优缺点特别感兴趣.

Answer 1

您可以在我的答案中找到ClearCase和Git之间的良好比较:
" 每个开发人员应该知道的基本ClearCase概念是什么？ ",说明了一些主要差异(以及ClearCase的一些缺点)

以文件为中心的操作

ClearCase最重要的一个重要缺点是其旧的"以文件为中心 "的方法(与SVN或Git或Perforce中的" 存储库中心 "相反).
这意味着每个结帐或签入都是按文件完成的.操作的原子性在文件级别.
将它与非常详细的协议和可能在开发人员工作站和VOB服务器之间存在多个节点的网络相结合,您最终可能会得到一个相当慢且效率低下的文件服务器(ClearCase的核心).

每个文件的文件操作意味着:缓慢的递归操作(如递归检出或递归"添加到源代码控制",甚至通过clearfsimport).
必须使用快速LAN来减轻该繁琐协议的副作用.

集中式VCS

要考虑的另一个方面是它的集中方面(即使它可以通过其多站点复制的VOB功能"分发")
如果网络不允许访问VOB,开发人员可以:

• 仍在快照视图中工作(但仅限于被劫持的文件)
• 如果他们使用动态视图,请等待网络的恢复

昂贵的分布式VCS选项

您可以通过复制Vob来获得一些分布式VCS功能.
但:

• 您需要一种特殊的许可才能访问它.
• 许可证很昂贵,并增加了常规许可证的成本
• 任何使用复制的vob(vob,admin pvob,...)的vob也必须被复制(这意味着一些不直接与分布式开发有关的项目仍然需要支付多站点许可...)

旧的,不是用户友好的GUI

• GUI非常古老而且不切实际(90年代中期的MFC外观,完全同步的GUI,这意味着你必须等到刷新才能点击其他地方):浏览基线时,你无法快速查找.
• Unix上的GUI与Windows上的GUI完全不同(最新的7.1版本更好但还没有)
• 安装过程非常复杂(尽管CC7.1引入的最新安装程序管理器现在是Windows或Unix上的连贯GUI,并且确实简化了程序)
• 唯一真正丰富的应用程序只为CCRC(远程客户端)开发

UCM不一致和一致性

如" 如何利用ClearCase的功能 "中所述,动态视图非常棒(通过网络查看数据而无需将其复制到磁盘),但主要功能仍然是UCM:如果您拥有UCM,它可能是真正的资产复杂工作流程的大项目.

这方面的一些缺点:

• 对于深度优于一个的组件,组件之间的依赖关系管理不善(因为" 寄生虫基线 " 的错误)
• UCM仍然有一些coherencies和不一致性中记录CM十字路口

Base ClearCase的有限政策

在不使用UCM的情况下使用ClearCase意味着必须将策略定义为:

• 创建分支(否则任何人都可以创建任何分支,并最终得到它们的gazillon,合并工作流程的噩梦)
• 放标签(否则你忘记标记一些文件,或者你把标签放在你不应该的位置,或者你从一个版本"移动"(喘息)一个标签到另一个版本:至少UCM基线不能移动)
• 定义变更集.ChangeSets仅与UCM活动一起存在.使用Base ClearCase,您可以简化为" cleartool find"请求......

没有申请权

ClearCase权限管理完全建立在系统权限之上.
这意味着您需要将您的用户注册到正确的系统组,当您必须输入IT服务的票证以便他们进行正确的注册时,这并不总是很容易.
再加上异构环境(Windows上的用户和Unix上的服务器),您需要在Unix和Windows上注册您的用户!(使用相同的登录名/组名).除非你在两个世界之间放置某种LDAP对应关系(比如Centrify)

没有高级API

• 只有CLI完成(" cleartool"是ClearCase命令行界面),这意味着任何脚本(Perl或其他语言)都在解析这些cleartool命令的输出)
• ClearCase自动化库(CAL) 存在,但非常有限
• 存在Java API,但仅适用于CCRC客户端的Web视图.

查看存储不易集中/备份

View存储相当于SubVersion的".svn",例如,每个视图只有一个"视图存储",而不是SubVersion工作区的所有目录中的许多.svn.那很好.

不好的是,视图中的每个操作(简单的" ls",结账,检查......)都会触发对管理视图服务器的view_server进程的网络请求. 2个选项:

• 在您的工作站上声明您的视图存储:非常适合可扩展性,您可以根据需要拥有尽可能多的视图而不会对LAN造成负担:所有通信都直接在您的工作站上完成.但如果那台机器死在你身上,你就会失去意见.
• 在中央服务器上声明您的视图存储:这意味着将在那里创建所有view_server进程,并且任何用户对视图的所有操作都必须与该服务器通信.如果基础设施"正确"(特殊高速LAN,专用服务器,持续监控),则可以完成,但实际上,您的LAN不支持此模式.

第一种模式意味着:您必须自己备份正在进行的工作(私人文件或签出文件)
第二种模式意味着:您的工作站可以不可用,您只需登录另一个即可获取您的视图(execpt for private快照视图的文件)

关于动态视图的侧面讨论:

要添加到"动态视图"方面,它有一个优点(它是动态的)和一个缺点(它是动态的).
动态视图非常适合设置一个简单的环境,以便在一个小团队之间快速共享一个小型开发:对于一个小的开发工作,一个动态视图可以帮助2或3个开发人员不断地保持联系,在一个人的提交中断时立即看到其他观点中的一些东西. 对于更复杂的开发工作,快照视图提供的人工"隔离"是更可取的(只有当您刷新 - 或"更新" - 您的快照视图时才会看到更改) 对于真正不同的开发工作或过程,仍然需要一个分支来实现真正的代码隔离(在某些时候需要合并,ClearCase可以很好地处理,尽管文件很慢)

关键是,你可以使用两者,原因正确.

注意:小团队我不是指"小项目".ClearCase最适合用于大型项目,但如果要使用动态视图,则需要设置" 任务分支以隔离每个分支的小型开发工作:这样一个"小团队"(大团队的一个子集) )可以有效地工作,快速分享其成员之间的工作.
如果你在一个"主"分支上使用动态视图,每个人都在做什么,那么任何签到都会"杀了你",因为它可能会引入一些"构建中断"无关根据您当前的开发工作.
那将是对动态视图的不良使用,并且会忘记其他用法:

• 另外一种访问数据的方法,除了快照视图外,这意味着它是一个很好的工具来"看到"文件(例如,您可以使用动态视图来调整其配置规范,直到您看到您想要的内容然后复制那些选择规则到你通常的快照视图)
• 进行合并的侧视图:您使用快照视图,但对于合并,您可以使用动态"姐妹视图"("姐妹",如"相同的配置规范"),以避免合并失败,因为签出文件(您当前正在处理快照视图),或者因为快照视图不是完全最新的.合并完成后,您将更新常规快照视图并恢复工作.

直接在动态视图中开发并不总是最佳选择,因为所有(未签出)文件都是通过网络读取的.
这意味着您的IDE所需的DLL或jar或exe将通过网络访问,这可能会大大减慢编译过程.
可能的解决方案:

• 包含所有内容的一个快照视图
• 带有dll或jar或exe的快照视图(每五分钟不更改一次的文件:每天一次更新),以及只有源可见的动态视图.

Answer 2

成本是一个相当明显的劣势.不仅是许可证成本,还包括ClearCase大师的工资成本.我所知道的几乎所有使用ClearCase的公司似乎至少有一个人的唯一目的是驯服不守规矩的野兽.

事实上,它足够复杂,需要一名全职保姆也令人担忧.

Answer 3

系统的绝对噩梦.它让我希望我们可以回到VSS!(别担心像Subversion或Git这样的现代源代码控制系统!)

• 这是懒散的.
• 如果您使用动态视图并且网络出现故障,则无法访问源的工作副本.你什么都不做,只能等待它修复.
• 如果您使用快照视图,您似乎一直遇到冲突和"劫持"文件,因此工作副本中的文件永远不会与源存储库中的文件完全相同.
• 每当您尝试大型更新或交付操作时,由于某种原因,它总是 失败,需要您的ClearCase专家花费几个小时/天来计算它.哦,是的,你必须有一个专职的全职ClearCase大师!
• 当它失败时,您通常也无法回滚操作,因此您仍然遇到正在进行的操作并且开发人员被阻止.
• 当您浏览漂亮的(？)图标时,GUI非常差 - 直到无法调整窗口大小以查看完整文件路径的情况!
• 他们的支持人员非常不愿意解决任何问题.他们的第一反应总是" 这是设计 "和"你可以解决它吗？" 如果他们最终提供了一个解决方案(经过多次争论),它将成为最直接问题的最基本的可能解决方案.

基本上,它是缓慢,复杂和不可靠的地狱.哦,我提到它的价格非常贵吗？他们可能出售的唯一方法是与从未使用过该产品的决策者交谈,永远不会!我很确定世界上没有开发商会买它.

Answer 4

原子提交和变更集是我对ClearCase最大的抱怨.假设你签入了五个文件,作为错误修复或重构的一部分.然后发现有些东西搞砸了,你需要还原.祝你好运,找到它们的五个文件以及每个文件需要的版本.但让我们退后一步.您刚刚完成了对这五个文件的编辑,是时候提交了.前四个通过就好了.最后一个需要大规模合并.其他四个文件已经签入.他们不会等你在最后一个文件中完成必要的更改.我当然希望没有人更新或使用动态视图.持续集成构建服务器也将失败.

有时我们会创建一个完整的新目录,其中包含需要签​​入的文件,但我们不希望在完成之前检查它们.这是早期的,一切都仍然不稳定,那么为什么要检查一下你可能会很快删除？好的,到目前为止很好.现在是时候办理登机手续了.您将新创建的文件夹添加到源代码管理中.嗯,ClearCase是不是递归的,因此只有一个文件夹中的检查.使用SVN,该文件夹及以下的所有内容都添加,任您选择.开发人员需要记住添加所有内容,否则会丢失大量文件.

ClearCase拥有文件和文件夹,因此除非您先检查过,否则无法修改任何内容.eclipse插件在这里消除了很多麻烦.我无法告诉你有多少次我在vi中打开一个文件进行快速更改,却发现我忘了先检查一下.结帐也不是递归的.

没有变更集,更新可能会非常缓慢.使用快照视图进行更新时,每个文件都会更新,而不仅仅是已修改的文件.我参与了一个包含20,000多个文件的项目.我会远程到我的工作机器,开始更新,然后开车上班; 喝咖啡; 在它结束时去我的办公桌.这可能听起来有些夸张,但遗憾的是并非如此.

除非你是一个非常小的团队,否则动态视图很糟糕.如果是这样的话,为什么你甚至有ClearCase？我看到无数人的观点变得模糊,因为有人检查了文件,打破了其他人的意见.您应该始终更新并合并您自己视图上的任何冲突.这样,更改只会影响您.使用动态视图,在推回之前无法合并; 你只是承诺并希望.

我知道成本可能不是一个大问题,但为公司赚钱的开发商将喜欢花费5万至10万美元(取决于ClearQuest许可证,这是常见的补充),无论是有趣的活动还是新设备(椅子,监视器等).IBM建议让员工继续使用ClearCase.为什么不重新利用这些人为公司创收,而不是确保事情不会崩溃和燃烧？

我听说过没有切换的一些原因:

• 学习需要时间和金钱
  • 学习SVN或Mercurial应该不超过一天.只有ClearCase建议给开发人员一定比例的管理员.
• 迁移将是痛苦的
  • 这就是工具存在的原因:cc2svn
  • Mercurial并不那么容易
• 安全
  • SVN AFAIK中没有已知的漏洞,开发团队致力于修复任何快速发现的内容.SVN对国防部似乎没问题.
• 之后没有真正的生产力增长
  • 它需要永远尝试在没有变更集的情况下追踪错误.我喜欢能够回滚,直到我看不到这个错误.你不能在ClearCase中做到这一点.
• 多站点
  • WANdisco解决了这个问题.但它不是免费的.

ClearCase唯一比其他文件做得更好的是分支单个文件,同时保持其他文件与另一个分支在同一轨道上.

Answer 5

我在Clearcase所做的一切似乎总是很难.然而,我从未对其他系统产生这种印象(有时可能除了CVS).

我使用过SVN,CVS,Clearcase和Mercurial.

Answer 6

我对ClearCase的体验是一场灾难,我将在Don的声明中说它需要一位常驻专家 - 不幸的是我们不止一次.我有CVS和其他版本控制系统的经验,我熟悉这些概念,但我发现ClearCase文档难以理解,不得不多次寻求帮助; 不同的专家给了我相反的建议,我们实际上打破了cd.也就是说,在UNIX shell中发出ClearCase命令后,"cd"命令失败并显示错误消息.

版本控制系统的基本任务非常简单.老实说,我认为六个命令就足够了,使用的文件方案可以很好地与其他人一起使用.对我来说,ClearCase看起来像是营销执行官故意使事情变得复杂化的结果,使产品看起来更加精致和强大.我听说它可以被配置为以简单,安全,可靠的方式运行,但同样需要专家的服务 - 开箱即用它就像一个机动的瑞士军刀.

Answer 7

我所经历的任何与ClearCase有关的东西都是低效,丑陋,过于复杂,缓慢,混乱,昂贵和不方便的.

它似乎吸引了管理人员和工程师,他们都错了.

该死的,IBM和Rational必须有出色的销售人员来销售这样一个糟糕的产品.

Answer 8

由于这里给出的许多原因,我们只是将CC迁移到Git上.我想补充一个理由,远离CC或任何其他商业源控制系统.

您的重要业务数据是ClearCase的人质.你无法解决它.

您的重要业务数据是代码,其版本历史记录以及所有元数据,例如提交注释,签入时以及何时签入.

所有软件的使用寿命都有限.当您引入一个吞噬重要业务数据的新系统时,您应该总是问自己,无论是代码,错误,客户数据还是什么不是:我如何再次获取数据？如果您无法回答该问题,则不应引入该系统.

当我们迁出时,我们失去了大部分历史和所有元数据.基本上我们只有与发布版本相对应的历史记录,但是有关为响应客户请求丢失而做了哪些更改的信息(我们在客户支持和错误票证系统中有这些数据,所以它并没有完全丢失,而是耦合到源代码消失了).

在短期到中期内,这将介于我们的麻烦和问题之间.在几年的时间里,它已经不重要了,但也许1到3年就很重要了.

(有一些商业工具可以将CC迁移到其他SCM,但它们并不足以满足我们的需求,我怀疑它是否可行.我们做的最小出口需要足够长的时间.)

吸取的教训是:永远不要将重要的业务数据委托给专有系统.

Answer 9

没有原子提交

签入文件后,很难恢复到某个状态,因为不支持原子提交.签入多个文件时,每个文件都会获得一个新版本(类似于CVS),而不是签入本身.我认为这是一个至关重要的功能,因为您几乎不想恢复单个文件,而是完成提交操作(应该映射任务).使用ClearCase,您只能使用标签恢复到某些状态.实际上,使用ClearCase标签进行每次登记都是过度杀伤,因此没有完成.

糟糕的用户界面

ClearCase Explorer的GUI只是个大笑话.糟糕的可用性和难看的外观.不提供不同且通常必需的功能(例如,递归地检查工件上的工件).与cygwin一起使用的命令行工具cleartool要好得多,但仍有一些东西不可用,比如递归添加新文件/文件夹到源代码控制.如果我读了50行代码长脚本来解决这个问题,我不得不大笑.

高度管理

管理ClearCase野兽远非明显或轻量级(与CVS,颠覆或Git等其他scm系统不同).预计会有相当多的专业ClearCase专家让它继续运行.

可怕的表现

没有什么比让你的开发人员在与SCM工具接口时等待更糟的了,就像开启手刹一样.它会减慢你的大脑和你的工作.将新鲜文件添加到快照视图大约需要30分钟才能获得10K工件.相同数量的更新(没有更改工件)大约需要5分钟.在进行大量实验并在不同的最新视图之间跳转意味着需要等待很多时间.更糟糕的是,当您处理文件并且想要签入或更新它们时.签出,签到和添加源控制周期大约需要10-15秒,这显然是一场噩梦.当您重构重命名/移动类型或方法(许多文件可能受到影响)时,它会变得非常烦人.

缺乏对分布式开发的支持

今天,软件开发通常是分布式的东西(开发人员遍布世界各地,在同一产品/项目上工作).ClearCase definetely不适用于此,因为它非常适合离线工作.执行签出(在编辑文件/文件夹之前执行操作)需要您进行网络连接.在这里你可以使用劫持选项,但这是一个解决方法作为一个功能(你基本上只是解锁文件系统上的文件).如果您的开发站点远离ClearCase服务器,则签入/签出延迟甚至会大幅增加,根本无法使用.有一些解决方法就像使用ClearCase Multisite(scm DB副本技术),但你必须支付额外的费用,并且管理起来并不容易.

Git是另类

虽然作为开源的忠实粉丝+支持者,我仍然愿意花钱买好软件.但是看看IBM怪物ClearCase我不会在这里投入资金,它有所有这些讨论的缺点,而且IBM似乎并没有投入大量资金来显着改善他们的产品.最近我看了一个看起来非常好的Git scm,特别是它的分支+合并功能,其中ClearCase有其主要优势.

此信息来自http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/

Answer 10

可能是有史以来最糟糕的软件.我不会为任何使用理性的公司工作.除了CC在动态构建中经常崩溃并重新启动我的工作站.当你推动某些东西来源控制而CC会做它最擅长的事情时会发生什么,崩溃？你的代码然后被丢失+发现,可能在某处备份吗？不,它永远消失了.因此,如果您处于使用这一大型昂贵软件的可怕情况,请保留所有内容的重复.干得好Rational/IBM.捕获源控制最重要部分的方法,可靠性.死得慢.

Answer 11

ClearCase的缺点 - 这里增加了最深入的帖子.

1. 合并工具不值得.它几乎没有帮助你,记得你做出的任何决定,它只是一个美化的差异.

2. 如果需要合并,合并工具必须检查目录甚至CHECK.它有点疯狂.

3. 我在工作中使用BitKeeper(让我们假设Git),并且即使存在冲突也合并两个存储库即使使用命令行也是如此微不足道和用户友好,而具有大量GUI工具的ClearCase是一个漫长且费力的过程,也非常容易出错.

4. 所有GUI工具都需要大量的延迟.即使看到可以对文件执行的操作也需要高速连接.因此,在家中工作的文件上右键单击ClearCase工具可能需要一两分钟的高速互联网,因为网络要求极高.

5. 如果他们的视图规格与团队不同,有人可能会完全搞乱存储库或签到.对于没有人可以查看某个分支而言,这是非常疯狂的; 他们需要适当的视图规范,偶然会给他们正确的东西.整个概念可以很好而且灵活,但99%的时间只会造成很多痛苦.我提到你不能通过Microsoft Outlook发送你的规范,因为CC工具不接受UTF-8所以你不能复制粘贴吗？

6. 我对CC 完全没什么好说的.我在2家公司使用了2年,并且在整个时间内心情愉快地放弃了它.在家里尝试自己的项目也是不可能的,所以你仍然会在家里学习SVN或Git,并被迫在工作中经历ClearCase的痛苦.我认识的任何人都没有自愿使用过CC.他们只使用它,因为一些工作经理决定CC是救赎之路,并迫使每个人都迁移到它.事实上,我的最后一家公司从CVS迁移到了ClearCase,一年后从ClearCase迁移到了SVN.这是令人痛恨的.

7. ClearCase不只是让你说不的一件事.就像生活在充满蚂蚁的房子里一样.每只蚂蚁充其量只是一个小小的不便,但感染会让你发疯.

Answer 12

我想在这里将一些评论合并到一个实际的帖子中.我不是真的在这里说服你,一个比另一个更好,除了提出几点:

• 如果您正在比较git和ClearCase,我谨慎地提出您需要更好地定义您的需求 - 如果您考虑ClearCase是出于"好"的原因,那么git可能甚至不在等式中 - 它太新了,无法信任对于企业级源代码控制,imo.
• ClearCase将许多概念引入到其他系统所没有的版本控制空间中,因此它可能非常令人生畏和混乱.特别是如果你唯一的经验是阅读文档,就像这里的一些人的情况一样.
• ClearCase绝对不适合开发人员支持的庞大代码库,这些开发人员不在具有VOB服务器的LAN上.您可以拥有许多复制(多站点)VOB服务器,以使它们与远程开发人员保持密切联系,但如果这些远程站点只是一个开发人员,则这不一定实用.
• 您想要文件版本控制还是存储库版本控制？这是一个非常重要的问题,必须过滤掉整套工具,使您的工作更轻松.存储库版本控制具有很多优点(并且它不是"新的",就像一些海报所宣称的那样 - 像Perforce这样的商业工具已经存在了十几年,而且可能有工具甚至在Perforce之前就进行了存储库版本控制),但是它不是灵丹妙药.
• 通过足够大的任何源控制系统安装,您将需要帮助.在考虑工具时,您需要考虑找人帮助您是多么容易(有经验的求职者,或者会立即通知他们以解决任何问题的顾问).没有免维护的SCM系统这样的东西,假设你有一个会让你遇到麻烦,而不是选择一个需要"太多"管理的系统.
• 不要过多关注那些谈论"动态视图"有多糟糕的人 - 不管你使用什么工具,糟糕的SCM政策都是不好的.您的配置管理策略和实践必须与您选择的工具分开 - 如果您没有定义明智的分支和合并策略,那么任何工具都不会阻止人们粉碎您的代码库.如果有人建议开发人员直接提交/ main是一个明智的想法,你可能想要离开那个对话.

ClearCase是一个很好的工具,但它是一个复杂的工具.没有解决这个问题 - 它没有"简易安装"模式.:-)从技术的角度来看,没有什么git或SVN可以做到ClearCase不能做的事情(尽管通常术语不同,因为开源项目往往只是发明了已经存在的新分类法),但有些事情肯定更容易/给定系统更难,取决于他们的设计.ClearCase"快照"视图与从SVN或CVS检出存储库时基本相同 - 它是您机器上源代码的本地副本,指针返回中央服务器以查询版本历史记录的工具,等.一旦创建了ClearCase服务器,您就可以使用这些视图而无需任何网络连接,并且您可以"回收"它们以避免在您想要移动到另一个分支上时再次下载整个存储库,例."动态视图"基本上是一个ClearCase发明,以及LAN的标准操作模式.它们看起来与签出SVN存储库相同,但在您进行更改之前它们实际上并不复制任何文件.通过这种方式,视图立即可用,但如果主clearcase服务器不可用,则显然无法使用该视图,并且在高延迟连接上工作时很不愉快.它们还具有在任何可以访问创建它们的服务器的计算机上作为网络驱动器安装的便利性,因此如果您的Windows工作站死亡,您只需登录另一个,安装视图,然后获取恢复工作,因为所有文件都存储在VOB服务器中(对于您未在此分支上修改的文件)或view_server(对于您在此视图中创建或修改的文件).

此外,这应该是它自己的段落.... clearmerge几乎值得入场的价格.它是我生命中曾经使用过的最好的合并工具.由于缺乏高质量的合并工具,我坚信SCM中的许多不良做法已经发展,因此CVS用户从未学会正确使用分支,这种对分支的恐惧已经传播到当前,没有特别好的理由.

好的,所有这一切,如果你正在寻找不使用ClearCase的理由,他们不难找到,虽然我认为这是错误的方式去做.真的,您应该提出使用ClearCase的充分理由,而不是使用ClearCase的原因.你应该进入任何SCM情况,假设ClearCase是太多的工具或太复杂的工具,然后看看你是否有某种情况鼓励你无论如何使用它.拥有IBM或Rational徽标不是一个很好的理由.. :-)

我甚至不会考虑使用ClearCase,除非您对以下所有陈述都说"是":

• 您现在或将最终有50多名开发人员在同一代码库上工作.
• 大多数开发人员位于中心位置,或者具有到中心位置的高吞吐量低延迟连接.
• 您有一组SCM策略,可以确定如何使用ClearCase来实施这些策略(实际上您应该考虑使用任何工具)
• 金钱真的不是对象

Answer 13

我的经验主要受CC,CVS和SVN的限制.原则上,CC具有技术能力,企业就绪,可与任何现代VCS相媲美.但它有几个缺陷,使其无法在任何以人为本的环境中使用.对于面向流程的环境,它可能更合适,但我怀疑这样的环境本身是合适的.也许,在军事,宇宙或医疗软件中,我不知道.无论如何,我相信即使对于这些领域,也有适当的,更友好的工具.

除了技术上有能力的VCS,CC还有几个独特的优势:

• 动态视图
• 好版本树
• 触发器
• 良好的合并版本控制,包括重命名

在我看来,他们的使用是有限的,除了最后一个; 他们不补偿缺陷.动态视图在理论上很好,但在实践中并不总是可用.版本树在其他VCS中的使用要少得多,而在CC中由于分支的扩散而必需(见6).据我所知,触发器非常详细和有能力,但我认为对于大多数实际任务而言,SVN钩子已经足够好了.现在主要关注可用性的缺点:

• CC对于主要用户群的可用性完全失败:对于开发人员.这就是我认为它永远不应该在任何环境中使用的主要原因,无论是企业还是非企业.即使它是免费的,但它会浪费你公司的钱,浪费你的开发人员的时间并使他们感到沮丧.这一点由以下内容组成:
  1. 使用严格的锁定方法"检查 - 检入" - 它会适得其反,重构不友好,并且对于具有针对多个开发人员的单一开发分支的存储库组织而言是危险的.同时,严格锁定的优点可以忽略不计.
  2. 性能差,负载高
  3. 没有多站点,它实际上不能远程使用(由于2).多站点也很昂贵.ClearCase Remote客户端非常有限.它甚至没有cleartool(在版本7.1之前),只留下动态视图.
  4. 它几乎不能脱机使用.动态视图不起作用.快照视图实际上是只读的,因为如果没有访问存储库就无法签出(参见1).劫持是一个糟糕的选择,实际上这意味着CC放弃了对被劫持文件的任何责任.当离线时,CC无法显示与先前版本的差异.即使离线,SVN也能够显示与先前版本的差异.
  5. 过于复杂的模型,特别是UCM:VOB,PVOB,项目,流,分支,视图,交付,更新,加载,恢复,rebase,合并,基线,签入,签出.我认为这一概念中有一半是多余的,并没有增加价值,同时增加了技术和概念的复杂性.很少有开发人员了解关于CC的基本知识.
  6. 分支机构的扩散.例如,存储库通常按每个开发人员的流组织(由于1).它在SVN或大多数其他VCS中没有任何意义.
  7. 没有广泛的版本库.嗯,有这样的修改,他们称之为基线.但是当我看到一些文件修订版并希望在该文件修订版本时获得存储库快照时,我会遇到一些问题.我将需要使用配置规范进行黑魔法来创建快照视图,或者通过动态视图以某种方式查找它是否可用.
  8. 糟糕的用户GUI.版本树,即使很好,也具有平庸的可用性.合并工具真可惜.其他"功能":不可调整窗口,某些地方没有增量搜索,鼠标中心界面,1995年风格的外观,客户端和项目浏览器之间分配的奇怪工作流程等.
  9. CC引发了罕见而广泛的检查.众所周知,检查必须小而频繁.但开发人员通常会避免与CC进行额外的交互,劫持文件并在本地VCS中工作,甚至根本不使用VCS(不幸的是,更常见).然后,经过两周的开发,他们开始提交comlex功能,添加20个文件并影响另外20个文件.它会持续一两天,因为它们劫持了文件,现在需要手动合并来自repo的所有新更改并解决所有冲突和差异.在此过程中,代码不可编译,因为几个文件已成功检入,而其他文件则没有.之后它仍然无法编译,因为他们忘了向CC添加另外两个文件.
• 这非常贵
• 它在基础设施方面非常复杂,需要专门的管理员

Answer 14

ClearCase从外部看起来非常强大.但实际上,只需要为基本工作流程使用的命令和选项的数量如此之高以至于它们隐藏在一些别名或脚本背后,并且最终得到的功能不如CVS,具有Visual Source的可用性安全.任何时候你想要做一些比你的脚本允许更复杂的事情,你的胃就会感到恶心.

与Git相比,Git从外面看起来很复杂,但经过一周的工作后,你感觉完全掌控了.存储库模型易于理解,并且非常强大.因为它很容易获得螺母和螺栓,所以在日常工作流程的表面下挖掘实际上是非常有趣的.

例如,找出一个简单的任务,例如如何在快照视图中查看文件的非HEAD版本花了我几个小时,我最终得到的是一个完整的黑客.不是那种令人愉快的黑客行为.

但在Git中,找出一个看似复杂的任务,比如如何交互式地只提交一些更改,(以及以后留待其余部分)非常有趣,而且我总觉得VCS允许我组织代码和历史以适合我的方式,而不是历史是我们如何使用VCS的意外."Git意味着永远不必说'你应该'."

在我的工作中,我使用Git进行各种轻量级任务,即使在ClearCase中也是如此.例如,我做TDD,每当一堆测试通过并且我即将重构时,我就会承诺使用Git.当任务最终完成时,我会检查ClearCase,Git帮我查看我正在改变的内容.试着让ClearCase在几个文件中产生差异 - 它不能!使用谷歌找出人们试图解决的各种黑客攻击.这是版本控制应该开箱即用的东西,应该很容易!几十年来CVS已经有了这个!

Answer 15

• 在安全的环境中管理的梦魇
• 过时的技术
• 非直观的GUI
• 昂贵
• 资源怪物
• 卖给微软

在我看来？只有理由拥有它？如果你虔诚地遵循RUP.

Answer 16

支持很糟糕.我们已经开了多年票.我们的eclipse大师实际上通过反汇编java文件在大约30分钟内修复了他们的eclipse插件中的错误.但是机票还没有超过一级支持.每隔一段时间他们就会试图偷偷地将它关闭或者回到我们面前"试试最新版本"(即使我们给他们发送了一个可以自己尝试的复制配方).

不要用驳船杆接触.

Answer 17

性能.

ClearCase功能强大,稳定(IF维护和监督),但速度很慢.有时地质.

动态视图视图导致可怕的构建时间,快照视图可能需要很长时间才能更新(大型项目的午休时间)或结帐(当天回家).