svn版本管理制度

svn 版本管理制度篇一：SVN 版本管理规范通联支付网络服务股份有限公司 技术支持中心研发部版本管理规范 受理市场支持部 XX 年 1 月 版本控制信息 目录文档类别使用对象 . 4 1引言 . 4 目的 .4 范围 .4 术语定义 .4 2版本管理 . 6 21 版本标识方法 . 6 211 版本标识说明 .6 22 目录结构 . 6 23 版本的存放 . 7 trunk . 8 branches . 8 tags . 8 files . 8 script . 8 sql . 8 24 权限控制管理 . 8 3更新管理（版本升级） 8 版本升级原则 .8 新版本的发布 . 9 版本管理流程说明 . 9 版本管理简略流程图 .10 角色定位说明 . 11 版本管理守则 . 11 4备份管理 11 5SVN 常用命令说明 . 12 文档类别使用对象 文档类别 该文档是为技术支持中心提供一个版本管理规范性文件。 使用对象 该文档使用对象为技术支持中心研发部版本管理人员，以及其他相关人员。未经许可，该文档不得提供给上述规定对象以外的人员阅读或使用。 1引言 目的 本文档是为规范技术支持中心研发版本管理而制定的。范围 本文档为研发部各人员提供有关版本管理规范的相关内容，包括： 1. 2. 3. 4. 版本标识方法 版本管理流程 角色定位 SVN 常用命令说明 术语定义 SVN Svn 是一个开源的版本控制系统 Subversion 的简称 文档 上线所需的相关文档，包括部署手册，源码修改清单列表等 脚本 上线所需的相关脚本，包括编译脚本等 SQL 语句上线所需的相关 SQL 语句，包括建表语句等 配置管理 标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：源码。 基线 软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。 邮件服务 需求转达，标签转达时候，需要发送邮件通知对方或者回复对方 版本控制 通过 svn co 把分支文件夹拷贝到开发环境进行开发，并进行版本控制 版本管理 根据需求，创建开发所需的分支 标签管理 为测试版本，上线版本创建标签 版本更新 通过 svn ci 定期备份修改内容，或通过 svn update更新当前所开发的源码，或通过 svn merge 把主干新增内容更新至分支 版本测试 通过 svn export 校验源码，进行源码的比对，测试 版本修复 对当前测试或上线版本出现的问题进行修复 篇二：SVN 管理规范1、目的： 本制度为研发部 SVN 配置管理的准则和依据，所有与SVN 配置管理的行为都必须遵照并服从于本制度。 2、适用范围： 本制度适用于研发部全体员工。 3、控制要求和方法： 操作流程 首先用户从 svn 版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 帐号注册、权限申请 1. 用户帐号注册：新进员工没有 SVN 帐号，通过联系 SVN 管理员，注明申请 SVN 普 通帐号，管理员处理完帐号注册事宜后，通知使用并介绍使用规范。 注：普通帐号，只对目录有读取权限，无法更改。 2. 权限的申请： 根据员工所参与的项目，SVN 管理员对其开放相应目录的读、写权限。 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、 、/build/、*.class、/classes/、/data/等不要提交到 SVN 里。 15. SVN 管理员需对 SVN 的所有项目定期备份。 16. SVN 的资料不允许公开给其他部门人员，确实要分发的，必须通过总经理同意。 重要说明文件要求: 硬件开发： 修改日志文件与版本文件（未修改可不写） ，需求分析书、源代码文件、PCB 原理图、料单、技术规格书、生产测试说明书，相关开发技术文档入库。软件开发： 源代码文件（含数据库创建脚本（含静态数据） ） 、编译构建脚本和所有源代码、修改日志与版本文件，需求分析书、技术规格书、测试重点说明书、使用手册（包含安装使用） 、使用 demo 与测试相关工具等文件。 测试部门： 测试计划、测试用例、测试 bug 问题单、阶段性测试报告、问题反馈修改单、最终测试报告单、版本发布说明书，用户手册。 以上文件请开发部门领导与人员督促准备与提交。 篇三：知识库(SVN 版)管理办法【试行】沃支付 SVN 版知识库管理办法 （试行版） XX-5-13 修改历史目 录目录 第一条. 第二条. 第三条. 第四条. 目标和职责 . 4 知识库内容范围 . 4 svn 搭建方案 . 5 权限管理 .7 第一条. 目标和职责 1、 为确保公司产品和平台建设过程透明化，使得产品建设团队能够有效把控平台建设状况， 同时，也为持续提升平台质量，持续积累业务方案和技术知识，特建立沃支付知识库。除此之外，沃支付知识库也可作为全公司流程制度，规范、规划、公告等文档的共享平台。 2、 全公司各部门或业务单元对知识库的持续建设承担职责。其中，产品建设知识内容由产 品团队和技术团队各业务单元分别维护，各部门或业务单元的公开性文档各自分别维护。 3、 为了保证知识库的建设有序、知识合理组织、有效运行，特设立知识库管理岗（兼职） ， 负责知识库建设方案制定和维护、知识库安全运行保障、知识库用户和权限管理、知识库使用说明和帮助等工作。 第二条. 知识库内容范围 1、 业务及技术规范：包括支付公司系统的业务规范、业务模型、总体架构和技术规范。其 中： ? 业务规范根据产品线架构分别描述产品线以及产品的功能要求、业务流程、规则以 及相关非功能需求； ? 业务模型是在业务规范的基础上形成的业务实体描述以及实体之间的关系描述，例 如：客户模型，用户模型，账户模型，产品模型，安全模型等等； ? 总体架构是为了实现业务规范和业务模型相关要求，从平台建设维度对 IT 设施的规 划、平台及系统职能界定和分配、平台及系统之间关系描述、数据分布及物理部署规划要求。 ? 技术规范根据产品线和平台架构分别描述各子平台的技术实现要求，其中包含业务 模型、架构以及各功能的技术实现要求等。 2、 产品需求：包括产品/业务需求文档、产品/业务需求分析文档。在此需要说明一下产品 需求和业务规范的的关系，由于支付公司产品具有互联网特色，产品需求文档先行发布，后期业务逐渐稳定后再形成业务规范，为了便于后期业务规范的整理，建议产品需求文档在编写时向业务规范的编写要求靠近。 3、 产品总体设计，包括平台总体设计说明文档以及相关参考资料，以架构版本为纬度分别 组织目录结构，每个架构的版本下可按照划应用层、标准产品层和能力支撑层平台分类组织为三个目录，属于某个平台分类的所有平台再以平台为单位划分目录维护在分数平台分类目录，每个平台下再以版本组织目录结构进行管理。4、 系统详细设计，包括数据库设计文档、系统详细设计说明文档、接口清单以及相关参考 资料，以数据库设计和系统设计两个纬度组织目录结构。 5、 产品指南，包括技术或业务、运营文档、培训资料；以及用户手册、运营方案和运营数 据、工程部署方案和数据信息等。 6、 流程制度，贯穿所有产品和平台建设过程中产生的各种流程和制度文件，如上线流程、 系统变更流程、svn 账号申请流程、厂商管理办法等。7、 软件工程规范，贯穿所有产品和平台建设过