基本操作中的若干问题(其中还有个别遗留问题,以后解决了再修改进来):
1)如何查看整个VOB的版本树:View中的某个 VOB——右键——ClearCase——Version
Tree,但树上的标签等信息并不是完整的,标签的位置也并非理想的。
2)如何查看某个文件、文件夹的History和版本树:easy,但文件的 VersionTree
经常不能说明什么问题,不推荐查看。元素的History里面有很多有用的。
3)如何比较版本间的改变:
首先,这里的版本有歧义:
狭义的版本:可以理解为“修改”,如 SVN
中每次提交一次,就自动更新一次版本号,产生一个新版本。CC中其实也是这样,可以在History中看到。
广义的版本:可以理解为“众多元素的一次整体发布”,如我们通常说的 8.19.01 版本。
这样说吧:
广义的版本发布之前,SVN或CC都会对我们的修改做n次记录,每次修改记录也能称为SVN或CC所作的一次更新版本。
广义的版本之间还存在“分支”,狭义的版本可以理解为一个“分支”内部的修改、更新。
所以:
1。比较某个元素(文件、文件夹)的两个版本(狭义):选定元素——右键——History——选定两个版本——Compare Selected
Versions。
但只能在该元素的“Event Kind”中“Create Version”类型之间比较。
2。比较两个版本或标签(广义):这个就需要一些技巧了,也是讨论中最集中的地方。CC自己无法完成,需要借助外部工具了。
a。创建两个空 View
b。修改空 View
的属性,加载一个待比较的版本或标签:
右键View——Properties of View——Config
Spec(修改视图规约)
空视图可能只有两句
element * CHECKOUT element *
……
把第一局的 CHECKOUT
修改为希望比较的一个版本或标签。
c。同理修改另一个View属性,加载另一个待比较的版本或标签
d。用
Merge 、Beyond Compare 等工具手工选择两个被映射好的 View中的任意文件、文件夹进行比较。
说白了,第1种方式比较一个元素,CC自己也只能比较单个元素,第2种方式比较多个元素。
SVN中比较两个版本时则一次递归列出所有子文件夹、子文件,非常方便,很好的融合了上述两种方式,让你感觉不到两种方式之间的区别。
4)如何修改、提交代码:手工copy到本地——code、debug——使用Merge工具比较本地-CC上的文件——checkout
已修改的文件——将本地的覆盖到CC上——checkin
|—add source to CC
主要问题就是:你经常不知道哪些文件已经被自己修改了,所以只有用Merge、BeyondCompare等工具手工对比,然后一一合入。
SVN由于采用了“本地工作拷贝”的方式,本地的代码都被管理起来了,你在本地的操作都会被记录,所以提交的时候SVN能够为你做很多事情(包括找到你的更新、递归提交你的更新……),而CC没有“本地工作拷贝”的概念,而只有“网络操作”的概念,拷贝到本地是纯粹的不受管理的“本地拷贝”,本地的修改无法为您记录,所以这个环节也就无法“为您服务”了。
这一点估计就是“对开发人员来说,CC与SVN最密切的区别了”,也能够成为SVN
Fans们攻击CC的最好把柄。
5)如何批量修改、提交代码:由于没有“本地工作拷贝”的概念,而只能做到“本地拷贝”——去掉只读权限——本地修改——合入CC
这样的步骤。
当有很多文件被本地修改需要合入CC的时候,麻烦就来了。
· 先用 Beyond compard
比较
· 点击“=?”比较服务器-本地文件
· 点击不等号,只显示不相等的文件
· 以前是进入View手工对照着每个文件checkout——巨耗精力,或者递归checkout出整个目录——checkin的时候又要点一通鼠标并删除一堆的
*.keep 文件
后来终于发现了【完美解决 批量
checkout、checkin】的方法:
· 可以:在Beyondcompare内选中待checkout的文件——右键——checkout
· 在本地的文件一侧再次选中这些文件,点击“复制(箭头下面一个加号)”,就可以从本地覆盖到CC了,然后再“find
checkout”-“checkin”,再也不会碰到checkout了但没有修改的问题了。
6)如何解决代码冲突:
冲突分两类:
1。分支间合并时产生的冲突:将一个分支合入主干,如果主干已经有修改,分支的修改合入时就会报冲突,需要人工解决。这是一个非常危险的操作,合不好的话会将主干改的不能编译和引入错误。所以我们公司基本禁止个人搞“私人分支”,就是CC管理员在将分支合入主干的时候也是能不合就不合的原则。
2。分支内某元素被多人修改而产生的冲突:
首先要明白checkout有两种:二进制checkout(CC中叫“保留式”checkout,一个人checkout后别人不能再次checkout)、非二进制checkout(CC中称为“非保留”式)。
如果你checkout
的时候用的二进制checkout,则没有冲突发生的情况。如果不是(SVN都不是),则需要保证及时的更新服务器的修改,合入的时候细心比较……反正麻烦着呢,CC你就始终用保留式Checkout吧。至于SVN就不用多操心,Updata操作会完美解决这个问题。
7)如何回溯历史版本:
第一种:简单的拿到一个以前的版本。这个好作,创建空View——修改视图规约为想要的标签——OK!
第二种:想把当前本地的一个版本还原到以前的一个版本(或标签):???偶还不知道
8)如何并行开发(知道别人正在checkout什么、我checkout时需要注意什么……):find
checkout的时候,会弹出一个对话框,里面可以选择是否“寻找别人正在checkout的文件”。
分享到:
相关推荐
ClearCase使用培训测试与开发人员实用PPT课件.pptx
ClearCase使用培训测试与开发人员实用PPT学习教案.pptx
ClearCase基本操作
本文为开发人员学习CLEARCASE 的一个补充文档。更详细的文档请参照CLEARCASE 软件 安装目录下的PDF 文档。为了开发人员学习CLEARCASE 的针对性,而...的管理员以及CM 人员所应该熟悉的内容,但并一定需要开发人员来掌握
UCM ClearCase下使用perl获取代码行总数
clearcase开发总结,这些都是我个人在学习clearcase当中的一些总结,大家多交流一下
clearcase for java 开发库
clearcase关于baseline的一些操作总结
clearcase客户端操作指导-080407
本章讲述了ClearCase的基本使用,前文讲过ClearCase UCM所用的工具是架构在基本的ClearCase之上的,掌握对ClearCase的基本使用能够降低对ClearCase UCM的学习曲线。
ClearCase 客户端使用指南 For windows base 方式 包括安装、配置、VOB和VIEW、基本操作、与开发工具集成等,文字与图片配合,内容详实,共41页。
随着时间的推移,可视化设计与软件配置管理(SCM)...本文适用于使用 Rational XDE/Java Platform Edition 和 Rational ClearCase 的软件开发人员。本文详细概述了 Rational XDE 与 Rational ClearCase 之间的集成。
ClearCase常用命令的操作和使用说明。
ClearCase就是一个软件开发的版本控制系统,不熟悉的人可以把它和git相类比,类似于windows和linux是两个操作系统一样。 ClearCase和Git就是两个版本控制系统。它们都有类似的操作,不过却有不同的命令等,更细的话...
clearcase一些常用命令,windows unix都适用
Clearcase中添加递归操作的方法,主要针对一些使用clearcase的用户不能批量上传整个目录下文档代码的问题
本参考手册为英文版clearcase命令参考手册上册.里面详细的说明了各个命令如何使用以及举例。是一本非常好而全的clearcase参考书。
ClearCase的使用方法,其中有ClearCase的基本概念等。
ClearCase客户端安装指导,适合不熟悉ClearCase的 朋友,