SVN版本管理规范.docx

上传人:b****5 文档编号:6946430 上传时间:2023-01-13 格式:DOCX 页数:21 大小:24.39KB
下载 相关 举报
SVN版本管理规范.docx_第1页
第1页 / 共21页
SVN版本管理规范.docx_第2页
第2页 / 共21页
SVN版本管理规范.docx_第3页
第3页 / 共21页
SVN版本管理规范.docx_第4页
第4页 / 共21页
SVN版本管理规范.docx_第5页
第5页 / 共21页
点击查看更多>>
下载资源
资源描述

SVN版本管理规范.docx

《SVN版本管理规范.docx》由会员分享,可在线阅读,更多相关《SVN版本管理规范.docx(21页珍藏版)》请在冰豆网上搜索。

SVN版本管理规范.docx

SVN版本管理规范

 

通联支付网络服务股份有限公司

技术支持中心研发部版本管理规范

 

受理市场支持部

2011年1月

 

版本控制信息

版本

日期

拟稿和修改

说明

2010-12-6

刘志毅

拟稿发布

2011-1-7

刘志毅

增加了邮件通知

2011-1-25

刘志毅

重新编写了管理规范

2011-1-28

沈德权

补充了邮件通知接受方和上线版本的编译流程

详见、和章节

2011-2-16

刘志毅

补充了紧急变更方案,详见

 

 

文档类别使用对象

文档类别

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

使用对象

该文档使用对象为技术支持中心研发部版本管理人员,以及其他相关人员。

未经许可,该文档不得提供给上述规定对象以外的人员阅读或使用。

1.引言

目的

本文档是为规范技术支持中心研发版本管理而制定的。

范围

本文档为研发部各人员提供有关版本管理规范的相关内容,包括:

1.版本标识方法

2.版本管理流程

3.角色定位

4.SVN常用命令说明

术语定义

SVN

Svn是一个开源的版本控制系统Subversion的简称

文档

上线所需的相关文档,包括部署手册,源码修改清单列表等

脚本

上线所需的相关脚本,包括编译脚本等

SQL语句

上线所需的相关SQL语句,包括建表语句等

配置管理

标识和确定系统中配置项的过程,在系统整个生存周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。

软件配置

软件的具体形态在某时刻的瞬时影像。

配置项

软件配置管理的对象称为配置项,如:

源码。

基线

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

邮件服务

需求转达,标签转达时候,需要发送邮件通知对方或者回复对方

版本控制

通过svnco把分支文件夹拷贝到开发环境进行开发,并进行版本控制

版本管理

根据需求,创建开发所需的分支

标签管理

为测试版本,上线版本创建标签

版本更新

通过svnci定期备份修改内容,或通过svnupdate更新当前所开发的源码,或通过svnmerge把主干新增内容更新至分支

版本测试

通过svnexport校验源码,进行源码的比对,测试

版本修复

对当前测试或上线版本出现的问题进行修复

版本冲突

由于修改了同一个文件,所以svnci,svnmerge以及svnup时会报错,造成了版本冲突问题。

2.版本管理

2.1版本标识方法

为了使工作规范化、统一化,各系统实行的版本标识管理方法分为:

上线版本,测试版本,修复版本,文档版本,脚本版本以及sql语句版本。

2.1.1版本标识说明

上线版本:

在生产环境上运行的正式版本。

测试版本:

在UAT环境上运行的测试版本。

修复版本:

在生产环境上用于修复当前版本的补丁版本。

以“acc”开头,版本号放后。

版本号分2节:

主版本号为上线时间点,由3节组成,每节之间以小数点(.)间隔。

如表示主版本号为,上线时间为2011年1月26日,次版本号为修复版和测试版本的组合,比如,主版本为次版本号为patch1,说明该版本为1次修复版本,如说明该版本为1次测试版本,如,说明该版本为1次修复版本的1次测试版本。

文档版本:

上线版本对应的相关文档。

以“file”开头,版本号放后。

就一个主版本号,为上线时间点,如,指文档为上线版本的文档。

注:

文档名必须是英文+数字组成,暂不支持中文名

脚本版本:

上线版本对应的相关脚本。

以”spt”为开头,版本号放后,就一个主版本号,为上线时间点,如指脚本为上线版本的脚本

sql语句版本:

上线版本对应的sql语句。

以“sql”为开头,版本号放后。

就一个主版本号,为上线时间点,如,指sql语句为上线版本的sql语句。

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.1trunk

主干文件夹,存放的是当前系统的最新源码

2.3.2branches

分支文件夹,存放的是当前开发和历史开发的分支文件夹的源码。

2.3.3tags

标签文件夹,存放的是当前上线版本和历史版本的源码。

files

文档文件夹,存放的是当前上线版本和历史版本的相关文档。

script

脚本文件夹,存放的是当前上线版本和历史版本的相关脚本。

sql

sql语句文件夹,存放的是当前上线版本和历史版本的相关sql语句。

2.4权限控制管理

为保障版本的安全性,一致性,以及防止意外修改,必须对不同的文件夹设置不同的访问权限。

文件夹权限类别:

只读权限,读写权限。

用户类别:

开发人员、测试人员、配置管理员、QA、项目经理等。

为了控制不同的使用权限,根据要求在服务器上分别建立不同的用户,针对不同的配置项所在目录分配不同的权限。

为了便于管理,应以表格的形式列出人员与管理对象的访问关系(用户权限清单)。

3.更新管理(版本升级)

版本升级原则

版本升级应严格纳入版本管理的控制之下。

应当谨慎地控制版本的升级,保障高版本的向下兼容性,或提供严格定义的升级方法。

在下面几种情况下,进行版本演化和升级:

1.当系统有重大的需求,需要较大的改进或修改时,主版本号为新版本上线时间点。

2.当系统有重大的BUG问题时,次版本要添加patch1。

3.对于改动量比较少的,如修复小问题之类的,可以从当前正在开发分支支中,进行改进或修改,和下一个新版本一起上线。

4.记录版本升级过程。

每次版本升级,都要填写版本升级记录表。

新版本的发布

版本管理流程说明

1.需求和上线点确认后,开发人员以邮件通知版本管理员,邮件内容包含以下要素:

上线点时间,开发系统,开发内容等。

版本管理员根据上线点,在对应的版本库下创建分支文件夹,并以邮件回复给开发人员。

2.开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout到开发服务器建立版本控制,进行程序开发。

3.开发人员开发完成后,把分支文件夹提交到版本库,然后从版本库中checkout出主干的工作拷贝,并把版本库中最新的分支文件合并至主干的工作拷贝,合并完成后,进行diff的比对,确认没问题后,最后把主干的工作拷贝提交至版本库。

4.开发人员以邮件通知版本管理员,告知当前开发的分支已经完成,并已更新至主干中,同时邮件内容必须含有:

部署手册,源码修改清单等相关文档,编译脚本,SQL语句。

版本管理员把当前主干版本创建标签文件夹,记录当前测试版本,以邮件回复给环境管理员、测试人员、开发人员、QA和项目经理,并附带相关文件。

5.环境管理员根据版本管理员提供的测试标签export至测试服务器进行版本测试,根据部署手册,源码修改清单等文档对源码比对,部署完成后,通知测试人员做功能测试等。

6.测试完成,测试人员以邮件通知版本管理员,版本管理员把测试标签创建为上线标签,以邮件回复给开发人员、测试人员、环境管理员、QA和项目经理,并附带相关文件,准备上线。

7.核心系统:

开发人员用上线标签的源码进行编译后,再针对上线内容进行测

试,通过后,提交上线包,相关文档给运行部上线。

管理系统:

开发人员,提交测试通过的上线包,相关文档给运行部上线。

(序号对应以下版本管理流程图)

8.测试未通过,开发人员对代码进行二次开发,待开发完成后,重复以上步骤4-7,直至上线

紧急变更方案

触发条件:

下一个上线版本已经并入了主干,需要在下一个上线版本前插入一个补丁版本。

1.变更需求和上线点确认后,开发人员以邮件通知版本管理员,邮件内容包含以下要素:

上线点时间,开发系统,开发内容等。

版本管理员根据上线点,在对应的版本库下创建分支文件夹(分支名为),并以邮件回复给开发人员。

2.开发人员根据版本管理员提供的分支文件名从版本库的分支文件夹内checkout到开发服务器建立版本控制,进行程序开发。

3.开发人员开发完成后,把分支文件夹提交到版本库,以邮件通知版本管理员,告知当前开发的分支已经完成,同时邮件内容必须含有:

部署手册,源码修改清单等相关文档,编译脚本,SQL语句。

版本管理员把分支版本创建标签文件夹,记录当前测试版本(测试标签:

),以邮件回复给环境管理员、测试人员、开发人员、QA和项目经理,并附带相关文件。

4.环境管理员根据版本管理员提供的测试标签export至测试服务器进行版本测试,根据部署手册,源码修改清单等文档对源码比对,部署完成后,通知测试人员做功能测试等。

5.测试完成,测试人员以邮件通知版本管理员,版本管理员把测试标签创建为上线标签,以邮件回复给开发人员、测试人员、环境管理员、QA和项目经理,并附带相关文件,准备上线。

6.上线成功后,开发人员把紧急修复的分支()合并入下一个上线版本的分支内,合并后无任何冲突,再提交到版本库,然后从版本库中checkout出主干的工作拷贝,并把版本库中最新的分支文件合并至主干的工作拷贝,合并完成后,进行diff的比对,确认没问题后,最后把主干的工作拷贝提交至版本库。

7.重复以上步骤4-7,直至上线

版本管理简略流程图

角色定位说明

开发人员需要做:

邮件服务,版本控制,配置项,文档,脚本,SQL语句,版本更新,版本修复,版本冲突

测试人员需要做:

邮件服务,版本编译,版本测试

版本管理人员需要做:

邮件服务,配置管理,基线,版本管理,标签管理

开发守则

请开发人员严格执行规范中的制定的版本管理流程。

上线前,必须准备好相应的文档,脚本,SQL语句,以便测试人员进行正确的测试。

在源码开发中的修改或者改进的地方,必须增加注释部分,以便测试人员进行正确的校验

在多人对同一个分支开发时,需要做好定期checkin,以保证源码无冲突

分支完成单元测试,进行集成测试时,才可合并入主干,如果要自己做集成测试,则可以把主干合并入分支进行测试。

在多个分支开发的情况下,后上线的分支必须等前上线的分支合并入主干后测试通过了,再可并入主干

后上线的分支必须定期从主干合并入分支文件夹,以保证当前开发的源码是以最新上线包的基础上开发的。

在本地的工作拷贝中合并入主干后,再用其与版本库的主干进行源码比对,确保没有任何问题之后,再checkin到版本库中。

4.备份管理

为了保证文档的最大可恢复性,要随时及定期地进行备份工作。

1、随时备份:

(1)开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。

(2)开发负责人每天要将所有源文件在本地机备份。

(3)建议备份采用循环备份。

2、定期备份

(1)备份形式为硬盘备份和光盘备份。

硬盘备份时,要备份在独立的硬盘上;光盘备份时,要将光盘存放在可靠的地方。

(2)备份周期视各系统的具体情况而定。

如果处于开发阶段,每周应对所有的源程序项进行备份,一般为每周周五;如果处于其它阶段,根据具体情况而定,但周期不能超过两周。

(3)备份要由版本管理员负责,备份原则应是保证文档的最大可恢复性。

(4)对于历史版本或某用户的特殊版本,如果无特殊原因不再进行修改的话,建议用光盘进行备份,而且应有备份盘说明文件。

该文件应该记录以下内容:

本次备份时间,备份内容,执行人。

5.SVN常用命令说明

svncheckout

命令简写

svnco

概要

svncheckoutURL[@REV]...[PATH]

描述

从版本库取出一个工作拷贝。

改变

创建一个工作拷贝。

选项:

--revision(-r)REV

--quiet(-q)

--depthARG

--force

--acceptARG

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--ignore-externals

--config-dirDIR

用途:

版本控制

例子:

$svncooutrevision20.

$ls

commit

命令简写

svnci

概要

svncommit[PATH...]

描述

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

改变

工作拷贝,版本库

选项:

--message(-m)TEXT

--file(-F)FILE

--quiet(-q)

--no-unlock

--non-recursive(-N)

--targetsFILENAME

--force-log

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--encodingENC

--config-dirDIR

用途:

版本更新

例子:

$svnci–m“备注信息”

Sending(修改的文件)

Transmittingfiledata.

Committedrevision21.

svnupdate

命令简写

svnup

概要

svnupdate[PATH...]

描述

会把版本库的修改带到工作拷贝,如果没有给定修订版本,它会把你的工作拷贝更新到HEAD修订版本,否则,它会把工作拷贝更新到你用--revision指定的修订版本。

为了保持同步,svnupdate也会删除所有在工作拷贝发现的无效锁定

对于每一个更新的项目开头都有一个表示所做动作的字符,这些字符有下面的意思:

A添加

D删除

U更新

C冲突

G合并

第一列的字符反映文件本身的更新,而第二列会反映文件属性的更新。

改变

工作拷贝2

选项:

--revision(-r)REV

--non-recursive(-N)

--quiet(-q)

--no-ignore

--incremental

--diff3-cmdCMD

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--config-dirDIR

--ignore-externals

用途:

版本更新

例子:

$svnup

Atorevision22.

svnmerge

命令简写

svnmerge

概要

svnmergesourceURL1[@N]sourceURL2[@M][WCPATH]

svnmergesourceWCPATH1@NsourceWCPATH2@M[WCPATH]

svnmerge-rN:

MSOURCE[@REV][WCPATH](最常用)

描述

第一种和第二种形式里,源路径(第一种是URL,第二种是工作拷贝路径)用修订版本号N和M指定,这是要比较的两组源文件,如果省略修订版本号,缺省是HEAD。

第三种形式,SOURCE可以是URL或者工作拷贝项目,与之对应的URL会被使用。

在修订版本号N和M的URL定义了要比较的两组源。

WCPATH是接收变化的工作拷贝路径,如果省略WCPATH,会假定缺省值“.”,除非源有相同基本名称与“.”中的某一文件名字匹配:

在这种情况下,区别会应用到那个文件。

不像svndiff,合并操作在执行时会考虑文件的祖先,当你从一个分支合并到另一个分支,而这两个分支有各自重命名的文件时,这一点会非常重要。

改变

工作拷贝

选项:

--revision(-r)REV

--non-recursive(-N)

--quiet(-q)

--force

--dry-run

--diff3-cmdCMD

--ignore-ancestry

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--config-dirDIR

用途:

版本更新

例子:

将一个分支合并回主干(假定你有一份主干的工作拷贝,分支在修订版本250创建):

$svncotrunk

$svnmerge-r250:

255,应用到主干的工作拷贝中)

Utrunk/

Utrunk/

Utrunk/

如果你的分支在修订版本23,你希望将主干的修改合并到分支,你可以在你的工作拷贝的分支上这样做:

$svnmerge-r23:

30…

svnresolved

命令简写

svnresolved

概要

svnresolvedPATH...

描述

删除工作拷贝文件或目录的“conflicted”状态。

这个程序不是语义上的改变冲突标志,它只是删除冲突相关的人造文件,从而重新允许提交;也就是说,它告诉Subversion冲突已经“解决了”。

改变

工作拷贝

选项:

--targetsFILENAME

--recursive(-R)

--quiet(-q)

--config-dirDIR

用途:

版本冲突

例子:

如果你在更新时得到冲突,你的工作拷贝会产生三个新的文件:

$svnupdate

C

Updatedtorevision31.

$ls

表示冲突,说明服务器上的改动同你的改动冲突了,你需要自己手工去解决。

如果你遇到冲突,三件事你可以选择:

“手动”合并冲突文本(检查和修改文件中的冲突标志)。

用某一个临时文件覆盖你的工作文件。

运行svnrevert来放弃所有的修改。

当你解决了的冲突,并且准备提交,运行svnresolved让你的工作拷贝知道你已经完成了所有事情。

简单介绍下手工合并冲突:

这里一个简单的例子,由于不良的交流,你和同事ttl,同时编辑了。

ttl提交了修改,当你准备更新你的版本,冲突发生了,我们不得不去修改来解决这个问题。

首先,看一下这个文件:

$cat

Toppieceofbread

Mayonnaise

Lettuce

Tomato

Provolone

<<<<<<<.mine

Salami

Mortadella

Prosciutto

=======

Sauerkraut

GrilledChicken

>>>>>>>.r2

CreoleMustard

Bottompieceofbread

小于号、等于号和大于号串是冲突标记,并不是冲突的数据,你一定要确定这些内容在下次提交之前得到删除,前两组标志中间的内容是你在冲突区所做的修改:

<<<<<<<.mine

Salami

Mortadella

Prosciutto

=======

后两组之间的是ttl提交的修改冲突:

=======

Sauerkraut

GrilledChicken

>>>>>>>.r2

通常你并不希望只是删除冲突标志和ttl的修改—当他收到三明治时,会非常的吃惊。

所以你应该走到她的办公室或是拿起电话告诉ttl,你没办法从从意大利熟食店得到想要的泡菜。

一旦你们确认了提交内容后,修改文件并且删除冲突标志。

Toppieceofbread

Mayonnaise

Lettuce

Tomato

Provolone

Salami

Mortadella

Prosciutto

CreoleMustard

Bottompieceofbread

现在运行svnresolved,你已经准备好提交了:

$svnresolved

$svncommit-m"Goaheadandusemysandwich,discardingttl'sedits."

记住,如果你修改冲突时感到混乱,你可以参考subversion生成的三个文件—包括你未作更新的文件。

你也可以使用第三方的合并工具检验这三个文件。

svnexport

命令简写

svnexport

概要

svnexport[-rREV]URL[@PEGREV][PATH]

svnexport[-rREV]PATH1[@PEGREV][PATH2]

描述

第一种从版本库导出干净工作目录树的形式是指定URL,如果指定了修订版本REV,会导出相应的版本,如果没有指定修订版本,则会导出HEAD,导出到PATH。

如果省略PATH,URL的最后一部分会作为本地目录的名字。

从工作拷贝导出干净目录树的第二种形式是指定PATH1到PATH2,所有的本地修改将会保留,但是不再版本控制下的文件不会拷贝。

改变

本地磁盘

选项:

--revision(-r)REV

--quiet(-q)

--force

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--non-recursive

--config-dirDIR

--native-eolEOL

--ignore-externals

用途:

版本测试

例子:

从版本库导出目录(打印所有的文件和目录):

$svnexport…

Exportedrevision15.

svnlog

命令简写

svnlog

概要

svnlog[PATH]

svnlogURL[PATH...]

描述

缺省目标是你的当前目录的路径,如果没有提供参数,svnlog会显示当前目录下的所有文件和目录的日志信息,你可以通过指定路径来精炼结果,一个或多个修订版本,或者是任何两个的组合。

对于本地路径的缺省修订版本范围BASE:

1。

如果你只是指定一个URL,就会打印这个URL上所有的日志信息,如果添加部分路径,只有这条路径下的URL信息会被打印,URL缺省的修订版本范围是HEAD:

1。

改变

选项:

--revision(-r)REV

--quiet(-q)

--verbose(-v)

--targetsFILENAME

--stop-on-copy

--incremental

--limitNUM

--xml

--usernameUSER

--passwordPASS

--no-auth-cache

--non-interactive

--config-dirDIR

用途:

查看版本信息,做合并参考

例子

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 法律文书 > 起诉状

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1