1、通联支付网络服务股份有限公司技术支持中心研发部版本管理规范受理市场支持部2011 年 1 月版本控制信息版本 日期 拟稿和修改 说明1.0 2010-12-6 刘志毅 拟稿发布1.1 2011-1-7 刘志毅 增加了邮件通知1.2 2011-1-25 刘志毅 重新编写了管理规范1.3 2011-1-28 沈德权补充了邮件通知接受方和上线版本的编译流程详见 2.3、2.4 和 3.2.1 章节1.4 2011-2-16 刘志毅 补充了紧急变更方案，详见 3.2.1目录文档类别使用对象 41引言 .41.1 目的 41.2 范围 41.3 术语定义 .42版本管理 62 1 版本标识方法 6211
2、 版本标识说明 62 2 目录结构 62 3 版本的存放 72.3.1 trunk .72.3.2 branches .72.3.3 tags .72.3.4 files .72.3.5 script .72.3.6 sql .82 4 权限控制管理 83更新管理（版本升级） .83.1 版本升级原则 .83.2 新版本的发布 83.2.1 版本管理流程说明 .83.2.2 版本管理简略流程图 .93.2.3 角色定位说明 .93.2.4 版本管理守则 .104备份管理 105SVN 常用命令说明 .10文档类别使用对象文档类别该文档是为技术支持中心提供一个版本管理规范性文件。使用对象该文档使
3、用对象为技术支持中心研发部版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。1引言1.1 目的本文档是为规范技术支持中心研发版本管理而制定的。1.2 范围本文档为研发部各人员提供有关版本管理规范的相关内容，包括：1. 版本标识方法2. 版本管理流程3. 角色定位4. SVN 常用命令说明1.3 术语定义SVNSvn 是一个开源的版本控制系统 Subversion 的简称文档上线所需的相关文档，包括部署手册，源码修改清单列表等脚本上线所需的相关脚本，包括编译脚本等SQL 语句上线所需的相关 SQL 语句，包括建表语句等配置管理标识和确定系统中配置项的过程
4、，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。软件配置软件的具体形态在某时刻的瞬时影像。配置项软件配置管理的对象称为配置项，如：源码。基线软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。邮件服务需求转达，标签转达时候，需要发送邮件通知对方或者回复对方版本控制通过 svn co 把分支文件夹拷贝到开发环境进行开发，并进行版本控制版本管理根据需求，创建开发所需的分支标签管理为测试版本，上线版本创建标签版本更新通过 svn ci 定期备份修改内容，或通过
5、 svn update 更新当前所开发的源码，或通过 svn merge 把主干新增内容更新至分支版本测试通过 svn export 校验源码，进行源码的比对，测试版本修复对当前测试或上线版本出现的问题进行修复版本冲突由于修改了同一个文件，所以 svn ci，svn merge 以及 svn up 时会报错，造成了版本冲突问题。2版本管理2 1 版本标识方法为了使工作规范化、统一化，各系统实行的版本标识管理方法分为：上线版本，测试版本，修复版本，文档版本，脚本版本以及 sql 语句版本。211 版本标识说明上线版本：在生产环境上运行的正式版本。测试版本：在 UAT 环境上运行的测试版本。修复版
6、本：在生产环境上用于修复当前版本的补丁版本。以“acc”开头，版本号放后。版本号分 2 节：主版本号为上线时间点，由 3 节组成，每节之间以小数点（.）间隔。如 acc_11.01.26 表示主版本号为11.01.06，上线时间为 2011 年 1 月 26 日，次版本号为修复版和测试版本的组合，比如 acc_11.01.26_patch1，主版本为 11.01.26,次版本号为 patch1，说明该版本为 1 次修复版本，如 acc_11.01.26_test1,说明该版本为 1 次测试版本，如 acc_11.01.26_patch1_test1，说明该版本为 1 次修复版本的 1 次测试版
7、本。文档版本：上线版本对应的相关文档。以“file”开头，版本号放后。就一个主版本号，为上线时间点，如file_11.01.26，指文档为上线版本 11.01.26 的文档。注：文档名必须是英文+数字组成，暂不支持中文名脚本版本：上线版本对应的相关脚本。以”spt”为开头，版本号放后，就一个主版本号，为上线时间点，如 spt_11.01.26,指脚本为上线版本 11.01.26 的脚本sql 语句版本：上线版本对应的 sql 语句。以“sql”为开头，版本号放后。就一个主版本号，为上线时间点，如sql_11.01.26，指 sql 语句为上线版本 11.01.26 的 sql 语句。2 2 目
8、录结构现以其中一个库名的目录结构举例如下：2 3 目录说明以子系统类别为主目录（即库名） 。库名 子系统 说明apsbm APSBMapsbat 清分清算apsms 商户服务平台 商户服务平台apsrisk_back APSRisk_Back 风险管理系统（后台）apsonl TGPnsp NSPtposp TPOSPcommfe 通讯前置alipay 支付宝前置bank 银行前置apsrpt APSRPT 统计报表posp POSPtest 测试使用apms APMS 商户管理系统目前暂不采用 SVN 管理apsrisk_front APSRisk_Front 风险管理系统（前端）.NET目
9、前暂不采用 SVN 管理2.3.1 trunk主干文件夹，存放的是当前系统的最新源码2.3.2 branches分支文件夹，存放的是当前开发和历史开发的分支文件夹的源码。2.3.3 tags标签文件夹，存放的是当前上线版本和历史版本的源码。2.3.4 files 文档文件夹，存放的是当前上线版本和历史版本的相关文档。2.3.5 script脚本文件夹，存放的是当前上线版本和历史版本的相关脚本。2.3.6 sqlsql 语句文件夹，存放的是当前上线版本和历史版本的相关 sql 语句。2 4 权限控制管理为保障版本的安全性，一致性，以及防止意外修改，必须对不同的文件夹设置不同的访问权限。文件夹权限
10、类别：只读权限，读写权限。用户类别：开发人员、测试人员、配置管理员、QA、项目经理等。为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。为了便于管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单） 。3更新管理（版本升级）3.1 版本升级原则版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。在下面几种情况下，进行版本演化和升级：1. 当系统有重大的需求，需要较大的改进或修改时，主版本号为新版本上线时间点。2. 当系统有重大的 BUG 问题时，次版本要添加 patch1
11、。3. 对于改动量比较少的，如修复小问题之类的，可以从当前正在开发分支支中，进行改进或修改，和下一个新版本一起上线。4. 记录版本升级过程。每次版本升级，都要填写版本升级记录表。3.2 新版本的发布3.2.1 版本管理流程说明1. 需求和上线点确认后，开发人员以邮件通知版本管理员，邮件内容包含以下要素：上线点时间，开发系统，开发内容等。版本管理员根据上线点，在对应的版本库下创建分支文件夹，并以邮件回复给开发人员。 2. 开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout 到开发服务器建立版本控制，进行程序开发。3. 开发人员开发完成后，把分支文件夹提交到版本库，然后从
12、版本库中checkout 出主干的工作拷贝，并把版本库中最新的分支文件合并至主干的工作拷贝，合并完成后，进行 diff 的比对，确认没问题后，最后把主干的工作拷贝提交至版本库。4. 开发人员以邮件通知版本管理员，告知当前开发的分支已经完成，并已更新至主干中，同时邮件内容必须含有：部署手册，源码修改清单等相关文档，编译脚本，SQL 语句。版本管理员把当前主干版本创建标签文件夹，记录当前测试版本，以邮件回复给环境管理员、测试人员、开发人员、QA 和项目经理，并附带相关文件。5. 环境管理员根据版本管理员提供的测试标签 export 至测试服务器进行版本测试，根据部署手册，源码修改清单等文档对源码比
13、对，部署完成后，通知测试人员做功能测试等。6. 测试完成，测试人员以邮件通知版本管理员，版本管理员把测试标签创建为上线标签，以邮件回复给开发人员、测试人员、环境管理员、QA 和项目经理，并附带相关文件，准备上线。7. 核心系统：开发人员用上线标签的源码进行编译后，再针对上线内容进行测试，通过后，提交上线包，相关文档给运行部上线。管理系统：开发人员，提交测试通过的上线包，相关文档给运行部上线。（序号对应以下版本管理流程图）8. 测试未通过，开发人员对代码进行二次开发，待开发完成后，重复以上步骤 4-7，直至上线紧急变更方案触发条件：下一个上线版本已经并入了主干，需要在下一个上线版本前插入一个补丁
14、版本。1. 变更需求和上线点确认后，开发人员以邮件通知版本管理员，邮件内容包含以下要素：上线点时间，开发系统，开发内容等。版本管理员根据上线点，在对应的版本库下创建分支文件夹（分支名为 acc_xx.xx.xx_patch1） ，并以邮件回复给开发人员。2. 开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout 到开发服务器建立版本控制，进行程序开发。3. 开发人员开发完成后，把分支文件夹提交到版本库，以邮件通知版本管理员，告知当前开发的分支已经完成，同时邮件内容必须含有：部署手册，源码修改清单等相关文档，编译脚本，SQL 语句。版本管理员把分支版本创建标签文件夹，记录
15、当前测试版本（测试标签：acc_xx.xx.xx_patch1_test1） ，以邮件回复给环境管理员、测试人员、开发人员、QA 和项目经理，并附带相关文件。4. 环境管理员根据版本管理员提供的测试标签 export 至测试服务器进行版本测试，根据部署手册，源码修改清单等文档对源码比对，部署完成后，通知测试人员做功能测试等。5. 测试完成，测试人员以邮件通知版本管理员，版本管理员把测试标签创建为上线标签，以邮件回复给开发人员、测试人员、环境管理员、QA 和项目经理，并附带相关文件，准备上线。6. 上线成功后，开发人员把紧急修复的分支（acc_xx.xx.xx_patch1）合并入下一个上线版本
16、的分支内,合并后无任何冲突，再提交到版本库，然后从版本库中 checkout 出主干的工作拷贝，并把版本库中最新的分支文件合并至主干的工作拷贝，合并完成后，进行 diff 的比对，确认没问题后，最后把主干的工作拷贝提交至版本库。7. 重复以上步骤 4-7，直至上线3.2.2 版本管理简略流程图3.2.3 角色定位说明开发人员需要做：邮件服务，版本控制，配置项，文档，脚本， SQL 语句，版本更新，版本修复，版本冲突测试人员需要做：邮件服务，版本编译，版本测试版本管理人员需要做：邮件服务，配置管理，基线，版本管理，标签管理3.2.4 开发守则 请开发人员严格执行规范中的制定的版本管理流程。 上线
17、前，必须准备好相应的文档，脚本，SQL 语句，以便测试人员进行正确的测试。 在源码开发中的修改或者改进的地方，必须增加注释部分，以便测试人员进行正确的校验 在多人对同一个分支开发时，需要做好定期 check in，以保证源码无冲突 分支完成单元测试，进行集成测试时，才可合并入主干，如果要自己做集成测试，则可以把主干合并入分支进行测试。 在多个分支开发的情况下，后上线的分支必须等前上线的分支合并入主干后测试通过了，再可并入主干 后上线的分支必须定期从主干合并入分支文件夹，以保证当前开发的源码是以最新上线包的基础上开发的。 在本地的工作拷贝中合并入主干后，再用其与版本库的主干进行源码比对，确保没有
18、任何问题之后，再 check in 到版本库中。4备份管理为了保证文档的最大可恢复性，要随时及定期地进行备份工作。1、随时备份：（1） 开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。（2） 开发负责人每天要将所有源文件在本地机备份。（3） 建议备份采用循环备份。2、定期备份（1） 备份形式为硬盘备份和光盘备份。硬盘备份时，要备份在独立的硬盘上；光盘备份时，要将光盘存放在可靠的地方。（2） 备份周期视各系统的具体情况而定。如果处于开发阶段，每周应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。（3） 备份要由版本管理员负责，备份原则
19、应是保证文档的最大可恢复性。（4） 对于历史版本或某用户的特殊版本，如果无特殊原因不再进行修改的话，建议用光盘进行备份，而且应有备份盘说明文件BACKUP.TXT。该文件应该记录以下内容：本次备份时间，备份内容，执行人。5SVN 常用命令说明svn checkout命令简写svn co概要svn checkout URLREV. PATH描述从版本库取出一个工作拷贝。改变创建一个工作拷贝。选项：-revision (-r) REV-quiet (-q)-depth ARG-force-accept ARG-username USER-password PASS-no-auth-cache-no
20、n-interactive-ignore-externals-config-dir DIR用途：版本控制例子：$ svn co svn:/192.168.1.29/apsbat/branches/acc_11.01.26A acc_11.01.26/aA acc_11.01.26/bA acc_11.01.26/cA acc_11.01.26/dChecked out revision 20.$ lsacc_11.01.26svn commit命令简写svn ci概要svn commit PATH.描述将修改从工作拷贝发送到版本库。改变工作拷贝，版本库选项：-message (-m) TEXT
21、-file (-F) FILE-quiet (-q)-no-unlock-non-recursive (-N)-targets FILENAME-force-log-username USER-password PASS-no-auth-cache-non-interactive-encoding ENC-config-dir DIR用途：版本更新例子：$ svn ci m “备注信息” Sending e.dll(修改的文件)Transmitting file data.Committed revision 21.svn update命令简写svn up概要svn update PATH.描
22、述会把版本库的修改带到工作拷贝，如果没有给定修订版本，它会把你的工作拷贝更新到 HEAD 修订版本，否则，它会把工作拷贝更新到你用-revision 指定的修订版本。为了保持同步，svn update 也会删除所有在工作拷贝发现的无效锁定对于每一个更新的项目开头都有一个表示所做动作的字符，这些字符有下面的意思：A 添加D 删除U 更新C 冲突G 合并第一列的字符反映文件本身的更新，而第二列会反映文件属性的更新。改变工作拷贝 2选项：-revision (-r) REV-non-recursive (-N)-quiet (-q)-no-ignore-incremental-diff3-cmd C
23、MD-username USER-password PASS-no-auth-cache-non-interactive-config-dir DIR-ignore-externals用途：版本更新例子：$ svn upA acc_01.11.26/f.txtA acc_01.11.26/g.txtD acc_01.11.26/a.txtUpdated to revision 22.svn merge命令简写svn merge概要svn merge sourceURL1N sourceURL2M WCPATHsvn merge sourceWCPATH1N sourceWCPATH2M WCP
24、ATHsvn merge -r N:M SOURCEREV WCPATH(最常用)描述第一种和第二种形式里，源路径（第一种是 URL，第二种是工作拷贝路径）用修订版本号 N 和 M 指定，这是要比较的两组源文件，如果省略修订版本号，缺省是 HEAD。 第三种形式，SOURCE 可以是 URL 或者工作拷贝项目，与之对应的 URL 会被使用。在修订版本号 N 和 M 的 URL 定义了要比较的两组源。WCPATH 是接收变化的工作拷贝路径，如果省略 WCPATH，会假定缺省值“.” ，除非源有相同基本名称与“.”中的某一文件名字匹配：在这种情况下，区别会应用到那个文件。 不像 svn diff，
25、合并操作在执行时会考虑文件的祖先，当你从一个分支合并到另一个分支，而这两个分支有各自重命名的文件时，这一点会非常重要。 改变工作拷贝选项：-revision (-r) REV-non-recursive (-N)-quiet (-q)-force-dry-run-diff3-cmd CMD-ignore-ancestry-username USER-password PASS-no-auth-cache-non-interactive-config-dir DIR用途：版本更新例子：将一个分支合并回主干（假定你有一份主干的工作拷贝，分支在修订版本 250创建）：$ svn co svn:/19
26、2.168.1.29/apsbat/trunk(首先建立主干的工作拷贝)$cd trunk$ svn merge -r 250:255 svn:/192.168.1.29/apsbat/branches/acc_11.01.26(比较acc_11.01.26 的 250 版本和 255 版本之间的差别，应用到主干的工作拷贝中)U trunk/tiny.txtU trunk /thhgttg.txtU trunk /win.txt如果你的分支在修订版本 23，你希望将主干的修改合并到分支，你可以在你的工作拷贝的分支上这样做： $ svn merge -r 23:30 svn:/192.168.1
27、.29/apsbat/trunk/U acc_11.01.26/win.txtsvn resolved命令简写svn resolved概要svn resolved PATH. 描述删除工作拷贝文件或目录的“conflicted”状态。这个程序不是语义上的改变冲突标志，它只是删除冲突相关的人造文件，从而重新允许提交；也就是说，它告诉 Subversion 冲突已经“解决了” 。改变工作拷贝选项：-targets FILENAME-recursive (-R)-quiet (-q)-config-dir DIR用途：版本冲突例子：如果你在更新时得到冲突，你的工作拷贝会产生三个新的文件：$ svn
28、updateC foo.cUpdated to revision 31.$ lsfoo.cfoo.c.minefoo.c.r30foo.c.r31C 表示冲突，说明服务器上的改动同你的改动冲突了，你需要自己手工去解决。如果你遇到冲突，三件事你可以选择： “手动”合并冲突文本（检查和修改文件中的冲突标志） 。 用某一个临时文件覆盖你的工作文件。 运行 svn revert 来放弃所有的修改。当你解决了 foo.c 的冲突，并且准备提交，运行 svn resolved 让你的工作拷贝知道你已经完成了所有事情。简单介绍下手工合并冲突：这里一个简单的例子，由于不良的交流，你和同事 ttl，同时编辑了s
29、andwich.txt。ttl 提交了修改，当你准备更新你的版本，冲突发生了，我们不得不去修改 sandwich.txt 来解决这个问题。首先，看一下这个文件：$ cat sandwich.txtTop piece of breadMayonnaiseLettuceTomatoProvolone .r2Creole MustardBottom piece of bread小于号、等于号和大于号串是冲突标记，并不是冲突的数据，你一定要确定这些内容在下次提交之前得到删除，前两组标志中间的内容是你在冲突区所做的修改： .r2通常你并不希望只是删除冲突标志和 ttl 的修改当他收到三明治时，会非常的吃
30、惊。所以你应该走到她的办公室或是拿起电话告诉 ttl，你没办法从从意大利熟食店得到想要的泡菜。一旦你们确认了提交内容后，修改文件并且删除冲突标志。Top piece of breadMayonnaiseLettuceTomatoProvoloneSalamiMortadellaProsciuttoCreole MustardBottom piece of bread现在运行 svn resolved，你已经准备好提交了：$ svn resolved sandwich.txt$ svn commit -m “Go ahead and use my sandwich, discarding ttl
31、s edits.“记住，如果你修改冲突时感到混乱，你可以参考 subversion 生成的三个文件包括你未作更新的文件。你也可以使用第三方的合并工具检验这三个文件。svn export命令简写svn export概要svn export -r REV URLPEGREV PATHsvn export -r REV PATH1PEGREV PATH2描述第一种从版本库导出干净工作目录树的形式是指定 URL，如果指定了修订版本REV，会导出相应的版本，如果没有指定修订版本，则会导出 HEAD，导出到PATH。如果省略 PATH，URL 的最后一部分会作为本地目录的名字。从工作拷贝导出干净目录树的第
32、二种形式是指定 PATH1 到 PATH2，所有的本地修改将会保留，但是不再版本控制下的文件不会拷贝。改变本地磁盘选项：-revision (-r) REV-quiet (-q)-force-username USER-password PASS-no-auth-cache-non-interactive-non-recursive-config-dir DIR-native-eol EOL-ignore-externals用途：版本测试例子：从版本库导出目录（打印所有的文件和目录）：$ svn export svn:/192.168.1.29/apsbat/tags/acc_11.01.26
33、A acc_11.01.26/testA acc_11.01.26/quizExported revision 15.svn log命令简写svn log概要svn log PATHsvn log URL PATH.描述缺省目标是你的当前目录的路径，如果没有提供参数，svn log 会显示当前目录下的所有文件和目录的日志信息，你可以通过指定路径来精炼结果，一个或多个修订版本，或者是任何两个的组合。对于本地路径的缺省修订版本范围BASE:1。 如果你只是指定一个 URL，就会打印这个 URL 上所有的日志信息，如果添加部分路径，只有这条路径下的 URL 信息会被打印， URL 缺省的修订版本范围
34、是 HEAD:1。改变无选项：-revision (-r) REV-quiet (-q)-verbose (-v)-targets FILENAME-stop-on-copy-incremental-limit NUM-xml-username USER-password PASS-no-auth-cache-non-interactive-config-dir DIR用途：查看版本信息，做合并参考例子：$ svn log-r20 | harry | 2003-01-17 22:56:19 -0600 (Fri, 17 Jan 2003) | 1 lineTweak.（-m 的备注信息）-r1
35、7 | sally | 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003) | 2 linessvn list命令简写svn ls概要svn list TARGETREV.描述列出每一个 TARGET 文件和 TARGET 目录的内容，如果 TARGET 是工作拷贝路径，会使用对应的版本库 URL。 缺省的 TARGET 是“.” ，意味着当前工作拷贝的版本库 URL。改变无选项：-revision (-r) REV-verbose (-v)-recursive (-R)-incremental-xml-username USER-password PAS
36、S-no-auth-cache-non-interactive-config-dir DIR用途：查看版本库中的文件列表例子：如果你希望在没有下载工作拷贝时察看版本库有哪些文件，svn list 会非常有用：$ svn list svn:/192.168.1.29/apsbat/trunkREADME.txtINSTALLexamples/svn diff命令简写svn di概要svn diff -r N:M TARGETREV.描述比较路径下的 2 个修订版本的区别改变无选项：-revision (-r) REV-old OLD-TARGET-new NEW-TARGET-extension
37、s (-x) “ARGS“-non-recursive (-N)-diff-cmd CMD-notice-ancestry-username USER-password PASS-no-auth-cache-non-interactive-no-diff-deleted-config-dir DIR用途：把分支合并入工作拷贝的主干中，然后使用此命令，对版本库中的主干和工作拷贝中的主干进行比对，校验修改内容是否正确例子：比较 BASE 和你的工作拷贝（svn diff 最经常的用法）：$ svn diff COMMITTERS Index: COMMITTERS=- COMMITTERS (re
38、vision 4404)+ COMMITTERS (working copy)察看你的工作拷贝对旧的修订版本的修改：$ svn diff -r 3900 COMMITTERS Index: COMMITTERS=- COMMITTERS (revision 3900)+ COMMITTERS (working copy)使用“”语法与修订版本 3000 和 35000 比较：$ svn diff svn:/192.168.1.29/apsbat/trunk/COMMITTERS3000 svn:/192.168.1.29/apsbat/trunk/COMMITTERS3500Index: COMMITTERS=- COMMITTERS (revision 3000)+ COMMITTERS (revision 3500)
