协同开发与cvs的使用.ppt

1、协同开发与cvs的使用(1),李鑫 北京工业大学放飞技术网 2003.10.30,今天将要介绍的主要内容,版本控制的重要意义 并行开发中的注意事项和编码规则 如何支持每日构建(Nightly Build) cvs(命令行)和WinCVS(GUI)工具的使用 如何看cvsweb,协同开发面临的问题,代码同步和集成困难 连调必须在所有代码被更新、并且能够正常编译的情况下才能进行，传统上，这一过程被安排在编码过程之后 难以预期模块间的相互影响，这将为整个系统的集成造成困难 难以评估每个人的工作量，这会打击项目参与者的积极性,高质量的编码过程希望的条件,问题尽早暴露出来并被修正 代码符合统一的规范 在

2、团队范围内共享同一份统一的代码库 明确责任和奖惩,版本控制系统的主要功能,保存项目文件的任何版本，并允许回退先前的任何版本 比较不同版本之间的差异(diff) 允许为文件创建不同的开发分支，以支持不同项目的特定需要 合并不同开发者的修改(重要!) 典型的单机版本控制系统是rcs(Revision Control System)。,cvs(并行版本控制系统),可以在单机运行，提供一般的版本控制系统的功能，供个人开发使用 可以在网络上运行，允许多人协同开发 开放源代码，可以被容易地定制 成熟。cvs被全世界的绝大多数开放源代码项目使用，同时也包括相当多的非开放原代码软件项目。 cvs (Concu

3、rrent Version System)由rcs发展而来。,cvs重要的基本概念,Repository(代码库): 项目文件的所有历史都被保存在代码库中 CVSROOT变量: cvs系统根目录的位置，后面将会介绍 checkin/commit(提交): 将文件的新的修改送入代码库的过程 checkout/update: 从代码库中取出某一特定版本的功能,编码规范,通用规范 文件头部的注释说明文件的用途、最初的作者、版权等信息，非常重要的，一个$Header$符，或者，经过定制的符号(如：$Frontfree$，这个符号最终将被替换为包括 良好的缩进(根据语言不同有所差异) 避免行尾空格,C#

4、中的编码规范(断行),断行希望放在： 逗号后面 运算符后面，如果可能，尽可能在高级运算符后面 断行之后的行的应缩进到断开的表达式开始的位置,C#中断行的举例,好的风格 longMethodCall(expr1, expr2, expr3, expr4, expr5); nVar = a * b / (c - g + f) + 4 * z; 不好的风格 nVar = a * b / (c - g + f) + 4 * z;,C#中的缩进规范,使用Tab作为缩进符 在开发团队中统一Tab宽度。通常，设置为4为宜；对于代码层次数较多的代码，建议设置为2，但具体空多少，应该在编码过程之前确定下来,注释

5、规范,一般注释/* * 第一行 * 第二行 */ 重要注释(单行)/* * 非常重要的注释 */,注释规范,单行注释/ 单行注释 文档注释/ / 类定义./ 等等。常用的还有, 以及 。,变量定义,一般情况下，每行只定义一个变量，例如：int level; / indentation levelint size; / size of table 而避免：int a, b; /What is a? What does b stand for? 尽可能在定义时初始化变量,接口定义,标识符及其后面的(之间，不空格。例如：public MySample(int myInt) 类和函数的定义，单起一行，

6、例如：public MySample(int myInt)this.myInt = myInt ;,If-else、for/foreach、while/while-do、switch、try/cache语句,if、else等等，与条件的)写在同一行，中间空一格if (condition)DoSomething();. else if(condition)DoSomethingOther();. else DoSomethingOtherAgain();.,If-else、for/foreach、while/while-do、switch、try/catch语句,基本上和这些语句的条件放在同一行

7、 case 条件:单放一行 冒号(:)后面的行缩进一级,善用空行和空格,使用空行分割不同的小型逻辑单元，例如，分割两组完成不同任务的程序段，分隔方法、属性、类的定义，等等 逗号后面用空格分开，例如：(a, b, c)不要写成(a,b,c) 类型、标识符、数值对齐,命名规则,开发团队必须指定统一的命名习惯，Windows上的开发，通常会使用Hungarian Notation(匈牙利命名，微软公司推荐的命名习惯)，而Unix上的命名习惯与此有很大的不同。但在同一个项目中，通常只允许一种开发习惯。 命名规则请参考具体的项目组规定。,cvs的使用,Windows上的工具 WinCVS(图形界面) c

8、vs for Windows(命令行界面) 集成环境 Igloo(Visual S集成插件) Java CVS(JBuilder等工具内建cvs支持) Unix环境 cvs,善用空行和空格,stringname= Mr. Ed; intmyValue= 5; TestaTest= Test.TestYou;,作为一般开发者的准备,向你的cvs repository meister (cvs代码库管理员)询问CVSROOT环境变量的设置、获得访问权限，等等 安装cvs客户端软件(普通的开发者只需要IDE的插件就可以了，但WinCVS或命令行的cvs能够提供更大的灵活性) 准备一个工作目录，并作一

9、次cvs checkout,工作准备举例,设置CVSROOT环境变量 创建一个空的目录，作为“工作目录”：mkdir D:WorkdirMyProject 执行checkout操作：cvs co 模块名称 * 如果希望checkout整个repository, 可以在模块名称处填写.,WinCVS中配置cvsroot,CVSROOT各个部分的意义,:pserver:/pcvspserver - 以口令验证身份的服务器delphij - 用户名 - cvs服务器/pcvs - Repository位置 上述信息可以从服务器管理员那里获得。pserver是比较常用的验证方式,本地CVSROOT举例

10、,:local:D:pcvs:local: - 本地cvs repositoryD:pcvs - 路径(需要首先执行cvs init初始化),CVSROOT与本地副本,在Windows上，本地的工作副本中包含了描述CVSROOT的一些数据，如服务器、用户口令，等等。 对于每一份工作副本，只需要在最开始checkout的时候设置一次CVSROOT，之后的cvs操作都会依据这些描述性数据自动找到服务器、用户，等等。,检出(checkout)和提交(commit)代码,检出代码cvs co .(检出当前目录对应的所有代码) 更新代码cvs up .(更新当前目录对应的所有代码) 提交代码cvs ci

11、 .(将所有本地修改过的代码提交到代码库),commit log,在提交代码时，cvs系统会要求提供发生这项修改的原因。 许多管理员会配置cvs使得这些日志通过邮件发给所有相关的人员。这类邮件被称为commit mail log可以通过cvs查阅，也可以通过cvsweb之类的工具来察看,cvsweb有效的cvs代码察看工具,允许以Web方式察看文件的任意版本 允许察看不同版本之间的diff(差异) 允许察看代码被引入的时间、修改发生的原因，等等 允许按照不同的版本分支察看代码 *以下演示cvsweb的一部分界面(目录、某个文件的版本、diff),添加和删除文件,添加文件cvs add 文件名

12、删除文件cvs remove 文件名 * 在commit之前，这些操作并不生效; 即使文件已经被删除，仍然可以得到它们先前的版本,演示WinCVS的操作,以下我将演示WinCVS的操作，其中包括设置CVSROOT、初始化本地Repository、checkout、commit、add、remove、update、和冲突处理。,提问时间,问题：如何移动文件？,cvs保存每个文件的历史(每次commit)，这些历史对于软件开发团队中的开发人员不断提高具有非常重要的意义 cvs本身不提供移动文件的机制，简单地使用add+remove，将会导致未来难以追踪文件的修改,解决方案：repo-copy,开发

13、者向cvs repository meister (代码库管理员)提出repo-copy的申请，包括涉及的文件、移动的原因，等等 meister将对应的rcs文件复制到目的位置 开发者checkout代码库，此时，本地工作副本的“目的位置”将会出现那些将被移动的文件 开发者使用cvs remove删除原来位置的文件，可选地，在新的位置做一次force commit，说明文件的移动,传统开发中的编码过程,开始模块开发 编码过程 本地调试 测试、连调、修正问题 后三步将反复地迭代，直到最终满意,使用版本控制系统之后的编码过程,每天开始工作之前，checkout一份代码 修改并进行初步的测试之后，c

14、ommit代码，并且，如果必要，解决代码修正的冲突 简单地说，开始修改之前作checkout，确认修改基本无误之后commit *上述过程是乐观并发的，尽管cvs支持对文件上锁或配置权限,上述方法的好处,所有开发者使用同一份代码库，本地修改与别人的修改及时地反映在代码库中，意味着连调能够尽早地开始。 改善开发者之间的沟通。修改了什么、为什么修改都在repository中反映，如果代码库管理员进行了适当的配置，这些记录(说明部分，以及对于修改的量化描述)还能够通过邮件直接发送到所有开发者,上述方法的好处,实际的软件工程中，两个人恰好修改同一代码的同一部分，并且有不同的想法的情况很少，因此，乐观并

15、发保证了他们能够同时修改同一文件的不同部分，而一旦发生冲突(同时修改同一文件的同一部分，并且修改不同)，后一个commit的开发者负责合并修改。 分享同一份代码库意味着能够实施每日构建，而这对于提高生产效率，使开发更具可控性具有非常重要的意义。,每日构建(Daily Build/Nightly Build),依赖版本控制系统，测试工程师每天(是的，每天)从代码库中checkout出一份最新的快照版本 测试工程师以这份源代码构建整个系统 测试小组以这份编译版本(binary)进行测试,每日构建的测试内容,确保每日构建时的快照能够正确编译(可能需要适当回滚某些文件版本) 按照详细设计检查当天提交的

16、代码是否符合详细设计(单元测试) 其他适应性测试和代码复审 将这些信息反馈给编码员，并要求他们解决,支持每日构建需要的额外努力,保证commit的代码至少通过了本地的编译和简单的运行测试(对于提交了由于代码本身原因造成无法编译的代码的开发者，一旦影响每日构建过程，通常会要求他们立刻解决) 进行功能性修改时，尽可能作到每修改一项功能就commit一次，这将减少万一出现问题时的改正难度,每日构建中的代码复审,此时的代码复审主要是对于代码是否符合设计要求，进行的修改是否可能造成对于其他模块的不利影响(特别是潜在的影响) 代码复审员必须是拥有丰富经验的程序设计师，并且，对于整个系统的架构有非常深入的了

17、解 许多公司选择把代码复审中发现的问题私下地发给相关开发者,每日构建与传统方式的比较,每日构建方式中，几乎每天都有一份可以正确编译的快照 开发团队中的任何人都可以进行每日构建，而测试工程师对完成每日构建之后的测试负责。,传统方式中，测试构建过程被放在开发接近结束的时候 通常是测试工程师完成测试构建，并分发给测试组。团队中的其他人可能并不了解构建的细节,每日构建与传统方式的比较,测试过程渗透到开发过程的每一步 每日构建最终在工程交付前，很难再出现严重的连调问题 不容易发生工期延误,测试过程集中于开发的最后阶段 传统方式中，交付前测试往往引起较大的震荡，如连调失败等等 容易发生工期延误,总结,引入

18、版本控制(我们本次演示的是cvs，但主要的思想适用于任何其他的版本控制系统)可以改善软件工程中的编码和测试过程，主要的好处体现在： 为开发者之间的代码同步提供了有效的途径，通过保存代码的不同版本，开发团队能够保留过去的经验，并据此对开发过程进行改进,总结,每个人的工作在版本控制系统中得到了有效的体现，从而，有利于明确奖惩，从而激发开发团队的工作积极性。 通过commit mail，工作人员之间能够更好的交流想法，而且由于每一个修正都必须写commit log，有助于养成严谨的开发习惯。 每日构建使得工程的进度更加容易把握，从而有助于更好地管理项目工作。,总结,每日构建使得测试被渗透到开发的整个过程中，这有助于尽早发现和解决问题，避免工期延误 代码库中保存了开发的整个历史，万一发生版权争议这样的问题，代码库能够有效地表现代码的开发过程，做为开发原创性的重要证据,谢谢大家,参考文献,车东，cvs命令速查手册， 如何参与到Mozilla工程中来：.br/kiko/mozse/br2002/13.php Murray Stokely，FreeBSD 4.4交付工程：/murray/papers/releng.pdf,参考文献,李鑫，协作开发中的质量保证技术并行版本控制、每日构建和交付工程 CVS 并行版本控制系统http:/www.c