通联支付网络服务股份有限公司技术支持中心研发部版本管理规范
受理市场支持部
2011年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 (8)
2.3.2 branches (8)
2.3.3 tags (8)
2.3.4 files (8)
2.3.5 script (8)
2.3.6 sql (8)
2．4权限控制管理 (8)
3．更新管理（版本升级） (8)
3.1版本升级原则 (8)
3.2 新版本的发布 (9)
3.2.1 版本管理流程说明 (9)
3.2.2 版本管理简略流程图 (10)
3.2.3 角色定位说明 (11)
3.2.4 版本管理守则 (11)
4．备份管理 (11)
5．SVN常用命令说明 (12)
文档类别使用对象
文档类别
该文档是为技术支持中心提供一个版本管理规范性文件。
使用对象
该文档使用对象为技术支持中心研发部版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。
1．引言
1.1目的
本文档是为规范技术支持中心研发版本管理而制定的。
1.2范围
本文档为研发部各人员提供有关版本管理规范的相关内容，包括：
1.版本标识方法
2.版本管理流程
3.角色定位
4. 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，上线时间为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次测试版本。
文档版本：上线版本对应的相关文档。
以“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目录结构
现以其中一个库名的目录结构举例如下：
2．3目录说明
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 开发守则
◆请开发人员严格执行规范中的制定的版本管理流程。
◆上线前，必须准备好相应的文档，脚本，SQL语句，以便测试人员进行正确
的测试。
◆在源码开发中的修改或者改进的地方，必须增加注释部分，以便测试人员进
行正确的校验
◆在多人对同一个分支开发时，需要做好定期check in，以保证源码无冲突
◆分支完成单元测试，进行集成测试时，才可合并入主干，如果要自己做集成
测试，则可以把主干合并入分支进行测试。
◆在多个分支开发的情况下，后上线的分支必须等前上线的分支合并入主干后
测试通过了，再可并入主干
◆后上线的分支必须定期从主干合并入分支文件夹，以保证当前开发的源码是
以最新上线包的基础上开发的。
◆在本地的工作拷贝中合并入主干后，再用其与版本库的主干进行源码比对，
确保没有任何问题之后，再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和M的URL定义了要比较的两组源。
WCP ATH是接收变化的工作拷贝路径，如果省略WCP ATH，会假定缺省值“.”，除非源有相同基本名称与“.”中的某一文件名字匹配：在这种情况下，区别会应用到那个文件。
不像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.26的250版本和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
当你解决了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，所有的本地修改将会保留，但是不再版本控制下的文件不会拷贝。
改变
本地磁盘
--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。
改变
无
--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 line
Tweak.（-m的备注信息）
------------------------------------------------------------------------
r17 | sally | 2003-01-16 23:21:19 -0600 (Thu, 16 Jan 2003) | 2 lines
…
svn list
命令简写
svn ls
概要
svn list [TARGET[@REV]...]
描述
列出每一个TARGET文件和TARGET目录的内容，如果TARGET是工作拷贝路径，会使用对应的版本库URL。
缺省的TARGET是“.”，意味着当前工作拷贝的版本库URL。
改变
无
选项：
目录 第一章引言 (1) 1.1Subversion的介绍 (1) 1.2Subversion的特性 (1) 1.3SVN模式 (2) 1.4SVN操作流程 (3) 第二章SVN使用 (4) 2.1SVN软件安装 (4) 2.2事业部SVN库介绍 (4) 2.2.1事业部SVN库 (4) 2.2.2注册、权限申请 (5) 2.3基本操作 (5) 2.3.1操作介绍 (5) 2.4系统规使用 (18) 2.4.1规操作 (18) 2.4.2版本控制的使用 (19) 2.4.3与目录无关容 (19) 2.4.4文件夹目录名称规 (20) 2.4.5文件上传格式 (21) 2.4.6文件、数据放置 (21) 2.5日常使用问题 (21) 2.5.1版本库无响应 (21) 2.5.2中的路径 (21) 2.5.3系统库最上层打不开 (22) 2.5.4提交失败（Commit fail） (22) 2.5.5SVN文件夹无法下载 (23) 2.5.6特征图标的显示 (23) 2.5.7冲突问题解决 (24) 第三章权限申请流程 (26) 3.1权限定义 (26) 3.2申请流程 (26) 3.2.1普通权限申请 (26) 3.2.2单位权限申请 (26) 3.2.3特殊权限申请 (27)
3.3表单使用 (28) 附录 (1) 参考文献 (5)
SVN使用规 第一章引言 1.1Subversion的介绍 SVN是Subversion的缩写。Subversion管理随时改动的文件和目录，以二进制格式存储所有的文件，使用高效的比较二进制差异算法来计算版本之间的改动。同时，它是一个时间机器，随时记录文件和目录的每次改动，例如：文件的增加、删除、重新排列文件等。同时SVN允许你恢复以前旧版本的数据，或者检查数据变化的历史。 SVN使用类似数据库事物的方式来处理用户提交入库的过程，整个改动要么成功的被提交，要么被中断并回滚。在数据提交完之前，其他人是看不到用户提交的修改文件，你看到的要么是改动之前的状态，要么是改动之后的状态。这样的行为被称为“原子提交”。原子提交很有用，因为它能保证所有相关人员看到的总是相同的东西。原子提交过程的其中一步就是包括把你的所有改动打包为一个“修订集”（有时被称为改动集），并且再给个改动标记的修订号（绿色勾变为红色叹号）。 1.2Subversion的特性 1.2.1 版本化的目录 Subversion实现了一个可以跟踪目录树更改的“虚拟”版本化文件系统，文件和目录都是有版本的。 1.2.2 真实的版本历史 通过Subversion你可以对文件或是目录进行增加、拷贝和改名操作，也可以新增一个具有干净历史的文件。可以毫不夸的将每一个版本都可以作为一个记忆片段定点。 1.2.3 原子提交
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 1.版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 2.更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 3.备份管理 (12) 4.版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1.目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2.范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关 内容，包括： ●●●●版本标识方法 软件系统数据的存放文档的修改控制 文档的备份制度 1.3.术语定义 SCM 软件配置管理（Software Configuration Management）缩写SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档
SVN管理规则 编写目的：为了保存项目资料，管理项目版本。提高开发的工作效率，管理项目文件，特别制定此规定。使用范围：开发部 文件类型：程序文件技术文件作业文件外来文件质量记录表格 受控级别：保密非保密 正文内容： 一.SVN安装和使用 1：SVN使用TortoiseSVN-1.5.8.15348-win32-svn-1.5.5.msi版本。 2：请按照使用说明书的方法使用。 使用说明书目录：\\172.16.0.2\RD_Share\TortoiseSVN-1.5.8.15348-win32-svn-1.5.5目录下。 这里简单说明几个重要的使用的命令： 1)updata ：为更新SVN资料，相当于下载的功能。 2)check out ：这个命令是在收到工作流程的时候，分配的一个路径的时候，可以用这个命令把相关资料 下载到本机目录下。 3)commit ：上传修改的项目文件。 4)show log ：显示当前SVN版本，和此版本修改的信息。 二.SVN目录管理规定 Xxxx_项目名称 | |——DOC | |——user 存放相关用户DOC文件 | |——product 存放相关产品DOC文件 | |——refer 存放相关产品设计参考资料 | |——tech 存放产品技术文件 | |——test 存放产品测试文件 | |——firmware | |——main 存放产品代码 | |——test 存放产品测试代码 | |——hardware | |——main 存放产品电路设计 | |——test 存放产品测试工装电路设计 | |——release 存放产品发布的资料（针对管理部） 1）按照规定，把开发资料存放到相关的目录下。 2）文件的名称命名以“项目名称+相关文件名称”。名称不需要加上版本号。SVN将自动保存版本号。 例如： 0901_DryContact 项目，他的清单命名为《DryContact元器件清单.doc》 三.SVN日常管理规定 1）开发人员所有的项目资料必须上传SVN。
Subversion管理规范 一Subversion介绍 Subversion (Subversion)是一个时间机器，随时记录文件和目录的每次改动，例如：文件的增加、删除、重新排列文件等。同时SUBVERSION允许你恢复以前旧版本的数据，或者检查数据变化的历史。 SVN使用类似数据库事物的方式来处理用户提交入库的过程，整个改动要么成功的被提交，要么被中断并回滚。在数据提交完之前，其他人是看不到用户提交的修改文件，你看到的要么是改动之前的状态，要么是改动之后的状态。这样的行为被称为“原子提交”。原子提交很有用，因为它能保证所有相关人员看到的总是相同的东西。原子提交过程的其中一步就是包括把你的所有改动打包为
一个“修订集”（有时被称为改动集），并且再给个改动标记的修订号（绿色勾变为红色叹号）。 图 1 图1总体概括了SVN 整个操作过程：首先用户从版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 二 Subversion 的目录结构 每个SVN 版本库下需要有trunk(可用项目名做目录名)、branches 及tags 目录，trunk 表示开发时版本存放的目录，即在开发阶段的代码都提交到该目录上。branches 表示发布的版本存放的目录，即项目上线时发布的稳定版本存放在该目录中。tags 表示保存测试无问题的发布版本，不可修改。branches/tags 命名规则：项目名[_说明]_版本号。 在这需要说明下分三个目录的原因，如果项目分为一期、二期、三期等，那么一期上线时的稳定版本就应该在一期完成时将代码copy 到branches 上，这样二期开发的代码就对一期的代码没有影响，如新增的模块就不会部署到生产环境上。而branches 上的稳定的版本就是发布到生产环境上的代码，如果用户使用的过程中发现有bug ，则只要在branches 上修改该bug ，修改完bug 后再编译branches 上最新的代码发布到生产环境即可。tags 的作用是将在branches 上修改的bug 的代码合并到trank 上时创建个版本标识，以后branches 上修改的bug 代码再合并到trunk 上时就从tags 的version 到branches ，最新的version 合并到trunk ，以保证前期修改的bug 代码不会在合并。 版本库 本地工作副本
1.使用注意事项 负责而谨慎地提交自己的代码（先更新后提交） SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。 如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。 保持原子性的提交 每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug 的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 不要提交自动生成的文件 Visual Studio在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用Delete 命令从仓库中删除。这个可以使用SVN过滤功能，在设置里面设置ignore lists. 不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。 不要提交自己不明白的代码 代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。提前宣布自己的工作计划 在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 对提交的信息采用明晰的标注 +) 表示增加了功能 *) 表示对某些功能进行了更改 -) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。 b) 表示修正了具体的某个bug
SVN提交规范文件编号： SVN提交规范 第 1 页共5页
SVN提交规范文件编号： 修订记录 第 2 页共5页
SVN提交规范文件编号： 目录 1、规范的目的 (3) 2、术语和定义 (4) 3、适用范围 (4) 4、参考和引用 (4) 5、细则 (4) 6、补充说明 (5) 1、规范的目的 本规范规定在产品开发过程中涉及的代码在SVN上的提交规则，确保分类清晰、提交格式统一、 第 3 页共5页
SVN提交规范文件编号： 简洁、便于管理。 2、术语和定义 代码：包括软件开发过程中从开发商获取的源代码、自己开发的代码、针对测试反馈的bug进行修改的代码。 工作目录：软件开发人员本地主机或者编译服务器上，用于调试问题、解决BUG的源代码目录。 编译目录：软件开发人员本地主机或者编译服务器上，用于编译版本、提交代码到SVN的源代码目录。 模块名：为本次提交代码的主要模块名称，采用全大写字母标识，尽量与程序中模块的命名相同，且前后应保持一致，不应同一模块出现多种不同的命名方式。 3、适用范围 本规范适用于规范研发体系所有软件工程师的SVN提交。 4、参考和引用 5、细则 5.1 SVN注释 SVN的提交时对注释的规范： 1、注释文字可以使用中文或英文，推荐使用中文，要求都能清晰表述要表达的意思 2、注释说明符合要求的格式以及内容完整，包括如下的内容： 格式要求：注释包括2个部分，中间用“| ”隔开，第一个部分描述操作的类别；第二部分对该操作的目的、方法、可能的注意事项进行描述。第一部分的第一个词为类别关键词，具体分类和关键词如下： Vendor：供应商提供的原始代码加入SVN进行受控管理 Develop：支持新特性的开发提交代码，包括功能优化和性能提升等的相关开发工作 Bug：开发阶段完成后，各测试环节反馈的问题修改，包括测试部、现场、工厂等 Customize：客制化需求软件制作过程中代码的修改 内容完整要求：SVN提交时必须说明该操作的目的，并尽可能的对相关的实现方法或注意事项进行说明；要尽量详细、清晰的说明修改内容，不允许为空或仅使用“Fix、Mofidy”等简单字词进行备注； 其他要求：为便于检索、跟踪，推荐在注释的内容中尽可能多的包括功能特性相关的模块或特性名称 5.2 SVN提交要求 代码的提交遵循如下的规则： 1、供应商提供的代码：需在代码提交时注明对应的供应商，以及该代码支持的硬件情况进行 第 4 页共5页
竭诚为您提供优质文档/双击可除 svn管理规范,华为 篇一：svn管理规范 安生sVn管理规范 第一章总则 第一条目的 通过对具备sVn管理权限的员工进行sVn规范的落实工作，促使员工不断改善工作效率，规范操作过程，从而提高公司对sVn仓库的合理、充分、高效利用的能力。 第二条适用范围 本制度适用于浙江安生信息科技有限公司（以下简称“公司”）及下属子分公司全体员工。 第三条责任说明 对于公司离职的员工，原则上由其所在部门具备sVn管理系统管理权限人员负责清除权限，同时人事行政部必须及时通知离职员工所在部门具备sVn管理系统管理权限人员（通常为部门主管）的权限清除工作。 第二章细则 第一条库管理
1，公司的所有sVn仓库（包括杭州）将整合在统一的sVn服务器上。2，公司历史迁移库在访问uRl中以“svn-past”标记，新建库在访问uRl中以“svn”标记。 第二条权限下放原则 1，由具备系统管理员权限（可配置）的管理人员分配库管理员。2，库管理员允许多个，通常将库管理员赋给对应于某库的项目经理。3，项目经理具备分配拥有项目（对应于某库）的人员以及权限的能力。3，sVn访问时统一将 ip替换为“https://www.doczj.com/doc/c41803962.html,”，端口为90。 第三条目录规范 1，按业务领域创建库，再按区域和平台性质划分分支目录，在分支目录下管理开发分支（适用于开发部）。 2，所有新建仓库默认结构为： --branches--tags--trunk各目录下的所有子目录均不允许出现trunk、tags、branches。3，开发分支命名规范：年月日-时分秒-编号，如“20xx1223-000000-001”。4，标签命名规范：年月日-时分秒-release-编号，如 “20xx1223-000000-release-001”。 第四条其他约束 1，对于仓库目录结构的操作，一律通过sVn管理系统进行，禁止使用eclipse5，编号为branches或则tags下已存在目录数量加1的结果。svn插件或则tortoisesVn客户
1、目的： 本制度为研发部SVN配置管理的准则和依据，所有与SVN配置管理的行为都必须遵照并服从于本制度。 2、适用范围： 本制度适用于研发部全体员工。 3、控制要求和方法： 3.1 操作流程 首先用户从svn版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 3.2 帐号注册、权限申请 1. 用户帐号注册：新进员工没有SVN帐号，通过联系SVN管理员，注明申请SVN普 通帐号，管理员处理完帐号注册事宜后，通知使用并介绍使用规范。 注：普通帐号，只对目录有读取权限，无法更改。 2. 权限的申请：根据员工所参与的项目，SVN管理员对其开放相应目录的读、写权限。 3. 账号注销：员工离职后，对其账号进行注销。 3.3 操作规范 1. 每日进行开发工作之前更新代码，下班时提交代码。 2. 各员工需牢记各自的账户和密码，不得向他人透漏，严禁使用他人账户进行SVN各项操作。
3. 不要签出整个目录，除非特别必要，不应同时签出过多的项目。 4. 文件提交时要求必须提交注释，注明相关修改信息，日志信息描述的越详细越好，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 5. 代码变动及时提交，避免丢失本地修改后无法恢复。 6. 在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交，否则只在你本地能正常工作，导致其它人不能编译通过。 7. 提交之前要测试所改变的应用，测试改变后的效果是否达到预期的目的。 8. 多次检查提交的内容。提交之前应先做SVN更新或与资源库同步，注意到SVN关于冲突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别，确认它们是不是你真正想要提交的。 9. 如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 10. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。 11. 提前宣布修改计划。当你计划进行修改，需要影响到SVN里的许多文件时，先通过邮件或者当面通知其他开发者。例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备，也会对修改提出意见和建议。 12. 每次提交尽量是一个最小粒度的修改。比如一个小功能提交一次。 13. 不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。 14. 提交时注意不要提交本地自动生成的文件，提交的文件必须是开发者共用的程序文件，程序编译中产生的中间文件或文件夹，如/Debug/、/Release/、*.ncb、*.obj、*.o、Thumbs.db、/build/、*.class、/classes/、/data/等不要提交到SVN里。 15. SVN管理员需对SVN的所有项目定期备份。 16. SVN的资料不允许公开给其他部门人员，确实要分发的，必须通过总经理同意。 重要说明文件要求: 硬件开发：
沃支付SVN版知识库管理办法 （试行版） 2012-5-13
修改历史
目录 目录 第一条.目标和职责 (4) 第二条.知识库内容范围 (4) 第三条.svn搭建方案 (5) 第四条.权限管理 (7)
第一条.目标和职责 1、为确保公司产品和平台建设过程透明化，使得产品建设团队能够有效把控平台建设状况， 同时，也为持续提升平台质量，持续积累业务方案和技术知识，特建立沃支付知识库。 除此之外，沃支付知识库也可作为全公司流程制度，规范、规划、公告等文档的共享平 台。 2、全公司各部门或业务单元对知识库的持续建设承担职责。其中，产品建设知识内容由产 品团队和技术团队各业务单元分别维护，各部门或业务单元的公开性文档各自分别维护。 3、为了保证知识库的建设有序、知识合理组织、有效运行，特设立知识库管理岗（兼职）， 负责知识库建设方案制定和维护、知识库安全运行保障、知识库用户和权限管理、知识 库使用说明和帮助等工作。 第二条.知识库内容范围 1、业务及技术规范：包括支付公司系统的业务规范、业务模型、总体架构和技术规范。其 中： ●业务规范根据产品线架构分别描述产品线以及产品的功能要求、业务流程、规则以 及相关非功能需求； ●业务模型是在业务规范的基础上形成的业务实体描述以及实体之间的关系描述，例 如：客户模型，用户模型，账户模型，产品模型，安全模型等等； ●总体架构是为了实现业务规范和业务模型相关要求，从平台建设维度对IT设施的规 划、平台及系统职能界定和分配、平台及系统之间关系描述、数据分布及物理部署 规划要求。 ●技术规范根据产品线和平台架构分别描述各子平台的技术实现要求，其中包含业务 模型、架构以及各功能的技术实现要求等。 2、产品需求：包括产品/业务需求文档、产品/业务需求分析文档。在此需要说明一下产品 需求和业务规范的的关系，由于支付公司产品具有互联网特色，产品需求文档先行发布， 后期业务逐渐稳定后再形成业务规范，为了便于后期业务规范的整理，建议产品需求文 档在编写时向业务规范的编写要求靠近。 3、产品总体设计，包括平台总体设计说明文档以及相关参考资料，以架构版本为纬度分别
版本管理规范 一、版本管理办法 1.1目的 按照一定的规则保存项目源程序的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到项目各个板块的任何版本。为保障公司源代码和开发文档安全不被泄漏，保证选代码的完整性，明确源代码控制管理流程，特制定此管理办法。 1.2适用部门 本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 1.3管理部门 源代码直接控制管理部门为软件部。 1.4控制范围 本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.5角色与职责 所有项目成员都必须遵照版本控制规则操作各个项目板块。 1.6版本管理工具Virsual SVN 用此工具对项目开始阶段的开发，和项目中期的变更进行版本的管理。避免发生版本丢失或混淆等现象，详细使用方法见：《Virsual SVN操作细则》 1.7项目各板块版本变迁规则 各板块的状态有3种：“草稿”（Dralt）、“正式发布”（Released）和“正在修改”（Changing） 各板块状态变迁如图所示： 各板块刚建立时其状态为“草稿”。各板块通过评审（试用）后，其状态变为“正式发布”。此后若更改各板块源代码，必须填写“版本变更情况表”及“版本变更状态跟踪表”，且版本状态变为“正在修改”，修改后通过审批（试用）其状态又为“正式发布”。以此循环。 二、SVN管理规范 2.1帐号密码的配发规则 根据岗位需要，针对不同人员，设置不同权限。遇岗位变更，随时增加删除权限。用户名：为姓名的‘姓’的全拼音+‘名’的开头拼音。 密码：一人一密码。 2.2上传文件注意事项 1.修改后的文件及文件夹的名字，跟修改前的必须同名，否则识别不了，当成新增
SVN使用规范 版本记录 序号版本修改内容修改人/日期审核人/日期批准人/日期1 2 编写目的：为了保存项目资料，管理项目版本。提高开发的工作效率，管理项目文件。 使用范围：研发部 文件类型：源代码；技术文档；记录文档； 受控级别：保密；非保密； SVN目录申请： 需项目负责人通过邮件向管理员申请，并抄送给部门经理，经部门经理同意后，方可开通账号及权限。 日常管理规定： 1）开发人员所有的项目资料必须上传SVN。 2）开发人员工作开展的时候，必须有SVN地址来CHECK OUT本机开展工作。 3）开发人员在上传SVN的时候，必须详细写上该版本的修改内容。且内容必须大于10个字符。 4）开发人员每天下班前，把工作的内容上传SVN。 5） SVN的资料不对外公开。确实需要分发的，必须通过部门领导同意。 6）使用者需紧记个人账号密码，保证SVN使用安全；多次忘记密码者，需接受相就惩罚。7）不能向项目外的同事分发自身所负责项目的SVN内容。 8）如查实员工向不必要的人员分发SVN内容，一律作开除并且追究相关责任处理。 注意事项： 1）负责而谨慎地提交自己的代码（先更新后提交） SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且通过自测之后，谨慎地提交。如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起自测保证解决冲突之后，程序不会影响其他功能。如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。 2）保持原子性的提交
每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug 并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。3）不要提交自动生成的文件 在编译过程中会产生很多自动文件，如.suo等配置文件、编译文件，以及其他的一些自动生成，同编译代码无关的文件。 4）不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在检出代码之后能够在统一的环境中进行编译。 5）不要提交自己不明白的代码 代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。 6）提交代码需填写注释 每次提交或建立新版本时，需描述清楚本次修改的内容，以便日后整理补丁，回滚版本所需。每条注释前，增加对此注释功能的描述标签，如下所示： +) 表示增加了功能 *) 表示对某些功能进行了更改 -) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。 b) 表示修正了具体的某个bug
北京迪科创新科技有限公司 一卡通项目研发部SVN使用规范 拟制张磊日期2015-03-09 审核日期 批准日期
1、目的： 本制度为研发部SVN 配置管理的准则和依据，所有与SVN 配置管理的行为都必须遵照并服从于本制度。 2、适用范围： 本制度适用于研发部全体员工。 3、控制要求和方法： 3.1 操作流程 首先用户从svn 版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 3.2 帐号注册、权限申请 1. 用户帐号注册：新进员工没有SVN 帐号，通过联系SVN 管理员，注明申请SVN 普 通帐号，管理员处理完帐号注册事宜后，通知使用并介绍使用规范。 注：普通帐号，只对目录有读取权限，无法更改。 2. 权限的申请： 根据员工所参与的项目，SVN 管理员对其开放相应目录的读、写权限。 3. 账号注销：员工离职后，对其账号进行注销。 Workin g Copy Workin g Copy Repository Network 版本库 网络 本地工作副本 检出、提交
3.3 操作规范 1.每日进行开发工作之前更新代码，下班时提交代码。 2.各员工需牢记各自的账户和密码，不得向他人透漏，严禁使用他人账户进行SVN各项 操作。 3.不要签出整个目录，除非特别必要，不应同时签出过多的项目。 4.文件提交时要求必须提交注释，注明相关修改信息，日志信息描述的越详细越好，让项 目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 5.代码变动及时提交，避免丢失本地修改后无法恢复。 6.在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交，否则只在你本地 能正常工作，导致其它人不能编译通过。 7.提交之前要测试所改变的应用，测试改变后的效果是否达到预期的目的。 8.多次检查提交的内容。提交之前应先做SVN更新或与资源库同步，注意到SVN关于冲 突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别，确认它们是不是你真正想要提交的。 9.如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是 同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 10.在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并 且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。 11.提前宣布修改计划。当你计划进行修改，需要影响到SVN里的许多文件时，先通过邮 件或者当面通知其他开发者。例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备，也会对修改提出意见和建议。 12.每次提交尽量是一个最小粒度的修改。比如一个小功能提交一次。 13.不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译。如 果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。 14.提交时注意不要提交本地自动生成的文件，提交的文件必须是开发者共用的程序文件， 程序编译中产生的中间文件或文件夹，如/Debug/、/Release/、*.ncb、*.obj、*.o、Thumbs.db、
SVN 规范 （1）每次提交（Commit）必须写注释，简单描述本次提交所做的变动。讨论：是否需要规定注释的写法和详细程度 （2）禁止无用代码提交到版本库，本地配置文件不得上传。 （3）个项目新功能开发在trunk中进行，bug修改在branchs中进行。（如有多个新功能同时进行，将多开一个branch，在其中进行开发）。（4）急时合并，临时修改、紧急BUG等测试通过后马上合并回主干，不要在版本发布前统一合并，容易出问题。 （5）每天将代码提交到版本库。 建议 SVN （1）每次提交前先更新一下，防止不必要的冲突。 SVN TortoiseSVN 1.8.7 使用基础 SVN （1）svn checkout 1.Url of repository : SVN版本库地址 2.Checkout directory : 下载到本地的目录 3.Fully recursive : 全递归：检出完整的目录树，包含所有的文件或子目录，一般默认就选这个 Immediate children,including folders : 把当前文件夹下的子文件及子文件夹都签出，但签出的子文件夹是空的，子文件夹下的 文件是不会签出的 Only file children : 只把当前文件夹下的直接子文件签出，其下的子文件夹（及其子文件）不签出 Only this item : 只把当前文件夹签出，其中为空，不包含任何子文件及子文件夹 4.Choose items : 点开后默认是全选的，如果下载时不想包含某个目录或文件时可以取消前面的勾 5.HEAD revision 更新到最新版本 6.Revision 更新到指定版本 （2）svn update 1.显示了更新的列表 2.更新到版本19 3.显示更新了4个文件，新增了3个文件 （3）svn commit
竭诚为您提供优质文档/双击可除 svn提交注释规范 篇一：sVn版本管理与提交代码规范 sVn版本管理，提交代码规范 项目开发要求： 1、工作目录要及时更新，不要和sVn服务器有太大的差别 2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交 3、提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交 4、必须保证sVn上的版本是正确的，项目有错误时，不要进行提交 sVn注意事项，请严格按照操作顺序操作，避免提交代码导致重大事故： 一．提交之前先更新 1.sVn更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。 2.如果在修改的期间别人也更改了svn的对应文件，那
么commit就可能会失败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 3.在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免sVn合并错误导致代码有错 二．保持原子性的提交 每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改ui界面的时候，可以每完成一个ui界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 三．提交时注意不要提交本地自动生成的文件 一般配置管理员都会将项目中一些自动生成的文件或 者与本地配置环境有关的文件屏蔽提交（例如eclipse中的.classpath文件等）。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲
通联支付网络服务股份有限公司技术支持中心研发部版本管理规范 受理市场支持部 2011年1月
版本控制信息
目录 文档类别使用对象.... 错误!未定义书签。1．引言............. 错误!未定义书签。 目的.......................................................... 错误!未定义书签。 范围.......................................................... 错误!未定义书签。 术语定义...................................................... 错误!未定义书签。 2．版本管理......... 错误!未定义书签。 2．1版本标识方法.............................................. 错误!未定义书签。 2．1．1版本标识说明........................................ 错误!未定义书签。 2．2目录结构 ................................................. 错误!未定义书签。 2．3版本的存放................................................ 错误!未定义书签。 trunk ..................................................... 错误!未定义书签。 branches .................................................. 错误!未定义书签。 tags ...................................................... 错误!未定义书签。 files ..................................................... 错误!未定义书签。 script .................................................... 错误!未定义书签。 sql ....................................................... 错误!未定义书签。 2．4权限控制管理.............................................. 错误!未定义书签。 3．更新管理（版本升级）.错误!未定义书签。 版本升级原则.................................................. 错误!未定义书签。 新版本的发布................................................. 错误!未定义书签。 版本管理流程说明 .......................................... 错误!未定义书签。 版本管理简略流程图 ........................................ 错误!未定义书签。 角色定位说明.............................................. 错误!未定义书签。 版本管理守则.............................................. 错误!未定义书签。4．备份管理......... 错误!未定义书签。5．SVN常用命令说明. 错误!未定义书签。
XXXX股份有限公司 开发部SVN使用规范 拟制日期审核日期批准日期
1、目的： 本制度为研发部SVN配置管理的准则和依据，所有与SVN配置管理的行为都必须遵照并服从于本制度。 2、适用范围： 本制度适用于研发部全体员工。 3、名词： 配置管理：是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。 变更控制组：是配置项变更的监管组织。 配置项：指哪些应该纳入配置管理之下，成为受控的工作产品最小单位项。 基线：基线是经过正式评审和认可，作为后续工作依据的配置项集合。 配置审计：配置审计主要是验证配置项的完整性和配置项的一致性。 4、职责： 3.1变更控制组 批准建立基线和标识配置项。 批准基线的发布。 评审与批准基线的更改。 批准由基线库生成产品。 3.2项目经理 协助配置管理员制定配置管理计划。 定义基线和配置项。 提出发布申请。 推动项目的配置管理工作。 3.3项目组成员
提交配置项内容。 3.4配置管理员 制定和维护配置管理计划。 建立和维护配置管理系统。 标识配置项。 发布基线。 执行基线审计。 标识、保存并分发配置状态报告。 从基线库发布产品。 3.5质量保证人员（QA ） 按照计划和过程检查配置管理活动及其工作产品。 报告检查中发现的问题，追踪问题直至关闭。 5、控制要求和方法： 5.1 操作流程 首先用户从版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 5.2 帐号注册、权限申请 1. 用户帐号注册：新进员工没有SVN 帐号，通过邮件联系SVN 管理员，邮件正文注明 申请SVN 普通帐号，管理员处理完帐号注册事宜后，会邮件回复。 Workin g Copy Workin g Copy Repository Network 版本库 网络 本地工作副本 检出、提交
计算机系软件工作室SVN管理规范 注：SVN官方使用手册地址如下https://www.doczj.com/doc/c41803962.html,/en/1.5/
文档管理 1.1 文档信息 文档名称计算机系软件工作室SVN管理规范办法 保密级别内部文档版本编号V1.0 制作人HuChao 制作日期2008-5-2 复审人复审日期 1.2 修改记录 时间版本说明修改人2008-5-2 1.0文档初建HuChao 2008-10-9 2.0 文档更新Jack Zhao
2内容摘要： Subversion (SVN)是一个版本控制系统，是CVS的极具竞争力的替代品。它支持CVS 所缺少的一些重要特性，比如版本化的重命名、目录和元数据；还支持原子提交和通过HTTP/HTTPS的远程访问。在小组开发中，熟练使用SVN是对开发人员最基本的要求之一；而配置管理员，同样要通过对SVN的管理来完成基线控制，版本发布等工作。 本文将详细描述SVN环境的初始化，用户权限管理，日常使用方法以及分支管理等方面的操作方法，供开发人员和配置管理员参考。 3SVN环境搭建： 3.1 服务器端： SubVersion 的运行分为两种情况，一种是作为独立的服务器，默认使用3690 端口，像CVS 那样来运行，支持直接连接或者SSL 连接。另一种是借助Apache2 的webdav 功能，直接挂接在Apache上，作为它的一个模块来运行。通过后一种方式，可以使用Apache现有的架构，不需要去改动你的防火墙，而且，可以使用IE 提供最简单的查看最新版本的功能。而且Apache是一个安全、稳定的服务器，有很多的认证方式，还有非常细致的对目录的权限管理，可以使资源库更加灵活的在网上进行共享。因此在本文中我们只介绍SVN+APACHE2的安装配置方式。 3.1.1SVN和APACHE安装 { 为避免出现不可预料的意外情况，安装路径中不要含有中文} 从https://www.doczj.com/doc/c41803962.html,/project_packages.html下载svn-win32-1.4.6后直接解压。 （如果下载到的是exe文件直接安装即可，无须下面SVN的环境变量配置） 从https://www.doczj.com/doc/c41803962.html,/download.cgi下载apache_2.2.6-win32-x86-no_ssl.msi并执行安装（最新版本是apache 2.2.9 ，最好与svn1.5.2搭配） 在下载时请注意svn和apache版本之间的匹配关系。完装完毕后设置以下系统环境变量：LANG=zh_CN.UTF8 APR_ICONV_PATH=%SVN_HOME%\iconv SVN_EDITOR=notepad PATH=%PATH%;%SVN_HOME%\bin;%APACHE_HOME%\bin 注意：以下所有的%SVN_HOME%和%APACHE_HOME%均需替换成实际的安装目录。