版本管理标准规范.doc

通联支付网络服务股份有限公司
技术支持中心研发部版本管理规范

受理市场支持部
1月

版本控制信息
版本
日期
拟稿和修改
阐明
1.0
-12-6
刘志毅
拟稿发布
1.1
-1-7
刘志毅
增长了邮件告知
1.2
-1-25
刘志毅
重新编写了管理规范
1.3
-1-28
沈德权
补充了邮件告知接受方和上线版本编译流程
详见2.3、2.4和3.2.1章节
1.4
-2-16
刘志毅
补充了紧急变更方案，详见3.2.1

目录
文档类别使用对象 4
1．引言 4
1.1目 4
1.2范畴 4
1.3术语定义 4
2．版本管理 6
2．1版本标记办法 6
2．1．1版本标记阐明 6
2．2目录构造 6
2．3版本存储 7
2.3.1 trunk 7
2.3.2 branches 7
2.3.3 tags 7
2.3.4 files 7
2.3.5 script 7
2.3.6 sql 8
2．4权限控制管理 8
3．更新管理（版本升级） 8
3.1版本升级原则 8
3.2 新版本发布 8
3.2.1 版本管理流程阐明 8
3.2.2 版本管理简略流程图 9
3.2.3 角色定位阐明 9
3.2.4 版本管理守则 10
4．备份管理 10
5．SVN惯用命令阐明 10

文档类别使用对象
文档类别

该文档是为技术支持中心提供一种版本管理规范性文献。

使用对象

该文档使用对象为技术支持中心研发部版本管理人员，以及其她有关人员。未经允许，该文档不得提供应上述规定对象以外人员阅读或使用。
1．引言
1.1目
本文档是为规范技术支持中心研发版本管理而制定。
1.2范畴
本文档为研发部各人员提供关于版本管理规范有关内容，涉及：
1. l 版本标记办法
2. l 版本管理流程
3. l 角色定位
4. l SVN惯用命令阐明
1.3术语定义
SVN
Svn是一种开源版本控制系统Subversion简称

文档
上线所需有关文档，涉及布置手册，源码修改清单列表等

脚本
上线所需有关脚本，涉及编译脚本等

SQL语句
上线所需有关SQL语句，涉及建表语句等

配备管理
标记和拟定系统中配备项过程，在系统整个生存周期内控制这些项投放和更动，记录并报告配备状态和更动规定，验证配备项完整性和对的性。

软件配备
软件详细形态在某时刻瞬时影像。

配备项
软件配备管理对象称为配备项，如：源码。

基线
软件生存周期中各开发阶段末尾标记，它作用是把各阶段工作划分更加明确化，使本来持续工作在这些点上断开，使之便于检查和必定阶段成果。

邮件服务
需求转达，标签转达时候，需要发送邮件告知对方或者回答对方

版本控制
通过svn co把分支文献夹拷贝到开发环境进行开发，并进行版本控制

版本管理
依照需求，创立开发所需分支

标签管理
为测试版本，上线版本创立标签

版本更新
通过svn ci定期备份修改内容，或通过svn update更新当前所开发源码，或通过svn merge把主干新增内容更新至分支

版本测试
通过svn export校验源码，进行源码比对，测试

版本修复
对当前测试或上线版本浮现问题进行修复
版本冲突
由于修改了同一种文献，因此svn ci，svn merge以及svn up时会报错，导致了版本冲突问题。
2．版本管理
2．1版本标记办法
为了使工作规范化、统一化，各系统实行版本标记管理办法分为：上线版本，测试版本，修复版本，文档版本，脚本版本以及sql语句版本。
2．1．1版本标记阐明
上线版本：在生产环境上运营正式版本。
测试版本：在UAT环境上运营测试版本。
修复版本：在生产环境上用于修复当前版本补丁版本。

以“acc”开头，版本号放后。版本号分2节：主版本号为上线时间点，由3节构成，每节之间以小数点（.）间隔。如acc_11.01.26表达主版本号为11.01.06，上线时间为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次测试版本。
文档版本：上线版本相应有关文档。
以“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.26sql语句。

2．2目录构造
现以其中一种库名录录构造举例如下：

2．3目录阐明
以子系统类别为主目录（即库名）。
库名
子系统
阐明
apsbm
APSBM

apsbat
清分清算

apsms
商户服务平台
商户服务平台
apsrisk_back
APSRisk_Back
风险管理系统（后台）
apsonl
TGP

nsp
NSP

tposp
TPOSP

commfe
通讯前置

alipay
支付宝前置

bank
银行前置

apsrpt
APSRPT
记录报表
posp
POSP

test

测试使用
apms
APMS
商户管理系统
当前暂不采用SVN管理
apsrisk_front
APSRisk_Front
风险管理系统（前端）.NET
当前暂不采用SVN管理

2.3.1 trunk
主干文献夹，存储是当前系统最新源码
2.3.2 branches
分支文献夹，存储是当前开发和历史开发分支文献夹源码。
2.3.3 tags
标签文献夹，存储是当前上线版本和历史版本源码。
2.3.4 files
文档文献夹，存储是当前上线版本和历史版本有关文档。
2.3.5 script
脚本文献夹，存储是当前上线版本和历史版本有关脚本。
2.3.6 sql
sql语句文献夹，存储是当前上线版本和历史版本有关sql语句。

2．4权限控制管理
为保障版本安全性，一致性，以及防止意外修改，必要对不同文献夹设立不同访问权限。
文献夹权限类别：只读权限，读写权限。
顾客类别：开发人员、测试人员、配备管理员、QA、项目经理等。
为了控制不同使用权限，依照规定在服务器上分别建立不同顾客，针对不同配备项所在目录分派不同权限。
为了便于管理，应以表格形式列出人员与管理对象访问关系（顾客权限清单）。
3．更新管理（版本升级）
3.1版本升级原则
版本升级应严格纳入版本管理控制之下。应当谨慎地控制版本升级，保障高版本向下兼容性，或提供严格定义升级办法。
在下面几种状况下，进行版本演化和升级：
1. 当系统有重大需求，需要较大改进或修改时，主版本号为新版本上线时间点。
2. 当系统有重大BUG问题时，次版本要添加patch1。
3. 对于改动量比较少，如修复小问题之类，可以从当前正在开发分支支中，进行改进或修改，和下一种新版本一起上线。
4. 记录版本升级过程。每次版本升级，都要填写版本升级登记表。
3.2 新版本发布
3.2.1 版本管理流程阐明
1. 需求和上线点确认后，开发人员以邮件告知版本管理员，邮件内容包括如下要素：上线点时间，开发系统，开发内容等。版本管理员依照上线点，在相应版本库下创立分支文献夹，并以邮件回答给开发人员。
2. 开发人员依照版本管理员提供分支文献名从版本库分支文献夹内checkout到开发服务器建立版本控制，进行程序开发。
3. 开发人员开发完毕后，把分支文献夹提交到版本库，然后从版本库中checkout出主干工作拷贝，并把版本库中最新分支文献合并至主干工作拷贝，合并完毕后，进行diff比对，确认没问题后，最后把主干工作拷贝提交至版本库。
4. 开发人员以邮件告知版本管理员，告知当前开发分支已经完毕，并已更新至主干中，同步邮件内容必要具有：布置手册，源码修改清单等有关文档，编译脚本，SQL语句。版本管理员把当前主干版本创立标签文献夹，记录当前测试版本，以邮件回答给环境管理员、测试人员、开发人员、QA和项目经理，并附带有关文献。
5. 环境管理员依照版本管理员提供测试标签export至测试服务器进行版本测试，依照布置手册，源码修改清单等文档对源码比对，布置完毕后，告知测试人员做功能测试等。
6. 测试完毕，测试人员以邮件告知版本管理员，版本管理员把测试标签创立为上线标签，以邮件回答给开发人员、测试人员、环境管理员、QA和项目经理，并附带有关文献，准备上线。
7. 核心系统：开发人员用上线标签源码进行编译后，再针对上线内容进行测
试，通过后，提交上线包，有关文档给运营部上线。
管理系统：开发人员，提交测试通过上线包，有关文档给运营部上线。
（序号相应如下版本管理流程图）

8. 测试未通过，开发人员对代码进行二次开发，待开发完毕后，重复以上环节4-7，直至上线
紧急变更方案
触发条件：下一种上线版本已经并入了主干，需要在下一种上线版本前插入一种补丁版本。
1. 变更需求和上线点确认后，开发人员以邮件告知版本管理员，邮件内容包括如下要素：上线点时间，开发系统，开发内容等。版本管理员依照上线点，在相应版本库下创立分支文献夹（分支名为acc_xx.xx.xx_patch1），并以邮件回答给开发人员。
2. 开发人员依照版本管理员提供分支文献名从版本库分支文献夹内checkout到开发服务器建立版本控制，进行程序开发。
3. 开发人员开发完毕后，把分支文献夹提交到版本库，以邮件告知版本管理员，告知当前开发分支已经完毕，同步邮件内容必要具有：布置手册，源码修改清单等有关文档，编译脚本，SQL语句。版本管理员把分支版本创立标签文献夹，记录当前测试版本（测试标签：acc_xx.xx.xx_patch1_test1），以邮件回答给环境管理员、测试人员、开发人员、QA和项目经理，并附带有关文献。
4. 环境管理员依照版本管理员提供测试标签export至测试服务器进行版本测试，依照布置手册，源码修改清单等文档对源码比对，布置完毕后，告知测试人员做功能测试等。
5. 测试完毕，测试人员以邮件告知版本管理员，版本管理员把测试标签创立为上线标签，以邮件回答给开发人员、测试人员、环境管理员、QA和项目经理，并附带有关文献，准备上线。
6. 上线成功后，开发人员把紧急修复分支（acc_xx.xx.xx_patch1）合并入下一种上线版本分支内,合并后无任何冲突，再提交到版本库，然后从版本库中checkout出主干工作拷贝，并把版本库中最新分支文献合并至主干工作拷贝，合并完毕后，进行diff比对，确认没问题后，最后把主干工作拷贝提交至版本库。
7. 重复以上环节4-7，直至上线
3.2.2 版本管理简略流程图

3.2.3 角色定位阐明
开发人员需要做：
邮件服务，版本控制，配备项，文档，脚本，SQL语句，版本更新，版本修复，版本冲突

测试人员需要做：
邮件服务，版本编译，版本测试

版本管理人员需要做：
邮件服务，配备管理，基线，版本管理，标签管理
3.2.4 开发守则
u 请开发人员严格执行规范中制定版本管理流程。
u 上线前，必要准备好相应文档，脚本，SQL语句，以便测试人员进行对的测试。
u 在源码开发中修改或者改进地方，必要增长注释某些，以便测试人员进行对的校验
u 在多人对同一种分支开发时，需要做好定期check in，以保证源码无冲突
u 分支完毕单元测试，进行集成测试时，才可合并入主干，如果要自己做集成测试，则可以把主干合并入分支进行测试。
u 在各种分支开发状况下，后上线分支必要等前上线分支合并入主干后测试通过了，再可并入主干
u 后上线分支必要定期从主干合并入分支文献夹，以保证当前开发源码是以最新上线包基本上开发。
u 在本地工作拷贝中合并入主干后，再用其与版本库主干进行源码比对，保证没有任何问题之后，再check in到版本库中。
4．备份管理
为了保证文档最大可恢复性，要随时及定期地进行备份工作。
1、 随时备份：
（1） 开发人员每天都要将自已当天修改源文献在本地机器上进行备份。
（2） 开发负责人每天要将所有源文献在本地机备份。
（3） 建议备份采用循环备份。
2、 定期备份
（1） 备份形式为硬盘备份和光盘备份。硬盘备份时，要备份在独立硬盘上；光盘备份时，要将光盘存储在可靠地方。
（2） 备份周期视各系统详细状况而定。如果处在开发阶段，每周应对所有源程序项进行备份，普通为每周周五；如果处在其他阶段，依照详细状况而定，但周期不能超过两周。
（3） 备份要由版本管理员负责，备份原则应是保证文档最大可恢复性。
（4） 对于历史版本或某顾客特殊版本，如果无特殊因素不再进行修改话，建议用光盘进行备份，并且应有备份盘阐明文献BACKUP.TXT。该文献应当记录如下内容：本次备份时间，备份内容，执行人。

5．SVN惯用命令阐明
svn checkout
命令简写
svn co

概要
svn checkout URL[@REV]... [PATH]

描述
从版本库取出一种工作拷贝。

变化
创立一种工作拷贝。

选项：
--revision (-r) REV
--quiet (-q)
--depth ARG
--force
--accept ARG
--username USER
--password PASS
--no-auth-cache
--non-interactive
--ignore-externals
--config-dir DIR

用途：
版本控制

例子：
$ svn co svn://192.168.1.29/apsbat/branches/acc_11.01.26
A acc_11.01.26/a
A acc_11.01.26/b
A acc_11.01.26/c
A acc_11.01.26/d
Checked out revision 20.
$ ls
acc_11.01.26

svn commit
命令简写
svn ci

概要
svn commit [PATH...]

描述
将修改从工作拷贝发送到版本库。

变化
工作拷贝，版本库

选项：
--message (-m) TEXT
--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...]

描述
会把版本库修改带到工作拷贝，如果没有给定修订版本，它会把你工作拷贝更新到HEAD修订版本，否则，它会把工作拷贝更新到你用--revision指定修订版本。为了保持同步，svn update也会删除所有在工作拷贝发现无效锁定
对于每一种更新项目开头均有一种表达所做动作字符，这些字符有下面意思：
A添加
D删除
U更新
C冲突
G合并
第一列字符反映文献自身更新，而第二列会反映文献属性更新。

变化
工作拷贝2

选项：
--revision (-r) REV
--non-recursive (-N)
--quiet (-q)
--no-ignore
--incremental
--diff3-cmd CMD
--username USER
--password PASS
--no-auth-cache
--non-interactive
--config-dir DIR
--ignore-externals

用途：
版本更新

例子：
$ svn up
A acc_01.11.26/f.txt
A acc_01.11.26/g.txt
D acc_01.11.26/a.txt
Updated to revision 22.

svn merge
命令简写
svn merge

概要
svn merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
svn merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
svn merge -r N:M SOURCE[@REV] [WCPATH](最惯用)

描述
第一种和第二种形式里，源途径（第一种是URL，第二种是工作拷贝途径）用修订版本号N和M指定，这是要比较两组源文献，如果省略修订版本号，缺省是HEAD。
第三种形式，SOURCE可以是URL或者工作拷贝项目，与之相应URL会被使用。在修订版本号N和MURL定义了要比较两组源。
WCPATH是接受变化工作拷贝途径，如果省略WCPATH，会假定缺省值“.”，除非源有相似基本名称与“.”中某一文献名字匹配：在这种状况下，区别会应用到那个文献。
不像svn diff，合并操作在执行时会考虑文献祖先，当你从一种分支合并到另一种分支，而这两个分支有各自重命名文献时，这一点会非常重要。

变化
工作拷贝

选项：
--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://192.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.26250版本和255版本之间差别，应用到主干工作拷贝中)
U trunk/tiny.txt
U trunk /thhgttg.txt
U trunk /win.txt

如果你分支在修订版本23，你但愿将主干修改合并到分支，你可以在你工作拷贝分支上这样做：

$ svn merge -r 23:30 svn://192.168.1.29/apsbat/trunk/
U acc_11.01.26/win.txt
…

svn resolved
命令简写
svn resolved

概要
svn resolved PATH...

描述
删除工作拷贝文献或目录“conflicted”状态。这个程序不是语义上变化冲突标志，它只是删除冲突有关人造文献，从而重新容许提交；也就是说，它告诉Subversion冲突已经“解决了”。

变化
工作拷贝

选项：
--targets FILENAME
--recursive (-R)
--quiet (-q)
--config-dir DIR

用途：
版本冲突

例子：
如果你在更新时得到冲突，你工作拷贝会产生三个新文献：
$ svn update
C foo.c
Updated to revision 31.
$ ls
foo.c
foo.c.mine
foo.c.r30
foo.c.r31
C表达冲突，阐明服务器上改动同你改动冲突了，你需要自己手工去解决。
如果你遇到冲突，三件事你可以选取：
Ø “手动”合并冲突文本（检查和修改文献中冲突标志）。
Ø 用某一种暂时文献覆盖你工作文献。
Ø 运营svn revert <filename>来放弃所有修改。
当你解决了foo.c冲突，并且准备提交，运营svn resolved让你工作拷贝懂得你已经完毕了所有事情。

简朴简介下手工合并冲突：
这里一种简朴例子，由于不良交流，你和同事ttl，同步编辑了sandwich.txt。ttl提交了修改，当你准备更新你版本，冲突发生了，咱们不得不去修改sandwich.txt来解决这个问题。一方面，看一下这个文献：

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread
不大于号、等于号和不不大于号串是冲突标记，并不是冲突数据，你一定要拟定这些内容在下次提交之前得到删除，前两组标志中间内容是你在冲突区所做修改：

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
后两组之间是ttl提交修改冲突：

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
普通你并不但愿只是删除冲突标志和ttl修改—当她收到三明治时，会非常吃惊。因此你应当走到她办公室或是拿起电话告诉ttl，你没办法从从意大利熟食店得到想要泡菜。一旦你们确认了提交内容后，修改文献并且删除冲突标志。

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread
当前运营svn resolved，你已经准备好提交了：

$ svn resolved sandwich.txt
$ svn commit -m "Go ahead and use my sandwich，discarding ttl's edits."
记住，如果你修改冲突时感到混乱，你可以参照subversion生成三个文献—涉及你未作更新文献。你也可以使用第三方合并工具检查这三个文献。

svn export
命令简写
svn export

概要
svn export [-r REV] URL[@PEGREV] [PATH]
svn export [-r REV] PATH1[@PEGREV] [PATH2]

描述
第一种从版本库导出干净工作目录树形式是指定URL，如果指定了修订版本REV，会导出相应版本，如果没有指定修订版本，则会导出HEAD，导出到PATH。如果省略PATH，URL最后一某些会作为本地目录名字。
从工作拷贝导出干净目录树第二种形式是指定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
A acc_11.01.26/test
A acc_11.01.26/quiz
…
Exported revision 15.

svn log
命令简写
svn log

概要
svn log [PATH]
svn log URL [PATH...]

描述
缺省目的是你当前目录途径，如果没有提供参数，svn log会显示当前目录下所有文献和目录日记信息，你可以通过指定途径来精炼成果，一种或各种修订版本，或者是任何两个组合。对于本地途径缺省修订版本范畴BASE:1。
如果你只是指定一种URL，就会打印这个URL上所有日记信息，如果添加某些途径，只有这条途径下URL信息会被打印，URL缺省修订版本范畴是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 | -01-17 22:56:19 -0600 (Fri，17 Jan ) | 1 line
Tweak.（-m备注信息）
------------------------------------------------------------------------
r17 | sally | -01-16 23:21:19 -0600 (Thu，16 Jan ) | 2 lines
…
svn list
命令简写
svn ls

概要
svn list [TARGET[@REV]...]

描述
列出每一种TARGET文献和TARGET目录内容，如果TARGET是工作拷贝途径，会使用相应版本库URL。
缺省TARGET是“.”，意味着当前工作拷贝版本库URL。

变化
无

选项：
--revision (-r) REV
--verbose (-v)
--recursive (-R)
--incremental
--xml
--username USER
--password PASS
--no-auth-cache
--non-interactive
--config-dir DIR

用途：
查看版本库中文献列表

例子：
如果你但愿在没有下载工作拷贝时察看版本库有哪些文献，svn list会非常有用：
$ svn list svn://192.168.1.29/apsbat/trunk
README.txt
INSTALL
examples/
…

svn diff
命令简写
svn di

概要
svn diff [-r N[:M]] [TARGET[@REV]...]

描述
比较途径下2个修订版本区别

变化
无

选项：
--revision (-r) REV
--old OLD-TARGET
--new NEW-TARGET
--extensions (-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 (revision 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/COMMITTERS@3000
svn://192.168.1.29/apsbat/trunk/COMMITTERS@3500
Index：COMMITTERS
=============================================================
--- COMMITTERS (revision 3000)
+++ COMMITTERS (revision 3500)
…