ClearCase培训-深入PPT课件

1 ClearCase培训 软件部 2 clearcase公司cc使用情况介绍CC的几个常用工具概念工作流程日常操作注意事项 3 是rational公司的主要配置管理工具 其原因在于ClearCase是整个rational产品系列中的中枢 repository ClearCase提供了VOB的概念来进行配置管理 功能极其强大 ClearCase目前国内流行版本是forNT的4 1需要在NT主域控制器上安装 ClearCase的解密和安装比较复杂 ClearCase是世界上目前最强大的配置管理工具之一 由于它采用许多新的配置管理思想 使得相对于传统的CVS VSS PVCS等版本管理工具 ClearCase具有许多闪光点 目前正在为世界上各大软件企业所使用 国内目前华为 先驱使用该系统 ClearCase中有大量的新的术语 其中比较重要的术语有 UCM 统一配置管理 VOB 版本对象基础 View 版本视图 Activity 更新活动 ClearCase实现版本管理的基础是VOB 成员要更改受控资料 需要先设置一个自己的View 这个View是你感兴趣的受控资料范围 然后可以CheckOut资料到本地资料区 进行修改后再CheckIn提交 ClearCase极为有力的支持多版本 并行开发 ClearCase不仅可以提供基于文件的版本历史 甚至可以对整个目录系统的演化进行跟踪记录 ClearCase 4 管理复杂的软件开发过程推进并行开发强有力的版本控制透明的工作区管理有效的build管理有弹性的流程管理 ClearCase功能简介 5 开发软件不是一件容易的事 首先面临的是管理多种产品 版本等问题 更为复杂的是由两组或多组人员共同开发相同的程序 再加上多样化的开发程序 使得整个开发过程很难进行有效的管理 而RationalClearCase就是一个软件开发管理工具来解决以前无法追踪整个开发过程的问题 它结合了完整的软件结构管理 SCM SoftwareConfigurationManagement 包括版本控制 VersionControl 工作区管理 WorkspaceManagement Build管理和流程控制 ProcessControl 它可以使开发团队能加速开发过程 而且确保得到正确的Release和可靠的build版本 并建立有效的开发过程 不需要改变原有的开发环境和工作模式 管理复杂的软件开发过程 6 在竞争的市场中 并行开发在软件开发中是一项实际的需要 然而很多机构因缺少合适的工具来执行有效的并行开发 结果导致问题未及时修改 集成困难等问题 RationalClearCase提供分布式的并行开发模式 让多个开发人员能有效地设计 编写程序 测试及修改程序代码 推进并行开发 7 ClearCase能让你确认正确的版本 解决版本不一致问题 它追踪每一个文件和目录的改变 维护所有的程序源代码 二进制码 执行码 测试项目 文档以及用户自定义的对象 让开发人员能快速找出所需的内容 重新build并恢复到原先的版本 强有力的版本控制 8 ClearCaseviews提供正确的文件版本来进行开发工作 以免除复杂的开发环境 开发人员可以选择所需view Dynamicview提供网络使用者快速取得最新的程序代码和文档资料 Snapshotviews提供localbuild 而且支持离线作业 开发人员能容易地将自己的工作与整体计划同步 且无论选择哪以种view RationalClearCase都能完全地集成整个开发环境 提高开发效率 透明的工作区管理 9 一组丰富的管理工具能帮助开发团队制定开发政策 设定开发角色和工作流程 确立升级模式 流程状态等 自动监视存取状况并防止非法修改 对流程自动化与任务管理 有弹性的流程管理 返回 10 活动和工件随着软件系统和开发团队在规模和复杂性上的不断增长 对开发团队来说如何围绕周期性的版本发布来合理地组织开发活动以及高效地管理用于实现这些活动的工件变得日益重要 活动 activity 可以是在现有产品中修复一个缺陷或者新加一个增强功能 工件 artifact 可以是在开发生命周期中涉及的任何东西 例如需求文档 源代码 设计模型或者测试脚本等 实际上软件开发过程就是软件开发团队执行活动并生产工件 图1 UCM集成了由RationalClearQuest提供的变更请求活动管理和RationalClearCase提供的工件管理功能 11 我们采用UCM模式采用ClearQuest管理变更 同时作为缺陷跟踪工具 和ClearCase集成 对于2人以上项目采用多流的方式 否则采用单流模式 一般是每个开发人员一个开发流 一个开发视图 一个集成视图 对于前后台结合紧密或者两人工作紧密相关的 可以两个人共用一个流 对于多流项目 在开发流上进行开发 严禁在集成流上进行update以及updateview外的其他操作 平时工作在开发流上 进行co ci addtosrc deliver rebase等操作 可以使用IDEA或Eclipse等与ClearCase集成插件的工具进行开发工作 每个项目组有专门的集成人员进行makebaseline和设置推荐基线工作 其他人员 如非特殊需要 禁止进行此操作 进行co ci addtosrc操作时 必须绑定一个activity 即项目经理指派给您的工作 请不要重复建立activity 也不要建立一些无用的activity 测试环境 testVOB下的test和ucm test 可以任意进行操作 但是在正式环境请按照规则工作 比如activity的命名要规范 headline应该是某个具体工作的简要概述 公司cc使用情况介绍 12 项目管理者在ClearCase中创建项目并且为项目中的元件确定初始基线集合 同时在ClearQuest中初始化一个数据库保存ClearQuest请求记录 设定其对应的工作流程 开发人员通过创建私有工作区域 获取项目基线内容 加入该项目 测试人员提交一个变更请求 管理者将其作为一项活动指派给开发人员 开发人员在属于自己的一个活动上工作 与活动相关的文件集合称为变化集 当开发人员完成活动 并且在其私有工作区对其工作进行了测试后 通过执行交付将其工作与开发组共享 交付操作将开发者私有区域中的工作合并到项目共享区域 使用ClearCase和ClearQuest的工作流程 1 13 项目管理者在项目共享区域集成开发人员交付的工作 项目管理者定期在项目共享域创建新的基线 用来集成开发人员的工作 项目管理者执行快速验证测试 以保证新的基线可以正常工作 在完成测试之后可以在ClearQuest中将该变更请求标识为已验证通过 软件质量工程师将执行更多的扩展测试 项目管理者定期在基线的质量和稳定性提高后调整极限的晋升级别 如 创建 测试 发布 以反映适当的里程碑 当新的基线经过了足够的测试 项目管理者可以将其指定为推荐基线 开发者执行rebase操作来修改其私有工作区 使其包含新的推荐基线所确定的新版本集 开发者继续如下的开发循环 基于活动进行开发工作 发布完成的活动 根据新基线修改其私有工作区域 使用ClearCase和ClearQuest的工作流程 2 14 Ucm方式 15 单流项目适于紧密协作的小规模团队 串行开发标准使用模式 一人一开发流适于隔离度极大的并行开发多人一开发流流适于组间隔离度较大 组内协作紧密的并行开发多项目规模较大的多发布项目主干项目继承性开发多的多发布项目 UCM使用模式 返回 16 常见概念 存储ElementHistoryVersion项目流activity视图基线 返回 17 VOB VersionedObjectBase版本对象库 用于存放文件元素 目录元素 派生对象以及与这些对象相关元数据的存储池 分为单组件和多组件的VOB 其中多组件的可以再包含VOB PVOB 一个存放UCM对象的VOB 例如项目 流 基线 活动和变更集等 每个UCM项目必须有一个PVOB 多个项目可以共享同一个PVOB 存储 18 可以理解为一些代码 文档 Model等按一定的目录结构组织成的完成某些功能的可以重用的集合 元素是出于cc版本控制下的文件或目录 组件用于对元素进行分组 一个Component是一个物理对象 标识了一个根目录 组件是有版本的 组件的版本就是基线 一个Component是一组文件和目录的集合 处于同一个目录树下 大系统可能包含多个Component Component可以理解为目录树 比如toptais包括很多模块 如reg dnc等 规划时 可以把整个toptais规划为一个vob 然后把每个模块规划为一个component 这样对于每个Component可以单独建立项目project 比如project reg使用reg这个Component 那么这个项目的整个目录结构就是Toptais reg 组件可以复用 比如一个公共的组件 可以被多个project所使用 Component与UCMProject相关联 UCMProject所管理的所有的Element必定从属于一个Component 每个UCMProject至少有一个Component 组件有基线一个组件不能跨越多个vob 最大的组件大小就是它的vob Component只是ClearCaseUCM模式的逻辑视图 而实际的存储与控制是由VOB实现的 通过对VOB的访问控制实现对Component的控制 组件 组件 19 20 vob 21 Vob pvob component关系 返回 22 Element纳入配置管理的包括版本信息的配置项 包括文件与目录 元素有版本 Element 返回 23 一个ClearCaseUCM的对象 包含用于管理重要开发成果的配置信息 或者产品发布版本 项目设置一组制度 用于管理开发人员在开发活动中访问和更新文件与目录 一个项目包含一个集成流 集成流配置的视图选定了项目中共享元素的最新版本 一个项目通常包含多个开发流 开发流配置的视图允许开发人员将自己工作和其他项目成员的工作内容进行隔离 在有限资源条件下 人们用于规划 执行和控制活动而付出的努力 项目 Project 24 单流项目和多流项目 单流项目 只有一个集成流 开发人员在集成流上进行工作 开发人员在本地建立视图 如果建立动态视图 则只需要进行刷新视图 按F5 即可获得最新的程序 如果采用快照视图 则需要进行updateview才可以得到最新的程序 单流的无须进行deliver操作 但是也可以进行makebaseline 以标识项目里程碑 25 单流UCM工程的工作流程 26 单流UCM工程中元素的版本树 27 从上图中可以看出 该UCM工程的集成流为 UCM单流工程 集成流 开发团队包括王刚与李亮两位开发人员 在开发活动中 开发人员通过关联分配给自己的活动直接从集成流中检出所需的文件版本进行变更 当完成变更并将其检入到源控制之后 其他开发人员就能看到对其所作出的变更 由于整个变更流程为串行开发 开发人员始终访问的是集成流中的数据 因此在开发过程中使用的数据都是最新的 鉴于此 当开发人员完成变更并要将变更结果检入到源控制时 需要完成完整的测试 保证变更的有效性 以免影响到其他人员的工作 作为集成人员来 需要适时监控开发人员对项目作出的变更 并根据变更所关联的活动创建项目基线 并在根据项目进展的程度决定推荐基线 28 多流项目 项目有一个集成流和多个开发流 每个开发人员可以有自己的开发流 即独立的工作区 在工作区内可以任意修改文件 然后checkin到自己的开发流上 然后deliver到集成流 多个开发人员可以同时修改同一个文件而互不干扰 也可以多个人共用一个开发流 29 多流结构UCM工程的工作流程 30 多流UCM工程中元素的版本树 返回 31 流为两个目的服务 开发和集成 涉及一个开发人员的工作活动的流称为 开发流 developmentstream 涉及对一个项目中所有开发人员的活动进行合并的流称为 集成流 integrationstream 每个项目有一个集成流和0到多个开发流 流 32 返回 33 Stream baseline activity 34 活动 个人要完成的工作单元 可以理解为RUP中的workorder 工作单 这里的activity包括defect basecmactivity ucmutilityactivity Activity 活动 返回 35 36 37 我们知道 软件配置管理工具的一个基本功能是建立和管理开发人员的工作空间 在ClearCase中 工作空间被称为视图 View 它可以选择所指定任务的每一个文件或目录的适当版本 并将它们呈现给使用者 通俗的讲 View就像一个过滤器 依据一组配置规则从VOB中将我们需要的文件或目录的版本选择出来 View是访问V库中文件和目录版本的手段 通过视图 用户可以浏览 修改 构建可用的文件和目录 在实际使用中 View分为两种类型 即DynamicView 动态视图 和SnapshotView 静态视图 又称快照视图 下面我们来看看这两种视图有什么差异 视图 38 自动保持与VOB库的同步更新 使用MVFS文件系统透明访问VOB库 不占用本机空间 动态视图无需将文件拷贝到本地目录 通过虚拟文件系统对VOB中的版本进行存取操作 动态视图的使用依赖于网络 提供了共享派生对象和构建审计功能 这是动态视图独有的 动态视图通过mount指定的VOB库来获取数据 动态视图采用mount的方式获取VOB中的数据 速度比较快 它是一个全局视图 动态视图 39 只能定期通过update操作实现文件的更新 文件被下载到本地 占用本地空间 可以离线工作 断网使用 可以在本地进行高速编译 使用静态视图占用ClearCase服务器资源较少 静态视图通过load指定的VOB库来查看文件 静态视图 40 在实际使用中 当你希望离线工作或只需要VOB库中的部分代码时 建议使用静态视图 这样还能减少因对服务器频繁访问所造成的压力 如果你使用便携式电脑 使用静态视图则更加便利当需要节省本地磁盘空间 希望频繁自动更新或者仅仅是为了查看文档 代码 创建动态视图既快速又不占用本机空间 是个不错的选择 比较 返回 41 一个ClearCaseUCM的对象 典型的用法是表达一个或多个组件的稳定配置 一个基线确定了一组活动 也确定了一个或多个构建中每个可见元素的一个版本 您可以基于一个基线创建一个开发流 或根据一个基线对已经存在的开发流执行变基操作 在软件开发过程中 可以将各个元素的不同的版本组合成一个基线 通过基线表示软件项目开发达到了一定的要求 也可以说是里程碑 项目管理员可以根据情况设置相应的基线 并随着项目的发展逐步设置新的基线 基线的静态的 不变的 在ClearCaseUCM模式中 有两种基线类型 增量基线 完全基线 ClearCase创建增量基线的方法是记录下最近一次完全基线以及自那时以来发生变化的版本 ClearCase创建完全基线的方法是记录下该构件根目录下的所有版本 复合基线 基线 baseline 42 基线 43 项目团队成员用于对开发流变基的一组基线 此外 当开发人员加入一个项目时 推荐基线将用于初始化他们的开发工作区 推荐基线代表了一个系统配置或者一组组件 其内容已经达到了特定的提升级别 推荐基线 recommendedbaseline 44 Rejected 未通过测试 不建议使用Initial 软件初始阶段的基线Built 可编译的基线Tested 完成测试的基线Released 通过测试验证 可以发布的基线 基线级别 返回 45 UCM为项目开发者提供的主要好处之一 就是基于活动来进行开发的思想 个人要完成的工作单元 有不同的类型 比如一个缺陷 一个增强的请求 或者一个问题可能就是一个活动 这种工作单元和变更请求管理系统及过程紧密结合 在项目管理系统中 活动可以作为其他活动的子活动 一个ClearCaseUCM的对象 用于跟踪完成一项开发任务所需的工作 一个活动包括用于描述任务的文字和一个变更集 变更集中指明在该活动中建立和变更的所有版本 所有的变更都是基于活动的 在UCM模式下所有的CheckOut CheckIn AddtoSourceControl等引起配置项发生变化的操作必须关联到一个Activity 活动 46 日常操作 开发人员 AddtosourcecontrolCheckOut 检出CheckIN 检入Deliver 交付变更Rebase 变基Merge 处理变更冲突对Hijacked文件的处理FindModifiedFilesUpdateViewFindcheckouts文件 目录的删除 移动 重命名DeliverBaseline集成人员 设置基线 设置推荐基线 返回 47 将更新您的开发环境 更新到某一个基线上 建议更新到推荐基线 默认情况是更新到推荐基线 不过您可以选择更新的基线 但是新基线不一定稳定 使得您可以看到其他开发人员所做的变更 让当前Stream的View的内容与IntegrationStream某个基线同步 Rebase完成后 不能回退 所以一定要慎重 变基步骤 运行变基操作 构建并测试 好的做法是在您的开发视图中构建软件并进行测试 特别是在需要解决冲突的情况下 完成或撤销变基 Rebase 变基 返回 48 变基是一个可以重新开始的操作 因为变基可以根据需要在一段时间内或在多次登录过程中完成 多数情况下 Rebase操作将简单的更新您的开发流配置 这样就可以在开发视图中看到新版本 也检查是否存在必须解决的冲突 也就是说您已对进行Merge操作 具体操作 打开 选择您所在项目的集成流 右键 点击RebaseFrom 49 选择一个基线 点Ok即可进行更新 建议选择推荐基线 返回 50 未checkout前 文件是只读状态 不能修改 CheckOut后可在本地可以进行修改 CheckOut后 文件变为可以修改状态 需要检出时 必须指定您正工作在哪个活动上 通过下拉列表 执行一个待做工作查询 可以找到预先分配给您的所有活动 还可以直接new一个新的活动 完成检出操作后 可以使用任何工具进行修改元素 元素可以被再次检出 当您工作在多个活动上或者当您想将一个元素的中间版本存入VOB时 这一检出检入动作可以根据需要执行多次 这里的检入操作并不会使您的变更结果被其他开发人员看到 只有在deliver之后其他开发人员才能看到这些变更 CheckOut 检出 51 保留型检出 非保留型检出 保留型检出操作意味着检出动作者能够保证第一个执行检入动作 在任意一个时间点上对于同一个文件最多只能有一个保留型检出 在第一个人A进行保留型检出后 其他人再进行保留型检出 则会出现错误提示 这时候您有三种选择 等待A将文件检入询问A在做何修改 以及需要多久进行非保留型检出 在A进行检入时 没有任何特别之处 但是对于进行非保留型检出的B来说 将得到错误提示 除非满足以下三种情况中的一种 A已经检入文件A撤销了检出A将保留型检出改为非保留型检出 返回 52 本地修改完毕 进行CheckIN 文件恢复为只读状态 checkin后 不能回退 所以一定要慎重 注 当一个文件的某一行超过8000个字节时 提交会有问题 请与配置管理员联系 可以点右键 查找哪些文件被检出 CheckIN 检入 返回 53 执行将选定的文件或目录纳入ClearCase管理的动作 如果正确执行完成后 该文件与目录后的类型会变为FileelementVersion或DirectoryVersion 注意默认的这个操作并不会进行递归 所以要由下级文件夹往上逐级的进行AddtoSourceControl 而不要只把最上级的文件夹进行AddtoSourceControl 否则则在执行完成后文件的类型还是View privateFile或View privateDirectory 在这种情况下 该文件或目录实际上没有纳入配置管理 AddtoSourceControl完成后 不能回退 所以一定要慎重 如果发现加错了 请在ClearCaseexplorer里把文件进行delete 批量添加文件 在需要加入版本控制的文件夹下打开dos窗口 输入下列命令 回车即可进行导入 for f delims vin cleartoolls view only r short docleartoolmkelem nc mkpath ci v AddtoSourceControl 返回 54 使得自己的变更可以为项目其他成员所用 将自己的变更和其他组成员的变更进行归并集成 是一个从开发流向UCMProject集成流或其他开发流提交工作的一个动作 deliver完成后 不能回退 所以一定要慎重 步骤 检入所有未检入的检出元素 Update集成视图可选择地变基至项目的最新推荐基线 如果您这样做 需要对与集成工作有关的变更进行构建 测试和调试 运行ClearCasedeliver命令构建并测试交付结果完成或撤销本次交付 注意 点complete或者取消 Deliver 交付变更 55 启动Deliver操作后 将要Deliver的流的状态将会被置为deliver in progress 注意不是目标流 检查所有提交的活动之间的依赖关系检查所有的目录配置项 如果发现提交流与目标流有不同 则在目标流上Checkout并进行Merge 如果由于目标流上已经对目标项进行了ReservedCheckout Merge失败 则提交停止 这时所有已经归并成功的目录配置项在目标流上保存Merge结果 对所有需要归并的配置项进行Checkout 如果不能进行Reserved类型的Checkout 跳过该配置项 继续尝试对其他需要归并的配置进行Checkout如果不能将所有的配置项Checkout 则以下步骤不会进行 有两种选择回退你的Deliver解决不能Checkout的问题 例如由于其他人正在进行Deliver操作 所以不能Checkout 则等其他人Deliver完成或回退后再执行Deliver所有需要提交的配置项都要Checkout成功后 开始Merge 如果自动Merge不成功 则需要手工Merge所有Merge成功后 建议在目标流是进行Build并测试Build没有问题 Complete提交流 将提交流的状态deliver in progress取消 Deliver原理 56 当交付一个活动时 对元素而言只有最近的检入版本才会被Deliver 为了交付变更必须检入变更 如果正准备交付的活动含有未检入的检出元素 则不会交付这些未检入文件上的变更 搜索未检入的元素 交付前进行变基 也需要进行测试 可以选择DeliverfromStreamtoDefaultTarget发布到父流 也可以选择DeliverfromStreamtoAlternateTarget 发布到其他人的开发流 返回 57 一般会自动进行归并 但是有时候需要手工进行干预 可能需要额外的编码工作来解决冲突 CC所支持的归并算法相当智能 直到插入 删除和移动文本块 但是它并不明白归并的语言的语法 仅仅知道它是一个文本文件并据此进行归并 因为 当交付或变基以完全自动方式进行归并之后 对归并结果进行校验十分重要 处理变更冲突 58 下栏的base是2和3的共同的原始祖先 第二是与目前文件冲突的文件 如deliver到集成流出现合并 则这个文件是本地视图的 第三个是目标流的文件 deliver的时候指集成流的文件 Rebase时 第二个文件是集成流的文件 第三个是本地开发视图的文件 在本例子中 进行rebase操作 可以看到第二个文件多了几行 第三个文件也是在原来文件的最后增加了3行 如果要保留自己的文件 则选择工具栏上的数字3 效果如下图 59 如果要保留服务器上的文件 放弃自己的修改 则选择2 合并效果如下图 60 返回 Merge二进制文件 在提交 Deliver 二进制文件时 CC无法对二进制文件进行Merge操作 会提示Mergeerror 解决办法 将开发流中的二进制文件复制到集成流 此时集成流中对应的文件为checkout状态 可以直接覆盖 接着deliver即可 61 当文件未经CheckOut即被强制修改 ClearCase会将其置为Hijacked状态 Hijacked文件将影响到UpdateView等操作 文件变成Hijacked状态有2大类原因 不正常 非故意 不小心所致 忘记CheckOut WindowsExplore中直接打开强制修改 通过相应工具如Word改文件内容或是使用Copy Paste命令覆盖原文件 正常 故意所致 如网络断 回家 出差在外 无法访问CCServer 而修改工作需要继续 又希望未来提交强制修改结果 Hijacked文件 62 对Hijacked文件可以有2种处理办法 认可强制修改 先转CheckOut接着再CheckIn 放弃该强制修改 UndoHijackedFile 返回 63 FindModifiedFiles步骤一 查找对整个视图寻找所有被修改 正常修改及Hijacked文件 的文件 注 必须选中视图名 否则右键菜单中无 FindModifiedFiles 命令 FindModifiedFiles 64 查找结果如下 我们的结果中有Hijacked文件 红线提示部分 FindModifiedFiles步骤二 65 Close上图后进入如下界面 提示有Hijacked文件 要否先直接CheckOut出来 因为不好判断该非法修改 没有CheckOut的修改 是否有意义 值得接受 先选择No 小心 默认是Yes 此时进入FindModifiedFiles汇总界面 下图后面界面 左侧CheckdOut文件夹指示被CheckOut出来并被修改过的文件集合 存在于右侧 Hijacked文件夹指示未经CheckOut而被非法修改的文件集合 点该文件夹后 所有Hijacked文件将刷新于右侧 FindModifiedFiles步骤三 返回 66 查找方法是选中视图的第一级目录 而非视图本身 然后执行右键FindCheckouts命令 Ok 进入一个FindCheckouts窗口 类同于上FindModifiedFiles命令结果窗口 默认查找的是本人的本试图的检出文件 如果要查找本流上所有的视图的checkout情况 则FindCheckouts窗口里选择 FindCheckouts 67 普通CheckOut文件有2种处理方式 CheckIn 修改认同 提交 或UndoCheckOut 放弃该修改版本 2个命令均可处理单个文件或批量处理 Find结果处理 有修改checkout文件 68 还有一种CheckOut文件比较特殊 就是CheckOut出来了 但是没有修改 如此有2种处理办法 强制性CheckIn 增加一个和前版本完全相同的版本 浪费 或是UndoCheckOut 为此需要先知道它有没有被修改 然后才能作决定 问题是没有直观办法知道它到底有没有被修改 所以 正确做法是如上面的界面一样先CheckIn所有CheckOut文件 对于没有修改的文件ClearCase将在CheckIn的过程中提示你该文件内容同于上一个版本 不能CheckIn 下图 则确定之 继续 当所有CheckIn完毕后 上图FindModifiedFiles的结果窗体将刷新 剩下的仍为CheckOut状态的文件即为无实质修改的文件 全部选中 UndoCheckOut即可 Find结果处理 未修改CheckOut文件 69 如果你足够懒 不想如此麻烦 不管三七二十一所有CheckOut文件均想CheckIn进去 也可以 方法是CheckIn时 会弹出一个选项设置窗体 选中一个选项 参下图 返回 70 仅限静态视图 对于动态视图 系统会自动定时更新到本地 特殊文件保存 Refresh一下即可 更新整个视图 点击CCExplorer中的文件夹窗格 执行右键菜单 UpdateView 命令 更新视图的某个目录树 点击该目录树的根 执行右键菜单 Update 命令 更新视图 UpdateView 返回 71 务必重视 对文件 目录的此3大操作只能在CCExplore中进行 绝对不能在WindowsExplore中进行 否则肯定出严重问题 此3大操作不必你自己签出 签入有关文件 系统会自动执行 重命名 删除 CCExplore中有相应右键快捷菜单 直接执行 提示确认即可 删除或者重命名文件时需要把上级目录进行checkout 然后直接进行删除或重命名操作 或者将删除 重名文件的活动设置为当前活动 然后直接在ccexplorer中执行删除重命名操作 请一定不要在windows的资源管理器里直接进行重命名或者删除 否则会出现错误 出现三个问号 移动CCExplore中有相应右键快捷菜单 直接执行 提示确认即可 需要注意的是 移动必须是自右向左拖 自 浏览器窗格 拖向 文件夹窗格 而无法自 浏览器窗格 拖向 浏览器窗格 更无法自 文件夹窗格 拖向 文件夹窗格 文件 目录的删除 移动 重命名 返回 72 设置基线 基线用于开发人员定期的变基操作 从而与最新的开发活动同步 步骤 锁住集成流 拒绝deliver 为软件构建建立基线构建执行所有可以执行的冒烟测试提升软件的构建基线 项目的使用推荐基线 可选 为集成流解锁 73 打开属性 选择locked在excluded 右键选择被排除的用户 锁住集成流 拒绝deliver 74 打开或者在开始 程序 选择选择集成流 右键选择MakeBaseline 为软件构建建立基线 75 首先是基线的名称 缺省情况下 是用项目名称加上日期作为基线名称 第二是基线的描述第三是确定基线的类型 完全的还是增量的 创建增量基线的方法是记录下最近一次完全基线以及自那时以来发生的变化的版本 创建完全基线的方法是记录下该构建根目录下的所有版本 第四是指明正在创建的基线所在的项目及工作流 最后指明用于创建基线的视图 缺省情况下 自上次基线以来的所有修改活动都将包含在新基线中 也可以选择某些活动 使这个基线只是包括这些活动 建立基线 76 在流的属性页选择unlocked按钮 解锁 为集成流解锁 77 在项目集成流上点击选择右键打开下图 提升软件的构建基线 项目的使用推荐基线 可选 78 在项目集成流上点击右键选择属性集成人员应该降级带有已知问题的基线 如果基线在构建时失败 应该转到rejected级别或者其他合适的提升级别 这就避免用到不好的基线 返回 79 选择 RecommendBaselines点change按钮 列出所有的基线选择一条基线作为推荐基线 当前的推荐基线 名称前有星号 设置推荐基线 返回 80 1 进行变更和活动相关联时 最常见的错误是在一个文件中进行了两个不同的变更 然后检入该文件 正确的做法是进行一次变更 检入本次变更 再检出文件 进行第二次修改 这样就可以将每次的检出同相应的活动相关联 2 在Deliver和Rebase尚未进行完 需要终止时 一定要先进行回退操作 而不要直接去进行其他的操作 否则将会出现错误 3 Deliver和Rebase进行完成时 要点complete或者cancel 然后点close按钮 而不要直接点close 4 在使用其他工具进行开发时 切勿不把变更和活动绑定而直接进行修改 否则 将造成无法Deliver 5 切勿直接修改本地文件的只读属性 然后强行修改文件 请先checkout 否则强行修改的文件状态会变为hijacked 这时候请进行undohijacked或者先checkout再checkin 再进行其他操作 注意事项 81 View的lost found文件夹是回收站 一般不需要进行进行修改开发人员工作在开发视图上 不要在集成视图上进行工作View下的view dat文件不要删除 进行deliver之前 请先把所有文件都checkin进行deliver之前 请确保您的流已经更新到推荐基线如果几个人共享一个流 则在出现无法checkout时 需要进行synchronise 方法是在clearcaseexplorer中 选择视图 右键选择propertiesofview 在出现的窗口点击Sychronisewithstream 然后会出现update 点继续即可 机器一定要登陆到域 并且以域用户身份进入机器才可以使用clearcase 如果需要deliver到其他开发人员的开发流 则