协同开发与cvs的使用课件

协同开发与cvs的使用(1)李鑫<delphij[at]frontfree[dot]net>2003.10.30今天将要介绍的主要内容版本控制的重要意义并行开发中的注意事项和编码规则如何支持每日构建(NightlyBuild)cvs(命令行)和WinCVS(GUI)工具的使用如何看cvsweb协同开发面临的问题代码同步和集成困难连调必须在所有代码被更新、并且能够正常编译的情况下才能进行，传统上，这一过程被安排在编码过程之后难以预期模块间的相互影响，这将为整个系统的集成造成困难难以评估每个人的工作量，这会打击项目参与者的积极性版本控制系统的主要功能保存项目文件的任何版本，并允许回退先前的任何版本比较不同版本之间的差异(diff)允许为文件创建不同的开发分支，以支持不同项目的特定需要合并不同开发者的修改(重要!)典型的单机版本控制系统是rcs(RevisionControlSystem)。cvs(并行版本控制系统)可以在单机运行，提供一般的版本控制系统的功能，供个人开发使用可以在网络上运行，允许多人协同开发开放源代码，可以被容易地定制成熟。cvs被全世界的绝大多数开放源代码项目使用，同时也包括相当多的非开放原代码软件项目。cvs(ConcurrentVersionSystem)由rcs发展而来。cvs重要的基本概念Repository(代码库):项目文件的所有历史都被保存在代码库中CVSROOT变量:cvs系统根目录的位置，后面将会介绍checkin/commit(提交):将文件的新的修改送入代码库的过程checkout/update:从代码库中取出某一特定版本的功能C#中的编码规范(断行)断行希望放在：逗号后面运算符后面，如果可能，尽可能在高级运算符后面断行之后的行的应缩进到断开的表达式开始的位置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，但具体空多少，应该在编码过程之前确定下来注释规范单行注释

//单行注释文档注释

///<summary>

///类定义...

///</summary>

等等。常用的还有<summary>,<param>以及<exception>。变量定义一般情况下，每行只定义一个变量，例如：

intlevel;//indentationlevel

intsize;//sizeoftable而避免：

inta,b;//Whatis'a'?Whatdoes'b'standfor?尽可能在定义时初始化变量接口定义标识符及其后面的(之间，不空格。例如：

publicMySample(intmyInt)类和函数的定义，{}单起一行，例如：

publicMySample(intmyInt)

{

this.myInt=myInt;

}If-else、for/foreach、while/while-do、switch、try/catch语句基本上{和这些语句的条件放在同一行case条件:单放一行冒号(:)后面的行缩进一级善用空行和空格使用空行分割不同的小型逻辑单元，例如，分割两组完成不同任务的程序段，分隔方法、属性、类的定义，等等逗号后面用空格分开，例如：

(a,b,c)

不要写成

(a,b,c)类型、标识符、数值对齐命名规则开发团队必须指定统一的命名习惯，Windows上的开发，通常会使用HungarianNotation(匈牙利命名，微软公司推荐的命名习惯)，而Unix上的命名习惯与此有很大的不同。但在同一个项目中，通常只允许一种开发习惯。命名规则请参考具体的项目组规定。善用空行和空格string name ="Mr.Ed";int myValue =5;Test aTest =Test.TestYou;作为一般开发者的准备向你的cvsrepositorymeister(cvs代码库管理员)询问CVSROOT环境变量的设置、获得访问权限，等等安装cvs客户端软件(普通的开发者只需要IDE的插件就可以了，但WinCVS或命令行的cvs能够提供更大的灵活性)准备一个工作目录，并作一次cvscheckout工作准备举例设置CVSROOT环境变量创建一个空的目录，作为“工作目录”：

mkdirD:\Workdir\MyProject执行checkout操作：

cvsco[模块名称]**如果希望checkout整个repository,可以在模块名称处填写.CVSROOT各个部分的意义:pserver::/pcvs

pserver->以口令验证身份的服务器

delphij->用户名

->cvs服务器

/pcvs->Repository位置上述信息可以从服务器管理员那里获得。pserver是比较常用的验证方式本地CVSROOT举例:local:D:\pcvs

:local:->本地cvsrepository

D:\pcvs->路径(需要首先执行cvsinit初始化)CVSROOT与本地副本在Windows上，本地的工作副本中包含了描述CVSROOT的一些数据，如服务器、用户口令，等等。对于每一份工作副本，只需要在最开始checkout的时候设置一次CVSROOT，之后的cvs操作都会依据这些描述性数据自动找到服务器、用户，等等。commitlog在提交代码时，cvs系统会要求提供发生这项修改的原因。许多管理员会配置cvs使得这些日志通过邮件发给所有相关的人员。这类邮件被称为commitmaillog可以通过cvs查阅，也可以通过cvsweb之类的工具来察看cvsweb——有效的cvs代码察看工具允许以Web方式察看文件的任意版本允许察看不同版本之间的diff(差异)允许察看代码被引入的时间、修改发生的原因，等等允许按照不同的版本分支察看代码**以下演示cvsweb的一部分界面(目录、某个文件的版本、diff)添加和删除文件添加文件

cvsadd文件名删除文件

cvsremove文件名*在commit之前，这些操作并不生效;即使文件已经被删除，仍然可以得到它们先前的版本演示WinCVS的操作以下我将演示WinCVS的操作，其中包括设置CVSROOT、初始化本地Repository、checkout、commit、add、remove、update、和冲突处理。提问时间问题：如何移动文件？cvs保存每个文件的历史(每次commit)，这些历史对于软件开发团队中的开发人员不断提高具有非常重要的意义cvs本身不提供移动文件的机制，简单地使用add+remove，将会导致未来难以追踪文件的修改解决方案：repo-copy开发者向cvsrepositorymeister(代码库管理员)提出repo-copy的申请，包括涉及的文件、移动的原因，等等meister将对应的rcs文件复制到目的位置开发者checkout代码库，此时，本地工作副本的“目的位置”将会出现那些将被移动的文件开发者使用cvsremove删除原来位置的文件，可选地，在新的位置做一次forcecommit，说明文件的移动传统开发中的编码过程开始模块开发编码过程本地调试测试、连调、修正问题后三步将反复地迭代，直到最终满意使用版本控制系统之后的编码过程每天开始工作之前，checkout一份代码修改并进行初步的测试之后，commit代码，并且，如果必要，解决代码修正的冲突简单地说，开始修改之前作checkout，确认修改基本无误之后commit*上述过程是乐观并发的，尽管cvs支持对文件上锁或配置权限上述方法的好处所有开发者使用同一份代码库，本地修改与别人的修改及时地反映在代码库中，意味着连调能够尽早地开始。改善开发者之间的沟通。修改了什么、为什么修改都在repository中反映，如果代码库管理员进行了适当的配置，这些记录(说明部分，以及对于修改的量化描述)还能够通过邮件直接发送到所有开发者上述方法的好处实际的软件工程中，两个人恰好修改同一代码的同一部分，并且有不同的想法的情况很少，因此，乐观并发保证了他们能够同时修改同一文件的不同部分，而一旦发生冲突(同时修改同一文件的同一部分，并且修改不同)，后一个commit的开发者负责合并修改。分享同一份代码库意味着能够实施每日构建，而这对于提高生产效率，使开发更具可控性具有非常重要的意义。每日构建(DailyBuild/NightlyBuild)依赖版本控制系统，测试工程师每天(是的，每天)从代码库中checkout出一份最新的快照版本测试工程师以这份源代码构建整个系统测试小组以这份编译版本(binary)进行测试每日构建的测试内容确保每日构建时的快照能够正确编译(可能需要适当回滚某些文件版本)按照详细设计检查当天提交的代码是否符合详细设计(单元测试)其他适应性测试和代码复审将这些信息反馈给编码员，并要求他们解决支持每日构建需要的额外努力保证commit的代码至少通过了本地的编译和简单的运行测试(对于提交了由于代码本身原因造成无法编译的代码的开发者，一旦影响每日构建过程，通常会要求他们立刻解决)进行功能性修改时，尽可能作到每修改一项功能就commit一次，这将减少万一出现问题时的改正难度每日构建中的代码复审此时的代码复审主要是对于代码是否符合设计要求，进行的修改是否可能造成对于其他模块的不利影响(特别是潜在的影响)代码复审员必须是拥有丰富经验的程序设计师，并且，对于整个系统的架构有非常深入的了解许多公司选择把代码复审中发现的问题私下地发给相关开发者每日构建与传统方式的比较每日构建方式中，几乎每天都有一份可以正确编译的快照开发团队中的任何人都可以进行每日构建，而测试工程师对完成每日构建之后的测试负责。传统方式中，测试构建过程被放在开发接近结束的时候通常是测试工程师完成测试构建，并分发给测试组。团队中的其他人可能并不了解构建的细节每日构建与传统方式的比较测试过程渗透到开发过程的每一步每日构建最终在工程交付前，很难再出现严重的连调问题不容易发生工期延误测试过程集中于开发的最后阶段传统方式中，交付前测试往往引起较大的震荡，如连调失败等等容易发生工期延误总结引入版本控制(我们本次演示的是cvs，但主要的思想适用于任何其他的版本控制系统)可以改善软件工程中的编码和测试过程，主要的好处体现在：为开发者之间的代码同步提供了有效的途径，通过保存代码的不同版本，开发团队能够保留过去的经验，并据此对开发过程进行改进总结每个人的工作在版本控制系统中得到了有效的体现，从而，有利于明确奖惩，从而激发开发团队的工作积极性。通过commitmail，工作人员之间能够更好的交流想法，而且由于每一个修正都必须写commitlog，有助于养成严谨的开发习惯。每日构建使得工程的进度更加容易把握，从而有助于更好地管理项目工作。总结每日构建使得测试被渗透到开发的整个过程中，这有助于尽早发现和解决问题，避免工期延误代码库中保存了开发的整个历史，万一发生版权争议这样的问题，代码库能够有效地表现代码的开发过程，做为开发原创性的重要证据谢谢大家参考文献车东，cvs命令速查手册，如何参与到Mozilla工程中来：

MurrayStokely，FreeBSD4.4交付工程：

参考文献李鑫，协作开发中的质量保证技术——并行版本控制、每日构建和交付工程

CVS–并行版本控制系统

版权声明版权所有©2003李鑫<delphij[at]frontfree[dot]net>，保留所有权力。在满足下列条件的前提下，允许重新分发修改过或未经修改的，以源代码或已编译形式存在的本软件：以源代码形式的发布必须保留未经修改的上述版权声明、本许可条件，以及其后的不承诺条款。以已编译形式的发布必须在发布