基于SVN版本控制与开发指南.doc

基于SVN版本控制与开发指南目录1 文档介绍11.1 文档目的11.2 文档范围11.3 读者对象11.4 参考文档11.5 术语与缩写解释12 SVN入门22.1 SVN介绍22.2 SVN的特性22.2.1版本化的目录22.2.2 真实的版本历史22.2.3 原子提交22.2.4 一致的数据操作22.3 SVN链接模式32.4 版本库32.5 工作拷贝32.6 修订版本32.7 SVN操作流程43团队协同开发策略43.1常用协同开发策略43.2我们的协同开发策略54 开发遵循原则54.1正确使用SVN客户端工具54.2修改前获取最新版本原则54.3 尽快释放文件锁64.4不随意偷锁64.5 不提交编译不通过的代码文件64.6 减少提交次数，加强提交注释64.7 分项目阶段的差异更新64.8 公共模块统一修改65版本控制流程75.1目标75.2原则75.3流程75.4程序目录结构85.5版本安全86日常开发指南96.1CRM项目SVN地址96.2安装后常规设置96.2.1中文界面的设置96.2.2忽略文件96.2.3配置强制注释106.3初始化版本库116.3.1直接“导入Import”116.3.2“检出Checkout”“提交Commit”126.4日常开发中的SVN操作156.4.1版本号的解释166.4.2更新(Update)工作副本166.4.3解决冲突176.4.4提交修改到仓库176.4.5比较差异(Diff)186.4.6加入(Add)新文件/新文件夹196.4.7删除、重命名、移动196.4.8取消改变(revert)206.4.9修订日志窗口216.4.10文件库浏览器22241 文档介绍1.1 文档目的本文档旨在研制团队协同开发策略、软件版本控制方案等相关内容，借助SVN版本控制系统工具，具体制定团队协同开发方式、开发准则、代码版本控制与管理等，并形成项目开发管理规范，指导项目的具体开发实施。1.2 文档范围本文档的范围包括：SVN入门、团队协同开发策略、版本控制流程、日常开发指南等。1.3 读者对象 预计读者如下：CRM项目组人员、部门其他同事、公司相关领导等。1.4 参考文档SVN使用手册1.5 术语与缩写解释u SVNSVN是Subversion的缩写，是一套免费开源的版本控制系统。u TortoiseSVNTortoiseSVN 是 Subversion 版本控制系统的一个免费开源客户端，可以超越时间的管理文件和目录。文件保存在中央版本库，除了能记住文件和目录的每次修改以外，版本库非常像普通的文件服务器。你可以将文件恢复到过去的版本，并且可以通过检查历史知道数据做了哪些修改，谁做的修改。这就是为什么许多人将 Subversion 和版本控制系统看作一种“时间机器”。u AnkhSvn不同的开发工具会有不同的svn客户端管理插件，AnKhSvn是集成在VS2008开发工具的一个Svn客户端管理工具，VS.net的开发人员可以使用该插件，可以方便的在VS开发工具上进行源码签入、签出、更新等操作。2 SVN入门2.1 SVN介绍SVN是Subversion的缩写。Subversion管理随时改动的文件和目录，以二进制格式存储所有的文件，使用高效的比较二进制差异算法来计算版本之间的改动。同时，它是一个时间机器，随时记录文件和目录的每次改动，例如：文件的增加、删除、重新排列文件等。同时SVN允许你恢复以前旧版本的数据，或者检查数据变化的历史。SVN使用类似数据库事物的方式来处理用户提交入库的过程，整个改动要么成功的被提交，要么被中断并回滚。在数据提交完之前，其他人是看不到用户提交的修改文件，你看到的要么是改动之前的状态，要么是改动之后的状态。这样的行为被称为“原子提交”。原子提交很有用，因为它能保证所有相关人员看到的总是相同的东西。原子提交过程的其中一步就是包括把你的所有改动打包为一个“修订集”（有时被称为改动集），并且再给个改动标记的修订号（绿色勾变为红色叹号）。2.2 SVN的特性2.2.1版本化的目录 SVN实现了一个可以跟踪目录树更改的“虚拟”版本化文件系统，文件和目录都有对应的版本信息。2.2.2 真实的版本历史 通过SVN你可以对文件或是目录进行增加、拷贝和改名操作，也可以新增一个具有干净历史的文件。可以实现将每一个版本都可以作为一个记忆片段定点。2.2.3 原子提交版本库采用二进制差异形式提交修改的数据内容，一系列的改动，要么全部提交到版本库，要么一个也不提交，这样可以让用户构建一个需要提交修改的逻辑块，放置部分修改提交到版本库。2.2.4 一致的数据操作SVN表示文件是建立在二进制文件区别算法基础上的，对于文本（可读）和二进制（不可读）文件具备一致的草所方式，两种类型的文件都压缩存放在版本库中。 2.3 SVN链接模式其中本地工作副本与SVN系统链接的媒介是“.svn”隐藏文件夹，.svn隐藏文件夹中包含了系统链接、版本等信息，图1-1为本地工作副本与SVN系统链接后状态，绿色勾代表文件受系统控制（后面简称：受控）标志，红色叹号为受控文件改动标志。图1-1 链接状态2.4 版本库版本库是数据的中央仓库，是Subversion的核心部分。版本库以典型的文件和目录结构形式文件系统树来保存信息。任意数量的客户端连接到Subversion版本库，读取、修改这些文件。客户端通过写数据将信息分享给其他人，通过读取数据获取别人共享的信息。严禁直接对版本库直接操作，有冲突应该在客户端解决。2.5 工作拷贝一个SVN工作拷贝是你本地机器上的一个普通目录，保存着一些文件，你可以任意的编辑文件，如果是源代码文件，你可以像平常一样编译，你的工作拷贝是你的私有工作区，在你明确的做了特定操作之前，SVN不会把你的修改与其他人的合并，也不会把你的修改展示给别人，你甚至可以拥有同一个项目的多个工作拷贝。但同时，你能操作的也只有你的工作拷贝，当你在工作拷贝作了一些修改并且确认它们工作正常之后， “提交”你的修改给项目中的其他人（通过写到版本库），如果别人发布了各自的修改，Subversion提供了手段可以把这些修改与你的工作目录进行合并（通过读取版本库）。 2.6 修订版本一个SVN commit操作可以作为一个原子事务操作发布任意数量文件和目录的修改，在你的工作拷贝里，你可以改变文件内容、删除、改名以及拷贝文件和目录，然后作为一个原子事务一起提交。 每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做一次修订（revision），每一个修订版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是0，只创建了一个空目录，没有任何内容。Subversion使用的是全局修订号。即，修订号是针对整个目录树的，而不是单个文件。每一个修订号代表了一次提交后版本库整个目录树的特定状态，另一种理解是修订号N代表版本库已经经过了N次提交。2.7 SVN操作流程图1-2 操作流程图图1-2总体概括了SVN整个操作过程：首先用户从版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。3团队协同开发策略3.1常用协同开发策略常用团队协同开发策略主要有两种：“锁定-修改-解锁” 和 “拷贝-修改-合并”，两种策略的特点分析如下：u 锁定-修改-解锁方案 许多版本控制系统使用“锁定-修改-解锁”机制解决这种问题，在这样的模型里，在一个时间段里版本库的一个文件只允许被一个人修改。“锁定-修改-解锁”模型的优点：能非常好的保证版本库中所有文件的一致性，能避免大部分的冲突。但锁定-修改-解锁模型有一点问题就是限制太多，经常会成为用户的障碍：a) 锁定可能导致管理问题；b) 锁定可能导致不必要的线性化开发；c) 锁定可能导致错误的安全状态。u 拷贝-修改-合并方案SVN版本控制系统使用“拷贝-修改-合并”模型，在这种模型里，每一个用户访问项目版本库建立一个个人工作拷贝版本库中文件和目录的本地映射。用户并行工作，修改各自的工作拷贝，最终，各个私有的拷贝合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。3.2我们的协同开发策略软件开发归结最重要的因素：“多交流”，交流贫乏冲突就会增加，没有任何系统能完全防止或解决冲突，在实践中，完全的锁定更会约束软件开发生产力。由3.1章节讨论的两种协同开发策略各有优缺点，“拷贝-修改-合并”模型感觉有不好控制，但由于我们在项目开发过程中，分工明确，模块交叉的概率较低，采用此方式用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有交迭发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少，因此运行也比较稳定。对于拷贝-修改-合并有一个很致命的缺点，就是对那些无法合并的二进制文件管理起来困难，SVN也提供了“锁定-修改-解锁”模型，用来更好的管理二进制文件，因此，综合以上论述，结合我们项目实际开发特点，我们采用两种混合版本控制协同开发策略，对于大部分模块级别文件实行“拷贝-修改-合并”策略；对于不可合并或重要公共文件采用“锁定-修改-解锁”策略。4 开发遵循原则SVN（或者其他版本控制软件）只是一个版本控制的辅助工具，不可能把所有的问题都自动解决掉。尤其，对于冲突棘手问题，因此，我们通过制定规则或优化流程来规避或较少问题发生。4.1正确使用SVN客户端工具在1.5章节介绍了我们项目中两种常用SVN客户端工具，TortoiseSVN是基于Windows文件目录管理操作方式SVN客户端软件，所有的SVN操作均在右键菜单操作完成，对于文档、图片等非项目代码行文件均使用该客户端工具完成；AnKhSvn是集成在VS开发工具上的SVN客户端插件，开发人员对项目所有的代码文件的版本控制、更新等统一在该插件上完成。4.2修改前获取最新版本原则坚持在对项目中文件修改之前，先从SVN服务器获取最新版本文件的好习惯，减少冲突发生的概率。4.3 尽快释放文件锁 在获得对指定文件加锁权限后，应尽快完成文件的修改编辑工作，处理完毕立即提交更新，并马上解锁，以免影响别人的开发。4.4不随意偷锁考虑到对重要公共模块的保护，特别是不可合并的资源文件，我们采用了“锁定-修改-解锁”策略，即同一时刻只能一个人编辑，当开发人员无法即时获得加锁文件的编辑的锁时，不能随意偷锁，以防后面提交时发生版本冲突问题，要嘛等待对方释放锁，只有在特殊情况下确认没问题才偷锁，如：由于加锁人离开后忘记解锁等。4.5 不提交编译不通过的代码文件 开发人员不要提交在本地编译运行无法通过的文件，特别是重要的公共模块，以免影响其他人员的开发。4.6 减少提交次数，加强提交注释 开发人员在日常开发过程中，应该尽量较少毫无意义提交，从而减少提交的次数，因为每次提交SVN都会有版本记录管理，每次提交，都要有详细的提交注释说明，方便后面版本追踪回溯。4.7 分项目阶段的差异更新将项目开发分为开始阶段和稳定阶段，项目开发初期，各个项目成员负责自己的文件夹（或者模块），与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹（或者模块），其他的文件夹（或者模块）可以不必关心；项目稳定阶段，也就是每天的变更量很小了，所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹（或者模块），各个项目成员在其本地编译时本地工作区的全部项目程序（或者资料）均为最新的版本，保证项目作为整体能够顺利运行。4.8 公共模块统一修改尽量保证公共文件或公共模块只有一个项目成员在编辑。举例说明：程序员A负责底层中文件MapControl地图控件，如果程序员B的工作要求他为MapControl增加方法，程序员B应该通知程序员A来增加而不是自己增加；如果此时A非常繁忙需要B自己增加，就需要B先更新本地的MapControl，然后开始修改，修改完成后立即提交并通知A更新本地的文件，通过缩短提交间隔来减少冲突。4.9 项目文件提交过滤在系统项目中，设置*.pdb bin obj等文件类型和文件夹过滤条件，保证在提交的时被忽略。5版本控制流程5.1目标l 保证各个环境(开发、测试、主干)的独立，避免相互影响；l 保证多项目分支版本控制相互独立，互不影响；l 有效进行各个项目历史程序版本管理；l 减少最终发布时合并难度；l 降低冲突处理的难度。5.2原则科学配置项目开发分支，多个版本（开发版本，测试版本，发布版本）；多次合并，尽量避免分支带来系统合并集成问题。5.3流程(1). 项目相关负责人根据项目实际规划好项目开发分支；通常trunk为开发主开发目录 ；(2). 所有项目开发人员都在trunk主干或各自分子进行开发；测试人员编写测试用例；(3). 根据需要可阶段性发布阶段性成果供测试人员进行部分模块测试，保证开发测试同步执行；(4). 系统集成阶段，如果有项目分支，将项目分支合并trunk主开发目录；(5). 开发结束，提交完整测试版本程序，供测试人员进行测试，回归测试的时候，直接从主开发目录发布新版本进行回归测试；(6). bug fix的时候我们直接在各个开发分支修改，重复(2) (6)步骤，直到一个版本/release开发测试告一段；(7). 当一个版本/release开发告一段落，代码处于冻结状态，此时应该基于当前冻结的代码库，打tag；(8). 一个版本/阶段的开发任务开始，继续在trunk或相关分支进行开发，重复(1)(8)步骤。5.4程序目录结构采用trunk主开发目录与branch分支目录组合方式，多个版本相互独立，互不影响，还能大大避免项目集成合并带来的问题，其目录结构如下：其中各个项目目录结果如下：SVN项目目录结构编号目录名称说明1trunk项目主开发目录2branches项目开发分支目录3tags项目源码历史版本发布目录4releases项目运行程序版本发布目录5.5版本安全l 除了访问授权控制外，还需要备份；l subversion控制的版本，每天晚上自动打包备份到*环境中，同时也备份到另外一台windows服务器中；l 定期清理,删除老的备份(一个月前的备份）。6日常开发指南6.1CRM项目SVN地址地址：svn:/54/project/crm6.2安装后常规设置6.2.1中文界面的设置将TortoiseSVN的操作语言设置为中文，控制文件夹使用“_SVN”以便支持A项目。6.2.2忽略文件为防止在提交操作时将不必要的文件上传到SVN服务器上，可将项目中不需要受SVN控制的文件和文件夹通过设置忽略选项的方式排除掉。常被忽略的文件有 _* obj *.db bin *.pdb *.bak。可以根据实际需要来修改忽略参数， 每个需要忽略的文件（文件夹）名称之间用空格作分隔符，需要忽略的文件夹只要写文件夹名称就行，例如 obj，忽略obj文件夹及所包含文件；_*忽略所有_（下划线）开头的文件夹及所包含文件。注意，这个设置仅对本机有效，而且对本机的所有项目的本地工作区有效，对其他项目组成员没有影响。被忽略的文件仍可以通过“添加”命令使其受SVN控制。操作界面如下图，只需将忽略参数填写在“全局忽略模式”后的文本框中即可。6.2.3配置强制注释项目负责人通过设置项目的TortoiseSVN:logminisize设置为5，以便强制注释。设置方法：在项目的本地工作区文件夹上点击鼠标右键选择“属性”，进入 Subversion标签，选中TortoiseSVN: logminisize，确保复选框“递归应用该属性”选中，取值设为5，其意思是指提交的注释最短长度为五个字。注意，这个设置对其他项目成员的也有效，但是对别的SVN客户端工具（如AnkhSVN）无效。如图：6.3初始化版本库6.3.1直接“导入Import”对要执行导入操作得项目文件夹进行如下清理：（1）把项目中不需要的文件删除。（临时文件、编译器创建的文件，比如*.obj、二进制文件等。）（2）把文件夹和子文件夹中的所有文件整理一遍。虽然你可以在导入之后再来进行重命名或删除等操作，但是还是推荐你在导入之前把你的项目整理好。在资源管理器（windows explorer）中选择项目(本地硬盘上)的根文件夹，单击鼠标右键，选择导入Import命令，跳出一个对话框：在这个对话框中你需要填写你要将项目导入仓库的URL地址（svn必须小写）。导入信息（Important Message）是用来记录日志信息的。注意：与“忽略样式exclude pattern”匹配的文件或文件夹不会被导入，除非选择了“包含忽略的文件”选项。按下“确定”按钮后，TortoiseSVN就开始把整个文件夹树（包括所有文件）导入到仓库。用来做“导入Import”操作的这个文件夹的名字不会出现在仓库中，只有文件夹中的内容会出现。注意：刚才用来做“导入Import”操作的这个文件夹并没有处于版本控制下！要获取一份处于版本控制之下的本地工作区副本，你需要对刚导入的版本做一次“检出Checkout”操作。6.3.2“检出Checkout”“提交Commit”新建一个空文件夹作为本地工作区的存放文件夹（建议与项目同名），在文件夹上（或者文件夹里）单击鼠标右键后在命令菜单中选择“检出Checkout”，出现操作窗口。注意：只能检出Checkout到一个空文件夹。把本地硬盘上的项目文件夹中的内容（不要复制项目的根文件夹）全部复制到本地工作区 文件夹中，并对文件夹中进行清理操作（同“导入Import”操作前的清理操作）。然后选择本地工作区 文件夹单击鼠标右键跳出菜单，选择命令“提交Commit”：提交对话框会显示每一个有修改的文件，包括新增的，删除的，还有没有版本控制的。如果不想“提交Commit”某个有变更的文件，只需取消勾选那个文件即可。相反，如果要提交某个未受版本控制的文件，只需勾选它就可以然后“提交Commit”即可。6.4日常开发中的SVN操作6.4.1版本号的解释SVN系统中的版本号准确应该叫做“修订版本号”，每当版本库接受了一个提交Commit，文件系统进入了一个新的状态，叫做一次修订（revision），每一个修订版本被赋予一个独一无二的、递增的自然数，这个自然数就是修订版本号。受控项目中任何一个受控文件/文件夹进行了修改提交Commit操作，项目的版本号就会提升一次，没有进行修改的文件/文件夹其版本号不会发生变化。受控项目每一个装态都包含项目的所有文件/文件夹，引起该次版本号增加的即修改了的文件/文件夹保存新副本，没有发生修改的文件/文件夹保存引用，因此项目中的文件/文件夹可能与项目的版本号不同。6.4.2更新(Update)工作副本把他人做的修改融合到自己的本地副本当中，这个把改动从服务器拿到本地的过程就是“更新Update”。“更新Update”操作可以针对一个文件，或几个被选择的文件，或某个文件夹中的所有文件。选择想要进行“更新Update”操作的文件和（或）文件夹，单击鼠标右键，在菜单中选择“更新Update”， 执行窗口显示正在“更新Update”的进度。他人做的修改会合并到自己的文件中，而自己所做的修改会被保留。如果不能合并，将会出现冲突（红色文字显示），冲突的文件图标将出现标志。命令 “更新至版本Update to Revision.” 可以使本地工作区更新到自己选择的一个特定版本。6.4.3解决冲突选择的文件，点击鼠标右键菜单中选择“编辑冲突Edit Conflict”来打开合并工具或冲突编辑器，做一些必要的修改，然后保存文件。然后选择菜单中的“已解决的Resolved”命令执行，接着提交commit修改到仓库。注意：命令“已解决的Resolved”并没有真正的解决冲突，它只不过是把“文件名称.扩展名.mine” 和 “文件名称.扩展名.r*”（r*中星号代表任意位数字，即版本号）删除，并允许你提交修改而已。因此，建议在有冲突发生时要先执行“编辑冲突Edit Conflict” 再执行“已解决的Resolved”；如果确信自己的修改是正确的，不需要保留他人的修改，可将文件名称.扩展名.mine去掉“.mine”后缀，并把“.r*”后缀的文件和“”的文件删除，然后正常“提交Commit”，版本库中将保存自己的版本。6.4.4提交修改到仓库强烈建议在提交之前，应该确认本地工作区 是最新的。可以直接作一次“更新Update”操作，或者先“检查更新Check for Modifications”看看在本地或在服务器上哪些文件修改过。如果没有这样的操作直接提交的话，很有可能出现冲突现象。“检查更新Check for Modifications”操作后的结果界面如下：如果本地工作区 是最新的，并且没有冲突，就可以提交你的修改了。选中你想要提交的任意文件或文件夹，然后选择在菜单中选择“提交Commit”在提交对话框中双击一个有修改的文件，可以启动外挂的比较工具来显示修改细节。 在按下“确定OK”按钮之后，会显示提交的进程情况。6.4.5比较差异(Diff)本地工作区 修改后，被修改的文件出现标志，选择 “比较差异Diff” 命令，可以查看该文件与版本仓库中文件具体差异，选择命令后出现对应的差异察看窗口。6.4.6加入(Add)新文件/新文件夹想把在开发过程中创建的新文件/文件夹加入到SVN控制之下，可以这样做：选中文件/文件夹（在新文件/文件夹所在父文件夹点击右键），然后在菜单中选择“添加Add”命令。不需要受SVN控制的文件请取消钩选。在把文件或文件夹加入到控制之下后，这些文件或文件夹