通用指令规则（有点具体了）,其实信息交换说到底就是指令.

链接:
电子支付试水企业供应链
以电子支付为切入点率先推行供应链金融线上化
支付工具升级助推企业供应链整合
当第三方介入供应链支付

Powered by MoFire

代码分支是好事,意味着代码有了后代,有了后代意味着进化.可是有的时候代码是不需要进化的.假设就目前的系统,我们有了新的idea和实现方法,为了避开对已有代码的影响,会在"基"(main trunk)的某个版本上开辟一个新的分支进行开发 - 并行开发.这种情况下,意味着新的分支不大可能会merge会"基".这是进化.

另一种情况,比较常见的做法,发布一个版本后,会同时生成一支专门用于bug fix,这里的前提是,你有可能会在"基"上重复发布,但有不想bug fix的东西被发布出去.这种情况下,当bug fix分支结束并测试通过后会把merge branch,之后关闭这条bug fix分支.

就我目前的知识来看,似乎只有这两种情况下 做分支才有意义.

常见的错误理解(我认为), 用分支来做平行开发,也就是把模块A用分支A,模块B用分支B. 这是典型的不知所谓.软件开发说白了管理的是依赖和变化.变化在这里暂且不提,如果两个模块有间接相互依赖,比如A依赖C,B也依赖C.这时候为了避免在模块A中对C修改会影响到B模块,做代码分支似乎解决了问题.但是既然C已经衍生出两个互不兼容的版本,就意味着你需要花很大的力气去把A中的C和B中的C合并,更可怕的是,可能仅仅因为C的两个不兼容的版本,你的两个模块被迫被发布为两个project.

如果没有这样的间接相互依赖, 那为啥还要分支呢? 这完全可以通过构建来实现.构建不出来是因为项目组织的有问题 - 依赖没搞清楚. sub-project是常见的方法来协调模块之间的依赖.

这种分支其实也ok,但谁能确保那些公用的代码不会被两拨程序员同时修改呢?如果改了,那 branch merge将变成噩梦. 如果分支时间长了,生米煮成熟饭了, branch merge的代价太大,就只能维护两套代码基了,而这两套代码基又有很多东西是相同的. yeah~

(alias ct /opt/rational/clearcase/sun5/bin/cleartool)

1.使用view -  setview,通常是在服务器上打开已经mount的view
ct setview clsallall_dev

2.如果view没有开启,需要通过下面这个打开:
ct startview clsallall_dev

3.查找element,比如用在检查要部署的文件有没有正确放到clearcase
find ./ -version '{lbtype_sub(label1) && !lbtype_sub(label2) }' -print
--列出打了label1而没有打label2的所有元素
find ./ -version '{version(\main\LATEST) && !lbtype_sub(label1)}' -print
--列出最新版本的元素中没有被打上label1的元素

4.打label(标签)
ct mklbtype -nc USR_BAU_SRXXX

相关资料:
Common ClearCase Practices

High-level Best Practices in SCM

Clearcase Versioning[PDF]