我们正在将一个相当大的代码库从VSS迁移到Clearcase w\UCM,并且正在考虑将我们的源代码组织到一个项目中的一个或多个组件中.我们应该记住哪些最佳实践\潜在的陷阱？
源被组织成层(数据层,业务层,GUI层).团队相当小,开发人员倾向于拥有代码库的某一层,并且由于并行开发工作,我们预计会有相当多的分支.
当我在ClearCase中签出一个文件时,它会询问我是否要查看"保留"或"未保留"文件.这些类型的结账之间有什么区别？何时适合使用它们？
我试图签出一个文件,然后将其转到"Checkout but removed"状态.
我无法解决它,也不知道接下来需要做什么.
当我通过网络浏览时,我发现了一篇文章IBM网站Checkout但删除了状态
但我没有尝试重命名文件名,如文章中提到的仍然得到错误.
我使用的是Clearcase 7.0.1.0版本.请帮忙解决这个问题.
我被要求提供我在3个月前进入ClearCase的签到的详细信息.我知道评论中包含的QC编号但到目前为止还未能完全找到通过评论搜索ClearCase进行签入的方法.
有任何想法吗？
我想检查目录和所有子目录到明确的情况.是否有特定的命令来实现它？目前我进入每个目录并手动检入每个文件.
将Rational ClearCase v.7.0.1.1与UCM一起使用时,我在使用ClearCase的"从流交换到备用目标"功能时遇到了问题.
想象一下,我们有一个项目集成流和两个从它派生的开发人员流A和B. 现在我在流A中更改了一个文件.我希望delevoper拥有流B能够使用我的工作而不必将文件传递到集成流,所以我从流A传递到备用目标流B.
到现在为止还挺好.我继续对文件进行另一次更改,但是流B开发人员不需要这个更改,所以我不会将它交给他.
经过一段时间,我将我的工作交付给主要的集成流.这很好,虽然我想知道为什么ClearCase将合并标记为正常的"合并"而不是"合并(平凡)" - 除了我之外没有人对文件进行了更改.
交付后,将在主集成流上创建新基线.
当开发人员B试图改变他的流时,会出现真正的问题.由于开发人员B从未对文件进行任何更改,因此我希望合并是一个简单的合并,无需进行任何交互.但是,开发人员B被迫以图形方式解决该文件上的合并冲突,让他在集成流上的基本版本,我提供给他的版本和我提供给集成流的版本之间进行选择.
在解决合并并完成rebase后,开发人员B想要执行到主集成流的交付时,会出现混淆.除了我最初交付给他的活动之外,他还被要求提供一项名为rebase _...的活动,我绝不期望提供交付.
我在这里错过了什么吗？我们是否错误地使用ClearCase或者这是一个已知的限制/错误？有没有人体验过这个功能？
在此先感谢您的帮助!
一月
Clearcase中的配置规范和加载规则有什么区别？
是否仅使用"cleartool editcs -tag"命令编辑它们？
TFS的分支特征是什么？
例如,如果我们查看Perforce,Subversion,CVS等工具,我们会看到分支正在获取主干的副本.它是"早期分支"所有被定义为分支的文件,而不管这些文件是否在该分支中被更改.
在为整个文件树创建分支的决定时,此方法开始创建新版本的文件.
其中一个最大的缺点是,在分支外部(通常在主干中)进行的任何更改,您希望将这些更改带入分支,因为它们具有"早期分支",因此需要将每个文件合并到这些文件的内部.
与更近期的工具(例如ClearCase,Plastic SCM,AccuRev,Mercurial,Git)相比,我们看到了一个迟到(便宜)的分支政策.
我们看到分支中的第一个新版本仅在分支上签入文件时创建.
这意味着当您希望重新绑定到分支的主干上发生更改时,不会发生未更改文件的合并.
TFS如何表现？
警告:我注意到当我们考虑DVCS工具时,我的术语并不准确.我认识Perforce有一种覆盖视图的圆形方式,但如果没有大量的劳动,就不会这样做.
使用cleartool我可以使用以下内容找到与标签关联的所有文件:
ct find -avobs -version "lbtype (Build-Label)" -print
如何在两个标签之间找到所有对象的更改(包括添加和删除)？
我们正在努力将我们的CC Vobs转换为GIT,我们有基本和UCM的vobs,我看过很多主题没有明确的步骤.
是否有任何工具或步骤可以保留历史和分支？