ClearCase适合我们的开发过程吗?

首先,您可以阅读一些关于ClearCase的文章:

• What are the basic clearcase concepts every developer should know?
• How to Leverage Clearcase’s features
• ClearCase advantages/disadvantages

现在:

• CCRC表示“Web视图”,即ClearCase专用Web服务器上的快照视图…你最好在桌面和服务器之间有一个好的局域网。

• 分支是ClearCase中的头等公民,这意味着一个给定的ClearCase视图(这里是一个快照CCWeb视图)只允许您访问一个分支。如果习惯于同时处理多个分支,则需要多个视图。

• 所有操作都是按文件进行的,因此在私有分支上工作,然后合并的想法很麻烦,因为涉及到的合并的数量很多。
  我强烈建议在 常见的 几个开发人员想要解决的特定开发工作的分支。
  如果他们想要私有的分支和沙盒,他们可以设置一个 Git view within their ClearCase view 没问题。
  (注意:不能将快照视图视为沙盒:签入文件时,其他开发人员在更新其快照视图时将看到您的更改)

• 这个 ClearCase Eclipse plugin 支持重构。

• 在ClearCase中,除了通过链接之外,实际上不支持svn:external的概念。或者通过UCM基线依赖。
  应该注意,使用二进制依赖项比使用源依赖项更容易:如果您的外部是为了包含下一个项目的数千个源文件,那么在ClearCase中会比较麻烦(由于更新时间长)。如果您包含一些JAR或DLL,那就快得多(加上那些是将实际部署的JAR或DLL)。

• 如果使用UCM,则无法将代码从一个组件移动到另一个组件。你必须 clearfsimport 新标识的“通用”组件中的主要标签。

• 注:rcs关键字替换为 generally considered... evil ;)我建议使用单独的文本文件,其中包含相关重要文件的版本或标签。对于交付材料,而不是源文件,这样做很好。

在我看来,CC是 坏的 敏捷团队的选择。原则上,你可以用它工作,但你不可避免地会在某种程度上失去工作效率。这个学位的多少取决于你的CC管理员有多好和有多同情。他们必须清楚地了解开发团队的需求。

在我们的团队中,CC的情况非常糟糕。我们的管理员是远程的,与团队的其他成员隔离,因此我们被迫通过邮件和请求跟踪程序与他们进行通信。你可以想象需要多少时间。由于这个过程的开销和复杂性,我们无法升级到最新的CC版本(我想还有一些管理负担)。因此,我们使用7.0版本的CC/CCRC。

这个版本的CCRC完全不好用。不能轻易地用它重构。不能与它执行任意合并。无法创建基线。您甚至不能将文件放入忽略列表。顺便说一下,据我所知,CC只支持后一个CCRC版本中的被忽略文件,而不支持本机CC客户机中的被忽略文件。我们的CCRC版本根本没有命令行接口。

CC高度依赖于服务器通信,因此当开发人员试图离线工作时,CC(和CCRC)会自行离开。没有CCRC或远程桌面,CC repo无法远程使用(鼠标单击响应时间为分钟)。

CC会干扰其他工具,因为它将所有文件标记为只读,并要求在修改之前显式签出这些文件。所以,有了Eclipse插件,您就可以重构了。但是用任何其他工具你都不走运。您需要先签出文件,或者强制修改文件,从而将其变为被劫持的文件。如果您使用其他的IDE、SED或awk脚本或类似的脚本,就会出现问题。即使只使用Eclipse,涉及CC的操作(这意味着所有重命名重构等)也很慢,因为CC很慢。

CC唯一的优点是它擅长合并和合并跟踪。但是,颠覆1.5已经接近了这一点。不管怎样,它并没有说服我使用CC。

我承认我尖锐的否定意见主要是由我个人的不良经历形成的。但我敢保证,即使在完美流程和管理的理想CC设置中,您的生产效率也会受到影响。这是因为CC过度依赖服务器,并且使用严格的锁定方法“签出签入”。它提供了一些“解决办法”(我宁愿称它们为kludges),比如无保留退房和被劫持状态,但它们添加了自己的问题。CC总是站在你和你的代码之间。

顺便说一下,我想IBMRational迟早会把客户转移到 Jazz platform . 它理性的团队合作是“敏捷的味道”。它有10个开发人员的免费版本和一些与CC的集成(但不确定它是否也是免费的)。所以你可以试试。不过,我不相信任何来自IBMRational的好消息。

ClearCase的问题是:

ClearCase创建于20世纪90年代,当时桌面系统上的工作站甚至可能没有磁盘驱动器——更不用说空间了。另外,您的桌面系统可能内存有限且速度慢。

ClearCase是一个很好的答案。视图可以位于视图服务器上。VOB位于VOB服务器上。快速、快速、快速的专用机器。

ClearCase有派生的对象 眨眼 而不是让缓慢的机器尝试编译代码。真节省时间!

而且,ClearCase的VOB结构意味着您可以做一些版本控制系统无法做到的事情。例如,您可以 cd 如果附加 @@ 关于名字。这允许您查看该文件的所有分支、标记和所有版本。您可以简单地运行标准的Unix工具来搜索差异等。

然后,世界发生了变化:

• 桌面系统变得更加强大。您拥有磁盘空间、内存和原始处理能力。在本地驱动器上创建一个签出工作区(当然您也有一个),意味着您不必依赖于随着越来越多的网络进程出现而变慢的网络。在派生对象中传情动漫?嘿,我的机器制造吸盘的速度比ClearCase找到一个合适的派生对象快五倍。

• 窗户。ClearCase的设计考虑到了Unix。钩子可以在本地系统上运行,因为每个人的桌面上都安装了Perl,您可以很容易地确保它们都处于同一版本。你可以安装一个nfs/usr/local目录(我知道,但是联网了 local 目录是常见的),使用正确版本的Perl或安装的任何东西,您的钩子都可以工作。窗户开得不太好。钩子让人头疼。

• Windows:ClearCase依赖于Unix工具才能正常工作。窗户没有。

• 敏捷开发:开发ClearCase时,开发模型是将开发人员彼此隔离的模型之一。如果不经常担心其他开发人员对您的系统进行更改,您可以更快地工作。在ClearCase中,分支很容易。你可以给每个人一个他们自己的分支,然后他们可以在完成后合并回主分支。前后合并!在ClearCase中很容易。哎呀,UCM是建立在这个基础之上的。不幸的是,这项战略需要完全的纪律。您必须不断提醒开发人员合并代码,以便其他开发人员可以看到它们。在发布之前,不可避免地出现了合并危机,因为许多开发人员都试图将他们的更改合并回集成分支。敏捷开发消除了开发人员隔离的概念。你做了一些小的改变,并跟踪别人在做什么。因此,奥普拉分支的概念(你得到一个分支!你有一根树枝!每个人都有一个分支!)不再使用。

• 所以,现在您有了一个具有大量磁盘空间和内存的快速系统。您可以同时进行三到四次单独的退房。动态视图的优势并没有简单地克服它的缺点,即速度慢和网络密集。快照视图有帮助,但它们删除了以前的所有ClearCase魔力。换言之,为什么要使用一个像ClearCase那样大和笨重的系统,就像它是cvs一样,而您首先只需使用cvs?

• 最后,ClearCase很难实现。早在开发人员都是系统和网络专家的旧时代,学习ClearCase的进进出出是可以预料的。提出观点并不比学习yacc语法困难。然而,开发人员并不像以前那样精通系统。为什么要这样?你不需要知道内存是如何工作的,以便用Java或C语言编程。开发人员不再想学习大约100种不同的工具来完成他们的工作。ClearCase培训可能需要几天时间,学习ClearCase的进进出出可能需要几周时间。在ClearCase中,我必须理解视图语法,才能做一些简单的事情,比如修改分支上的代码。对于cvs,它只是一个命令。

ClearCase过于复杂、缓慢和昂贵。而且,其中很大一部分是阿特丽亚在建造ClearCase时所下的赌注:1)。开发人员愿意学习它,因为无论如何他们必须学习100个其他工具。2)。与网络服务器相比,您的台式机既慢又小。“在云中”做任何事情都更快。3)。ClearCase集中功能是公司的一大优势,因为一个站点可以管理和支持所有内容。

所有这三个假设都是错误的,因此,越来越少的公司甚至在考虑ClearCase。也许早在Rational收购Pureatria的时候,如果Rational将其带入21世纪,使其变得更小、更轻、更便宜,它可能仍然是一种广泛使用的工具。但是,Rational过于忙碌,使得开发变得更加复杂,以便将他们购买的所有漂亮工具集成到一个集中的开发过程中。当IBM收购Rational时,ClearCase已经开始让用户流血。

Gizmo

除了从另一个角度来看之外,我目前正面临与您相同的问题——我是一个ClearCase管理员,试图将一个团队从SVN迁移到ClearCase。

CCRC正在被吹捧为开发Java的工具。我不完全确定我相信-ccrc(ClearCaseRemoteClient)的设计目的是帮助开发人员从主要基础设施进行远程工作。为了帮助提高访问速度,代码被保存到桌面上——但是签入和签出的开销是不可忽略的。

从技术上讲,重构在CCRC中是可能的,但是如果与基础结构断开连接,就不可能进行重构——该工具不会允许您这样做。

Eclipse工作区与CCRC视图很好地配合还存在其他问题-您可能(取决于环境的分支结构)在工具的绝对路径名方面存在问题。

需要记住的一点是,ClearCase确实可以实现普通的快照视图,而且可能需要深入研究。我不同意VonC(也许是有史以来第一次,他是一个Heluuva管理员),因为我相信CCRC视图(称为Web视图)与本地快照视图截然不同,这允许您在一个更像VPN的环境中开发——特别是如果您要做Java开发的话。

至于ClearCase和Hudson,我已经和AndrewBayer谈过了,让ClearCase插件在动态视图中更容易工作——动态视图在0.9版本中起作用。他是哈德逊社区的活跃成员,所以如果你对插件有问题,提出的问题应该很快得到解决。

不过,我能给出的最大建议是,仅仅因为情况不同,并不意味着情况更糟。耐心一点,如果您阅读文档并花时间的话,ClearCase会给您提供令人惊讶的控制级别。

祝你好运!

斯图尔特

ClearCase是一个功能强大的软件配置管理工具,您概述为日常活动的大部分内容都可以通过ClearCase实现。

ClearCase的视图概念类似于您提到的沙盒。 有了一些配置规范(从存储库中选择元素版本的规则集)的基本知识,可以更容易地进行分支,并且可以很好地支持合并在不同分支中所做的更改。

我不确定是否支持它的一个活动是关键字替换。即使ClearCase支持不支持关键字替换,也可以创建预签入触发器来自动执行关键字替换。

但我不清楚您与ClearCase的所有交互是否仅通过CCRC(ClearCaseRemoteClient)进行。我没有使用过CCRC,也不知道通过CCRC支持什么。

ClearCase是我所知道的最强大的版本控制系统。支持所有枚举任务。