从ClearCase迁移到SVN/Mercurial

在工作中,我们现在正在使用ClearCase.但是,需要大量的开销,特别是当有人做了一些愚蠢的事情时(例如擦除在主干上有多个保留检出的视图......).由于我们试图降低我们的开销并且尽可能轻量级,我们已经考虑了放弃CC和寻找更轻的东西(Subversion或Mercurial)的可能性,看看我们如何不使用CC的90%的功能无论如何.这听起来合理还是我们将法拉利换成旅行车？

根据我的经验,ClearCase确实有很多开销,我们使用SVN进行了大量管理.

我投票,"降级"(实际上是升级).;)

我学到的主要内容是,比产品更重要的是流程.

如果您已经使用SVN类型模型实现了ClearCase(CC),那么SVN将工作得很好并且便宜很多.

另一方面,如果您使用延迟分支,按标签构建和动态视图(或可以),我们在节省时间和精力以及提高可靠性方面非常有用,您将会非常遗憾地失去这些功能.(更不用说构建管理,UCM等)

我发现大多数人都使用第一选择,就像在高峰时段使用法拉利......

例？定义标签GA,SP1,SP2(您可以根据需要在GA和SP1之间放置尽可能多的版本,不相关,并记住,CC标签与SVN不同).GA是您的基础版本,SP1是您当前的版本.SP2是您的下一个版本.当前版本基于GA和SP1.下一个版本基于GA,SP1和SP2(参见CC配置规范)

开始QA.开发正在为"下一个版本"进行持续的工作,用户可以参考(而不是更改)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转变为颠覆升级!