在工作中,我们现在正在使用 ClearCase。但是,需要很多开销,尤其是当有人做了一些愚蠢的事情时(比如删除一个视图,在后备箱上有多个保留的结账......)。由于我们试图降低开销并尽可能轻量级,因此我们已经考虑了放弃 CC 并采用更轻量级(Subversion 或 Mercurial)的可能性,看看我们如何不使用 90% 的 CC 功能反正。这听起来合理吗,还是我们会将我们的法拉利换成旅行车?
13 回答
根据我的经验,ClearCase 确实有很多开销,我们使用 SVN 管理得很好。
我投票“降级”(实际上是升级)。;)
我学到的主要事情是,比产品更重要的是过程。
如果您已经使用 SVN 类型的模型实现了 ClearCase (CC),那么 SVN 将工作得很好并且便宜很多。
另一方面,如果您使用延迟分支、按标签构建和动态视图(或可以),我们使用它们在节省时间和精力以及提高可靠性方面有很大的优势,您将非常后悔失去这些功能。(更不用说构建管理、UCM 等)
我发现大多数人使用第一选择,这就像在高峰时段使用法拉利......
例子?定义标签 GA、SP1、SP2(你可以在 GA 和 SP1 之间有任意多个版本,不相关,记住,CC 标签与 SVN 不同)。GA 是您的基本版本,SP1 是您当前的版本。SP2 是您的下一个版本。当前版本基于 GA 和 SP1。下一个版本基于 GA、SP1 和 SP2(请参阅 CC 配置规范)
开始质量检查。开发正在为“下一个版本”做持续的工作,用户可以参考(而不是更改)GA和SP1,并且可以应用SP2。维护工作是修复 QA 发现的缺陷,可以参考 GA,并应用 SP1。
案例 1:在 ClearCase 中,仅应用 SP1 标签的行为就可以自动将修复程序提供给 Dev SP2 发布团队。没有工作。纳达,零。
在 Subversion 中,您将在 QA 分支上进行更改,然后(希望记住)将更改迁移到 SP2。
案例 2:在您询问之前,当然,如果您添加 SP2 更改,您将不得不分支为 SP1 添加后续更改,就像在大多数系统中一样。
在我的世界中,真实世界的数字:案例 1 在我的上一个 SP 中发生了 122 次(每年 8 个 SP)。如果我使用 Subversion 模型,我不必在 ClearCase 中进行每年超过 800 次更改。
自 2002 年初我们安装 CC 以来,案例 2 已经发生了 6 次。
看过程,而不仅仅是产品。
(对不起,它没有开始那么长:-)
我同意以前的海报。放弃 IBM 产品并转向开源控制产品根本不会是降级。您可能会对这些更轻、更易于使用的工具更满意。在我们的商店中,我们正在从 CVS 迁移到 SVN,并且对结果非常满意。
我肯定会考虑从 clearcase 到 subversion 的升级!
我们从 ClearCase LT 转到 SVN 并喜欢它。我们节省了大量的维护费用,一切都和以前一样好。
我只是希望我在推荐 SVN 之前调查过 Git 或类似的东西。
我对你的“开关”没有任何问题。如果您没有许多使用 UCM 的相互依赖的项目,这将是一个升级。
我同时管理 SCM(ClearCase 和 Subversion),并为中小型独立项目推荐 Subversion。
但是,请确保您的开发人员不习惯 ClearCase 的动态视图:它是文件系统的封装,允许用户从网络访问文件。据我所知,ClearCase 是唯一拥有这种访问权限的公司。
并考虑范式转换:
- ClearCase 以文件为中心(您获得的每个文件都是只读的,并且您只签出您正在处理的文件)
- Subversion 以存储库为中心(您获得的每个文件都是读写的,您在一次原子提交中签入所有修改/添加/删除的文件)
第四次推荐你切换。如果您不使用这些功能,那么使用商业定价的解决方案是一个糟糕的商业选择。
现在,“免费”解决方案也有相关成本。SVN 和 Mercurial 都不会为您提供商业级支持。如果这是一个问题,并且在某些情况下肯定会出现,您可能不想这样做。
在您提到的两个中,如果您当前使用的是集中式 VC 存储库,则应该选择 SVN。SVN 的操作模型不仅简单直观,而且 SVN 拥有我在开源项目中见过的最好的文档和开发者社区。用户邮件列表很棒,开发人员对他们的用户反应灵敏且负责,而红豆书是最好的开源手册。
我喜欢 ClearCase 的一些我在其他 SCM 工具中做不到或根本做不到的事情:
- 使用开发人员分支很轻松。在 CC (UCM) 中,您在流(又名分支)中工作,并将大量工作“交付”到集成流。同时,其他开发人员也这样做。集成商(可能是开发人员之一)然后对集成流进行一些测试,并确保一切都构建并可能进行冒烟测试,然后推荐一个新的基线,其中包括所有开发人员的工作。同时,您继续在您的分支机构工作。下次您想要交付时(或之前,如果您愿意),您会看到一个新的基线可用,因此您合并到您的流中。事实上,如果有更新的基线可用,您将被迫重新设置基准。我尝试在 Microsoft Team Foundation Server 和 SVN 中执行此操作。首先,我找不到执行诸如 CC 强制变基之类的策略的方法,所以我必须去弄清楚自上次合并以来我做了哪些修订,以及从那时起在主干中做了什么,然后从主干合并到我的分支中。然后当我想将我的新工作合并到主干时,我不得不重新合并我刚刚合并到我的分支中的所有内容,以及我的新工作。
- 开发人员分支有利于有效的代码审查。当我使用 CC 时,我们审查了所有内容。但实际上,评论需要时间,我们需要继续努力。每件作品都对应于 CC 中的一项活动。只有在审核完成后,我们才将活动交付给集成流。如果审查需要更改,我可以决定在我所做的原始工作的活动中进行更改(只要没有对该活动中更改的文件进行后续更改),创建一个新活动来解决审查更改,或者可能会吹走整个活动并重新开始(再次,只要没有进行后续更改)。在 TFS 和 SVN 中,一旦你提交了一些东西,你就不能轻易地回去而不吹走后续的工作。所以我们必须找到其他方式向其他开发人员展示我们的更改。这最终将差异转换为网页,但是,如果不将其与待审核的工作混合,我们将无法继续进行更多工作。
- 使用动态视图可以更轻松地进行跨平台开发。我这里只有SVN可以比较,所以也许Mercurial或其他更好。我的目标是在 Linux 和 PowerPC 平台(以及另一个项目的 Windows)上进行更改、构建、测试和调试,并在我满意它适用于所有平台时提交单个变更集。对于 PowerPC 构建,我们有一个用于构建和测试目标的 sun 工作站(访问动态视图)。它很慢,所以我们在 Linux 上进行了大部分编码和调试,然后在 PowerPC 上构建和测试,然后在 (PowerPC) 目标上进行最终测试,最后是签入。解决此问题的一种方法是网络文件共享。我在这里看到的一个问题是 Linux svn 和 Windows 上的 TortoiseSVN 之间的版本不兼容。如果您让 Tortoise 进入 Linux 存储库副本,它会更改 .svn 文件,然后 Linux svn 抱怨版本太新。(由于我们为目标选择的平台,我们无法将我们的 Linux 机器升级到足够新的 svn。)所以我不能在 Linux svn 存储库中使用我的 Windows diff 工具。如果我采用另一种方式,使用 Windows 签出和 Linux 安装 Windows 存储库,则不会保留符号链接(Linux 构建需要这些链接)。
我不反对,维护 ClearCase 是一场噩梦,而且会花钱。但是一旦设置好,它就可以提供一个非常好的开发环境。特别是当您开始与 ClearQuest 集成时(缺陷跟踪,我们也用于跟踪代码审查)。
正如另一位响应者所说,您的答案在很大程度上取决于您的流程需求。
在我以前的公司(CMMi 流程)中,大约 100 名开发人员/测试人员/集成人员与 ClearCase (CC) 一起工作,其中有 3 名全职管理员(添加 2 名自愿兼职)。除非您使用配置管理部分(基线),否则您应该继续使用现代 SCM。基线功能很强大:在传统的 SCM 中,当您更新/变基时,默认情况下您会获得最新的修订。基线是特定“兼容”版本的一组软件组件,以确保构建正常。在某种程度上,它就像依赖构建(即 Maven、Ant Ivy)。当开发人员在基线上变基(更新)时,他们得到了应该是“可构建”的东西。
现在从我的新公司(敏捷商店)回顾过去,我们使用 SVN 和 Mercurial,我认为 CC 是每天的痛苦。使用 CC 处理项目(存储库),您可以创建视图、创建活动,然后签出文件。有些同事害怕做分支:)。使用 SVN 和 Mercurial,我们的 GUI 客户端就没有这样的问题了。开发人员每天提交 10 次。与 CC 相比,人们每天会签到一次。
事实上,CC 有很多开销和缓慢的网络延迟、高昂的许可成本和需要全职管理员。那么除了配置管理还有什么好处呢。
在 Mercurial 上,工作流程更轻松。对于我们当前的项目,提交非源文件搞砸了。汞的历史是不可改变的。我们没有管理员。一位开发人员在半天内重新克隆了一个新项目。在 Clearcase 中,您需要请专家来备份已删除的文件 :)。要创建一个新的 repo,你问你的管理员 :)
离开 ClearCase 之后,现在我对 SVN 尤其是 Mercurial 非常满意。因此,从 ClearCase 迁移到 Mercurial 在流程方面将非常轻量级,而且您会获得更高的生产力。
现在在 SVN 和 Mercurial 之间进行选择?您应该问自己是集中式存储库还是分散式存储库。您可以在 stackoverflow 上进行快速搜索。
我开始不喜欢 IBM Rational 产品,而是喜欢优雅的开源解决方案。
如果您阅读并理解了它,您应该将其命名为“从 clearcase 升级到 svn-mercurial”。
补充: Clearcase 落后于可推荐性阈值,而 Mercurial、Subversion 和 Git 被明确推荐。
http://martinfowler.com/bliki/VersionControlTools.html
您也可以结合 Mercurial 和 Clearcase。阅读“多个 VCS”段落
在过去的几周里,我一直在寻找新工作的 SCM(软件配置管理)和 ALM(应用程序生命周期管理)工具,以取代 CVS 并支持敏捷的采用。
如果您正在寻找能够通过并行开发和分支支持真正的 SCM 的东西,那么可能有比您意识到的更多的选择。
对于简单的 SCM 解决方案,请查看以下内容:
- Accurev:这是一个 SCM 工具,原生支持基于流/并行的开发。它提供了一个非常好的流浏览器,为您提供流的图形视图,并允许您以图形方式将更改作为问题或更改集进行升级(强制对一组源文件进行原子升级)。它有一个内置的问题跟踪器,可为您提供变更管理并让您以基于任务的方式工作。使用 AccuFlow,您可以通过工作流程更好地控制您的更改,而 Accubridge 为您提供 IDE 集成。
- Seapine Surround:这是一款外观漂亮的工具,非常适合分支,但不如 Accurev 先进。Seapine 的优点在于与他们的问题跟踪工具 TestTrack Pro 以及他们的测试用例管理解决方案 TestTrack TCM(结合到 TestTrack Stuido)的集成。最后,他们还有 QA Wizard Pro,这是一个 web 和 winforms 自动化测试工具。
- PureCM:这是另一种非常流行的替代方案,但我没有仔细研究过
- Perforce:这个领域的另一种选择,我对它印象不深,但它确实有一些有趣的小众功能,比如比较和合并图像的能力。
- Plastic SCM:一种不成熟的产品,但看起来非常有趣。
所有这些解决方案都提供了比 ClearCase 更好的分支支持,例如开发人员沙箱(而不是在 ClearCase 中使用那些疯狂的视图)和版本快照等概念。本质上是一个只读分支,有点像基线。
如果您有一个广泛的 Rational 部署,您可能想要研究这些替代方案:
- MKS Integrity:一个很好的组合产品,具有出色的投资组合管理工具和一个很好的内置测试运行视图。它的所有工具都集成在一个 IDE 中,并且非常可定制。
- Serena CM:同样是一个足够好的套件,包含围绕核心 ALM 解决方案的大量工具。非常大的投资组合管理部分,他们的 Mashups 组件有很多业务流程支持,还支持原型设计。
- Telelogic:具有讽刺意味的是,现在是 IBM 的一部分,并且很快就会成为 IBM 的理性人。它的 SCM 解决方案(Telelogic Change and Synergy)很容易成为我见过的最好的解决方案,它能够通过任务明确地将代码更改提升到发布构建分支中。
所有上述解决方案都支持与 Accurev 等相同的 SCM 概念,但显然更多的是端到端产品并且是企业规模的。
在这一点上,我们将选择范围缩小到 MKS 或 Telelogic。
我最大的观点是在 ClearCase 和 CVS/Subversion 之间有很多很多的解决方案,它们是商业的,但相对便宜。
希望这是有用的。
我推荐阅读HG Init - Joel Spolsky 撰写的关于如何从 SVN 切换到 Mercurial 的指南。
正如之前的一些答案所提到的,SVN 和 ClearCase 基本上是在相同的范式下工作的,所以当你阅读这篇文章时,你几乎可以用“Subversion”这个词的每个出现来代替“ClearCase”并将其应用于你的情况。
这是最终说服我开始在工作中使用 Mercurial 的文章。
在我看来,您在 git/mercurial 中会很开心,而在 SVN 中可能不会。OTOH,我所有的 clearcase 经历都是乏味和无爱的,所以我认为任何“逃脱”行动确实是一件非常好的事情。
分布式系统听起来更符合您的工作流程。
我很想知道您的分支结构是如何设置的。
为什么用户在你产品的“主干”上工作?(我假设这意味着您的主要分支)。开发分支不会阻止您的开发人员影响主干吗?
为什么不能在 rmview 脚本上引入一个触发器,以防止用户在结帐时删除视图?这是一个非常简单的练习,网上有很多资源(如果你问的话,我相信 StackOverflow 会为你提供答案!)。
另一个建议是,如果您已经将现金投资于 IBM 产品(因此愿意花钱购买商业支持的 SCM 环境),您可能想看看 Team Concert 和 Jazz。