搜索
CVS使用手册（仅供内部交流使用）一、基本概念CVS是一个可以多人协同工作的文件版本管理工具，常用于源代码的管理，也可以用于其他基于文本结构的文件的历史版本管理。CVS是基于文件进行管理，并不保存目录的变更信息。保存每一个文件的每一次修改的信息，能够方便的查找到每一个文件的不同时刻的版本的内容。可以方便查找旧有版本进行比较或者回退。通过TAG记录版本的统一基准。通过分支支持多版本的开发与合并。对第三方代码的跟踪提供了支持。CVS使用中心源代码库和个人工作空间的方式。使用CVS进行管理的项目有一个中心的源代码库（Repository），然后开发人员checkout到本地的个人工作空间中进行修改，修改完毕之后将新的版本commit到中心源代码库中，其他开发人员可以将这个新的版本update到他们本地的个人工作空间中。CVS在多人协同上没有采用加锁机制（lock-modify-unlock），而是使用冲突合并机制（copy-modify-merge）。所有人可以同时修改同一个文件，后提交的人需要将别人已提交的更新合并到本地，解决不同修改之间的冲突，再提交新版本。CVS所管理的文件，每一个版本都有一个唯一的版本号，通常使用1.1、1.2的方式递增。而分支的版本号则增加两位，如1.3.1.4、1.3.1.5等。为了方便记忆，可以通过TAG的操作，为某一时刻的不同文件添加同一个版本名称。另外，可以通过某个特定的时间点的方式来指定所需的版本。二、代码修改2.1.准备工作CVS可以通过本地路径、pserver、sshtunnel的方式来访问，这里主要讨论pserver方式。为了避免每次输入cvs命令都加–d:pserver:user@host:/path的参数，可以设置CVSROOT变量，这个设置可以写入~/.bashrc或~/.bash_profile中，在执行CVS其他命令前，要先执行一下cvslogin命令：$exportCVSROOT=:pserver:username@192.168.100.2:/cvsroot/proj$cvslogin（另外，CVS服务器建立提供服务前，首先要初始化，使用$cvsinit命令（略）。）2.2.创建新项目通过CVS来管理项目时，首先要使用cvsimport命令将原始版本放入CVS中。创建新项目时要注意下列事项：（1）在原始版本所在的目录里面执行import命令。import前先去掉一些可以从其他文件中生成的中间文件。（2）import后要备份原始版本，然后checkout新版本，以后所有的修改都在checkout的版本上进行，import动作并不会把当前目录转换成checkout的版本。（3）import后要将checkout的版本和原始版本做一下diff命令（excludeCVS目录），检查是否有不恰当ignore的内容。小心一些以点开头的隐藏文件。（4）检查是否有二进制文件被误作文本文件对待，使用cvsadmin命令纠正。$pwd/work/myproj$cvsimport–m“whyimportthis”myprojsealsv_old_1_2_3$cd..;mvmyprojmyproj.ori$cvscheckoutmyproj$diff–rmyproj.orimyproj|more$tarczvfmyproj.ori.bak.xxxxxx.tar.gzmyproj.ori;rm–rfmyproj.ori$cvsadmin–kbmysub/mysubfile.datimport命令的两个最后参数分别表示vendor和release_tag。一般vendor使用seals，release_tag使用init_xxxxxxxxxx即可。如果是使用第三方代码，则需要小心使用，并且使用readme.txt文件记录好每次import和merge信息，具体见【跟踪第三方源代码】一节。import后的项目不能通过cvs命令删除，如果发现import出错，需要删除后重新import，则删除动作需要由管理员直接在代码库中进行删除。2.3.查看源代码使用一个已经存在的CVS项目时，首先将其checkout到本地。根据Seals团队习惯，在CVS项目的根目录中，有PROG_VERSION.def文件存放项目的版本，有readme.txt文件存放介绍内容，有Changelog.txt文件存放版本的重大更新，习惯在Changelog.txt文件的开头写上此CVS项目所依赖到的其他项目。$cvscheckoutmyproj$catPROG_VERSION.def;catChangelog.txt;catreadme*开发过程中，应该多执行一下update操作，及时获取其他开发者的更新，以减少可能存在的开发冲突。update的时候，文件名左边的字母的意思为：“M”表示本地有修改未commit，“P”“U”表示有其他人修改的新版本，已经更新到本地，“C”本地有修改，并且与其他开发者者的改动有冲突。update常用参数：-d表示将新增加的目录也更新到本地（缺省是不更新）；-P表示删除本地的空目录。-A命令表示去掉粘着的tag（具体见【TAG和分支】一章）$cvsupdate–d–Pcvsupdate命令可以使用–r参数更新到指定TAG和分支上，然后这个TAG和分支会附在这些文件上（cvsstatus命令可以看到），后续的update将会保持这个TAG或分支不变，不会更新到最新代码，直到update时使用–A参数为止，参考【TAG和分支】一章。使用cvsdiff命令可以检查当前版本与CVS中的版本的差异，也可以比较指定两个版本之间的差异：$cvsdiff–r1.44myfile.cpp$cvsdiff–D“3hoursago”myfile.cpp$cvsdiff–r1.42–r1.43myfile.cpp除了比较文件版本的差异，使用CVS还可以查看各个文件的具体修改日志，当前文件的状态，以及文件的各行的修改情况：$cvslogmyfile.cpp$cvsstatus–vmyfile.cpp$cvsannotatemyfile.cpptmpfile.txt另外还可以使用第三方工具可以生成统计信息和分析信息，方便查看。2.4.修改源代码源代码修改时的一些注意事项：（1）修改过程中，多执行一下cvsupdate操作，以便尽早发现冲突并解决。（2）commit的代码必须是可以编译通过的，而且最好不要有会影响其他模块运行的重大功能倒退，以免影响其他模块的开发。（3）在满足上述条件的同时，尽可能多commit，有阶段性成果就可以commit一下，以便其他开发人员尽早进行update，减少冲突。（4）commit之前使用cvsupdate和cvsdiff来检查一下需要提交的代码，commit之后使用cvsupdate来检查提交的结果。特别要注意检查是否有新增加的文件或者目录忘记使用cvsadd添加到CVS中，这是非常容易遗漏的。（5）commit的时候一定要写log信息。log信息应该简练，包含有效信息，同一任务的多个修改可以考虑使用同一个log信息，方便一些工具进行收集和汇总。（6）CVS只是工具，不能代替团队的交流。团队开发过程中应该加强前期的讨论交流，减少后期的代码冲突合并。$cvsupdate–d-P$cvsdiff–r1.44myfile.cpp$./do_my_file_edit$rmnouse.hnouse.cpp$cvsremovenouse.hnouse.cpp（这两步可以合并成cvsremove–fxxx）$cvsaddnewfile.cppnewfile.h$cvsdiff$cvsupdate–d–P$cvscommit一般要避免commit错误的代码，commit前最好先diff。如果需要将部分代码退回到某个版本，要加强沟通，讨论后再执行。主要有下列两种方法：（取回前一个版本，但不更改服务器中数据，需要commit。）$cvs–Qupdate–p–r1.3hello.chello.c或：$cvsupdate–j1.4–j1.3hello.ccvs中增加目录直接cvsadd，不需要commit，但目录里面的文件不会自动添加，需要手动逐个add后再commit。如果目录层次比较多，除了逐层add目录再add文件外，也可以使用import命令（参考【跟踪第三方源代码】一节）。$cvsimport–m“newdir”myproj/newdirsealsv_init_newdir删除文件要先删除本地文件，再执行cvsremove命令，或者直接cvsremove–f来操作。删除目录直接删除里面的文件即可，目录本身不需要删除，然后update使用-P参数可以去除空目录。CVS不支持文件和目录的改名操作。可以考虑使用先remove再add的方法，一方面比较麻烦，另一方面log信息不能延续。所以文件和目录命名时要谨慎。2.5.跟踪第三方源代码如果要使用到第三方源代码，可以通过多次import然后merge来进行。此时需要注意import时候的后两个参数（其实前一个是branch标记，后一个是tag标记），第一个参数要保持一致，一般使用厂商名，第二个参数一般使用该第三方源代码的版本号。一般来说，如果不是使用到第三方代码，那么只会import一次，后两个参数随便也无所谓。另外，使用第三方源代码时，一般也不会同时跟踪两个分支，这里暂不讨论。假设这样一个场景，我们使用了GNU的gcc的源代码，一方面对gcc的代码进行修改，另一方面又在跟进gcc代码的更新，具体过程如下：首先我们import了gcc3.4.0作为最原始的代码，然后在这些代码基础上进行修改：$targcc-3.4.0.tar.gz;cdgcc-3.4.0$cvsimport–m“gcc3.4.0”myproj/gccGNUv_gcc_3_4_0$cd..;cvscheckoutmyproj;cdmyproj;./edit_commit;$cdgcc;./edit_commit;cd..;cd..然后我们import了gcc3.4.2的代码，并且将gcc3.4.2的改动和我们的改动合并起来，合并之后的效果等价于我们直接在gcc3.4.2的基础上进行改动。合并完之后，我们还可以在此基础上继续做新的改动：$targcc-3.4.2.tar.gz;cdgcc-3.4.2$cvsimport–m“gcc3.4.2”myproj/gccGNUv_gcc_3_4_2$cd..;mkdirtmp_aa;cdtmp_aa$cvscheckout–jv_gcc_3_4_0–jv_gcc_3_4_2myproj/gcc$cdmyproj/gcc;./solve_conflict_commit;cd../..$cd..;rm–rftmp_aa$cdmyproj;cvsupdate–d–P;./edit_commit;$cdgcc;./edit_commit;cd..;cd..再来一个新的3.4.4版本的时候，也可以重复这个过程，先import，然后再合并，然后可以做新的修改：$targcc-3.4.4.tar.gz;cdgcc-3.4.4$cvsimport–m“gcc3.4.4”myproj/gccGNUv_gcc_3_4_4$cd..;mkdirtmp_bb;cdtmp_bb$cvscheckout–jv_gcc_3_4_4–jv_gcc_3_4_4myproj/gcc$cdmyproj/gcc;./solve_conflict_commit;cd../..$cd..;rm–rftmp_bb$cdmyproj;cvsupdate–d–P;./edit_commit;$cdgcc;./edit_commit;cd..;cd..三、TAG和分支3.1.TAG的使用TAG的功能是保存一个各个文件的即时的同一时间的快照。不使用TAG也可以根据某个时间点获取快照，但这个时间点比较难以确