由于公司的項(xiàng)目前期是給外包團(tuán)隊(duì)做的，接手的時(shí)候我們自己和外包團(tuán)隊(duì)都需要更新代碼，但因?yàn)楹贤膯栴}，所以我們不能直接修改外包團(tuán)隊(duì)CVS上的代碼， CVS的版本分支問題搞的頭好大！
當(dāng)然問題圓滿解決?。。「兄x車東！?。?br />
確認(rèn)版本里程碑：多個(gè)文件各自版本號(hào)不一樣，項(xiàng)目到一定階段，可以給所有文件統(tǒng)一指定一個(gè)階段里程碑版本號(hào)，方便以后按照這個(gè)階段里程碑版本號(hào)導(dǎo)出項(xiàng)目，同時(shí)也是項(xiàng)目的多個(gè)分支開發(fā)的基礎(chǔ)。
cvs tag release_1_0
開始一個(gè)新的里程碑：
cvs commit -r 2 標(biāo)記所有文件開始進(jìn)入2.x的開發(fā)
注意：CVS里的revsion和軟件包的發(fā)布版本可以沒有直接的關(guān)系。但所有文件使用和發(fā)布版本一致的版本號(hào)比較有助于維護(hù)。
版本分支的建立
在開發(fā)項(xiàng)目的2.x版本的時(shí)候發(fā)現(xiàn)1.x有問題，但2.x又不敢用，則從先前標(biāo)記的里程碑：release_1_0導(dǎo)出一個(gè)分支 release_1_0_patch
cvs rtag -b -r release_1_0 release_1_0_patch proj_dir
一些人先在另外一個(gè)目錄下導(dǎo)出release_1_0_patch這個(gè)分支：解決1.0中的緊急問題，
cvs checkout -r release_1_0_patch
而其他人員仍舊在項(xiàng)目的主干分支2.x上開發(fā)
在release_1_0_patch上修正錯(cuò)誤后，標(biāo)記一個(gè)1.0的錯(cuò)誤修正版本號(hào)
cvs tag release_1_0_patch_1
如果2.0認(rèn)為這些錯(cuò)誤修改在2.0里也需要，也可以在2.0的開發(fā)目錄下合并release_1_0_patch_1中的修改到當(dāng)前代碼中：
cvs update -j release_1_0_patch_1