到目前为止,我一直在使用SVN,现在需要从开发人员的角度快速获取ClearCase.这有什么好的资源吗？谢谢.
- 加上 -
SV的概念/术语(即存储库,工作副本,主干,分支,标签,结账,提交,更新,还原)与CC之间是否有映射？根据初步阅读,我提出以下内容.
存储库=> VOB？
工作副本=>快照视图？
Trunk => ??
分支=>整合流？发展流？
标签=>标签？基线？
从repo签出作为工作副本=>从VOB签出作为快照视图？
从工作副本提交到repo =>从快照视图签入到VOB？
更新=> Rebase？
恢复=> ??
?? =>交付
AFAIK CC有自己独特的概念,因此我无法告诉最近的地图.
Von*_*onC 14
你可以从阅读我的答案开始:
您需要注意的两个主要区别是:
ClearCase是以文件为中心的,而不是以存储库为中心的,这意味着您将获得需要逐个签出以便能够修改的只读文件(并且您逐个"提交"(签入)):no global工作区修订版
ClearCase将分支视为真正的元数据,而不是作为带有廉价副本的"目录":存在非"目录",其中包含分支的名称.
话虽这么说,很快:
Repository => VOB:
是:VOB只是repo的另一个术语(Versioned Object base).它不是SQL数据库,而是旧的Atria平面文件库.
工作副本=>快照视图？
快照视图是工作副本中最接近的访问机制,因为它复制硬盘驱动器上的文件.
动态视图可以实现对工作副本的相同访问...无需在硬盘上复制任何内容,这对于快速查询非常有用.
Trunk => ??
" main":这是ClearCase中的主分支(ClearCase中的每个元素 - 文件或目录 - 在"main"上至少有一个版本),但实际上除了你选择作为trunk的一个分支之外没有trunk.
分支=>整合流？发展流？
流不是分支.它是一个元数据,包含您需要使用的标签(基线)列表.那时,只有你选择使用UCM.否则,分支是您可以在没有UCM(mkbranch myBranch)的情况下创建的任何分支.
流可以作为模式来创建以它命名的分支:您在UCM视图中进行的任何结账(在Stream之后自动配置的视图)将创建以其流命名的分支.
标签=>标签？基线？
首先,标签不是像UCM这样的廉价副本的目录.
它是应用于您需要引用的任何版本的标签.
标签(非UCM)和基线(UCM)之间的区别在于基线是应用于(UCM)组件(文件组)的所有文件的标签,而标签可以应用于您的任何元素选择,就像只有给定文件组的子集一样.
从repo签出作为工作副本=>从VOB签出作为快照视图？
几乎,但快照视图的正确术语是"更新".
对于动态视图,您甚至不需要更新(或svn checkout),因为视图是......动态的:您只需立即通过网络查看正确的工作副本.它只是另一种访问机制.
从工作副本提交到repo =>从快照视图签入到VOB？
不完全是因为提交将涉及所有已修改的文件,而签入将是逐个文件(即使ClearCase 7.1.1引入了"原子签入"的概念:请参阅checkin手册页).
更新=> Rebase？
Nope:表示在快照视图中更新(动态视图中没有任何内容,因为它是动态的:在具有类似选择规则的另一个视图中进行的任何更改将在您的视图中立即可见)
Rebase是一个UCM合并,它是来自父流的分支从子流到分支.最后,它只是一个合并.
恢复=> ??
这不是微不足道的......这是一个不合理的合并.
?? => Deliver
Deliver和Rebase只是分支"source"和分支"destination"之间的合并:
唯一的好处是你可以提前"看到"你的合并工作流程定义一个流的层次结构(这只是一个标签列表) ,知道之间的任何合并: