1、CVS 使用指南1 概念CVS 是 Client/Server 结构的并行版本控制系统。资源库（repository ）存在于服务器上，所有版本的数据仓库。可以把它想象成一个数据库服务器。模块 （module）在资源库上，被当成一个整体来维护的版本对象，一个模块由若干文件、目录组成。例如，可以把一个项目当成一个模块。模块可以被当成一个整体被导入（import） 、检出（checkout） 。分支（branch）一个模块的变化可以形成多个并行的分支。分支可以成为一棵树。分支可以看成整个模块的版本。主分支被称作 HEAD。标记（tag）在某一时刻，模块中所有的文件处于各自的不同版本，为了保存当前模
2、块的状态，可以对模块做一个标记。将来可以按照这个标记检出文件。相当于一个快照。分支的形成是基于标记的。一个标记可以是分支标记。标记是应用于文件的，当按照标记检出的时候，只有带某个标记的才被检出。可以对模块做标记，也可对一些文件做标记。修订版（revision）对文件修改的版本号。用系统自动用 1.2.3.6 之类的来标识。2 使用2.1 登录、注销cvs login这时候 cvs 会问密码，输入密码。如果没有任何错误信息，登录成功。成功登录后将建/.cvspass 文件，保存你的口令，以后就不用输入口令了cvs logout2.2 检出（checkout ）cvs checkout modul
3、e_name把一个模块从服务器上检出，到本地计算机上。一个模块只需要在开始使用的时候检出一次，以后使用更新。2.3 更新文件cvs update filename将文件同步到最新的版本：不指定文件名，cvs 将同步所有子目录下的文件。最好每天开始工作前或将自己的工作导入到库里前都要做一次，并养成“先同步 后修改“ 的习惯，和Virvual SourceSafe 不同，CVS 里没有文件锁定的概念，所有的冲突是在 commit 之前解决，如果你修改过程中，有其他人修改并 commit 到了库中， CVS 会通知你文件冲突。2.4 提交文件cvs commit -m “write some com
4、ments here“ file_name确认修改写入到 CVS 库里。如果不用写-m “comments“而直接确认 cvs commit file_name 的话，cvs 会自动调用系统缺省的文字编辑器 (一般是 vi)要求你写入注释。 注释的质量很重要：所以不仅必须要写，而且必须写一些比较有意义的内容：以方便其他开发人员能够很好的理解。每次只确认一个文件到 CVS 库里是一个很好的习惯，但难免有时候忘了指定文件名，把多个文件以同样注释 commit 到 CVS 库里了，以下命令可以允许你修改某个文件某个版本的注释： cvs admin -m 1.3:“write some comment
5、s here“ file_name2.5 查看状态 cvs status filename 状态报告，类似这样： File: foo.c Status: Up-to-date Working revision: 1.1.1.1 Some Date Repository revision: 1.2 /home/cvsroot/cvstest/foo.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) 这里最重要的就是 Status 栏，这里总共可能有四种状态： Up-to-date： 本地的文件与库一致。Locall
6、y Modified： 本地文件比库中文件新。Needing Patch：本地文件比库中文件旧。Needs Merge： 本地文件和库中文件都被修改了。2.6 查看修改历史和注释信息 cvs log file_name 2.7 添加文件和目录 cvs add new_file_name cvs add -kb new_file_name cvs add dir_name CVS 一般只处理文本文件，它会扩展 keyword(宏)并转换行结束符。对于图片，Word 文档等非纯文本的项目，需要使用 cvs add -kb 选项，否则有可能出现文件被破坏的情况。然后确认修改并注释 cvs ci -m
7、 “write some comments here“ new_file_name 2.8 删除文件 将某个源文件物理删除后。cvs remove file_name 然后确认修改并注释 cvs ci -m “write some comments here“ file_name 注意：很多 cvs 命令都有缩写形式： commit=ci; update=up; checkout=co; remove=rm; 2.9 修改文件名 移动文件/文件重命名 cvs 里没有 cvs move 或 cvs rename，因为这两个操作是先 cvs remove old_file_name，然后cvs a
8、dd new_file_name 实现的。 2.10 目录结构同步 如果在你 checkout 后，有人添加了新的文件或目录，你需要把他们取出来。cvs update -d 2.11 放弃本地的修改(undo) 如果修改来了本地文件，不想提交，想重新取新文件。cvs update -C filename 它会先把你的本地文件改名。建议：建议大家把 checkout 的文件缺省为 readonly,把“cvs -r“ 添加到/.cvsrc 文件中 这样，你每次修改一个文件前，先 cvs edit filename,提交后文件又变成 readonly, 如果你想放弃本地的修改，则 cvs uned
9、it filename,它会 undo,而且文件又变成 readonly。2.12 恢复到旧版本 cvs update -j1.20 -j1.15 filenames 1.20 时当前版本号，注意顺序不要反了，记住要 commit,为了保证是当前版本号，最好先lock。注意：cvs update -r1.15 file.name，这里的-r 不是版本号的意思，是给文件加了一个叫 1.15的 sticky tag 如果不小心已经加成 STICK TAG 的话：用 cvs update -A 解决 2.13 文件比较 cvs diff -c filename cvs diff -c -r1.8 -
10、r1.5 filename 2.14 锁定与解锁文件 为保证串行的修改文件。加锁：cvs admin -l files 解锁：cvs admin -u files 3 CVS 宏 CVS 缺省会对文件进行 keyword(宏)替换,在文件中加入这些关键字是个良好的工作习惯 。$Id$ 关键字是用文件名、版本、时间、作者 及代码性质替换，如果使用-l 选项取出，在Exp 后面会加上登录用户的名称。$Log$ : 你所提供的修改日志信息。 $Author$ ：存入该版本的作者。 $Locker$ : 该版本的加锁者 $State$ : 该版本的状态 Exp（试验版） , Stabe（稳定版）, R
11、el（发行版）.缺省是 Exp $Date$ : 该版本存入的时间，使用 UTC 时间格式。 $Revision$ : 该版本的版本号 $RCSfile$ : RCS 文件名 $Source$ : RCS 全路径名 $Name$ : 取回该版本的符号名 $Header$ : 相当于$ Source $ Revision$Date$Author $State$Locker$的组合 4 标签(tag)操作4.1 对当前模块设置标签cvs tag release_name module_name release_name 要简洁而含义丰富，由字母开头，加字母，数字，下划线和连字号组成，特别是不能含“
12、.”。4.2 检出有某个标签文件cvs checkout -r release_name module_name 4.3 合并cvs update -A tag 标识的文件是历史文件，不能修改，这样可在本地去除这个限制，让它和当前版本合并。5 CVS 分支管理 5.1 标定里程碑 cvs tag release_1_0 prj_dir_name 5.2 开始一个新的里程碑： cvs commit -r 2 标记所有文件开始进入 2.x 的开发 注意：CVS 里的 revsion 和软件包的发布版本可以没有直接的关系。但所有文件使用和发布版本一致的版本号比较有助于维护。 5.3 建立分支 在开发
13、项目的 2.x 版本的时候发现 1.x 有问题，但 2.x 又不敢用，则从先前标记的里程碑：release_1_0 导出一个分支 release_1_0_b2 cvs rtag -b -r release_1_0 release_1_0_bugfixes prj_dir_name -r 修饰的是 release_1_0,-b 修饰的是 release_1_0_bugfixes，cvs 的版本号将变为 4 位，以后每分一次支，版本号增加 2 位 5.4 分支并行开发 一些人先在另外一个目录下导出 release_1_0_bugfixes 这个分支：解决 1.0 中的紧急问题， cvs check
14、out -r release_1_0_bugfixes 分支是可以修改的，并自动提交到分支上去 而其他人员仍旧在项目的主干分支 2.x 上开发 5.5 tag 分支 在 release_1_0_bugfixes 上修正错误后，标记一个 1.0 的错误修正版本号 cvs tag release_1_0_bugfixes_p1 5.6 合并分支 如果 2.0 认为这些错误修改在 2.0 里也需要，也可以在 2.0 的开发目录下合并release_1_0_patch_1 中的修改到当前代码中： cvs update -j release_1_0_bugfixes 5.7 再次合并分支 如果又发现 1
15、.x 新的 bug,我在分支已经修改了，并标定了 release_1_0_patch_2,我们同样希望把它合并到主干上来 cvs update -j release_1_0_bugfixes_p1 -j release_1_0_bugfixes 它的意思是把 release_1_0_bugfixes_p1(tag)到 release_1_0_bugfixes(分支)变化了的部分合并到当前文件(主干) 否则用 6 步的方法，则以前合并的内容会重新合并 注意：此时我们使用第 5 步的结果 教训：尽早频繁的 tag,但同时不能导致 tag 泛滥，tag 在不同的分支里可以同名 5.8 锁定分支 cv
16、s admin -l r_0_2 锁定 r_0_2 分支 cvs admin -l锁定主分支 5.9 设置缺省分支 cvs admin -b r_0_2 设定 r_0_2 为缺省分支 cvs admin -b 设定主分支 5.10 删除历史记录 如果历史文件过多，或确定有几个阶段的稳定版本，我们可以删除一些历史文件，以保证cvs 的性能。cvs admin -o rev1:rev2 filename 删除 rev1 到 rev2 的版本，含这两个版本 cvs admin -o rev1:rev2 filename 删除 rev1 到 rev2 的版本，不含这两个版本 如果省略 rev1,表示删除本分支 rev2 之前的所有版本 如果省略 rev2,表示删除本分支 rev1 之后的所有版本 cvs admin -o rev filename 删除 rev 这个版本的文件 注意：有 tag 的版本不能被删除，所以 tag 很重要，而且只能删单个文件
