SVN管理规范

《SVN管理规范》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、1、目的： 本制度为研发部SVN配置管理的准则和依据，所有与SVN配置管理的行为都必须遵照并服从于本制度。  2、适用范围： 本制度适用于研发部全体员工。   3、控制要求和方法： 3.1 操作流程 首先用户从svn版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 3.2 帐号注册、权限申请 1. 用户帐号注册：新进员工没有SVN帐号，通过联系SVN管理员，注明申请SVN普通帐号

2、，管理员处理完帐号注册事宜后，通知使用并介绍使用规范。     注：普通帐号，只对目录有读取权限，无法更改。 2. 权限的申请： 根据员工所参与的项目，SVN管理员对其开放相应目录的读、写权限。    3. 账号注销：员工离职后，对其账号进行注销。 3.3 操作规范 1. 每日进行开发工作之前更新代码，下班时提交代码。 2. 各员工需牢记各自的账户和密码，不得向他人透漏，严禁使用他人账户进行SVN各项操作。 3. 不要签出整个目录，除非特别必要，不应同时签出过多的项目。 4. 文件提交时要求必须提交注释，注明相关修改

3、信息，日志信息描述的越详细越好，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 5. 代码变动及时提交，避免丢失本地修改后无法恢复。 6. 在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交，否则只在你本地能正常工作，导致其它人不能编译通过。 7. 提交之前要测试所改变的应用，测试改变后的效果是否达到预期的目的。 8. 多次检查提交的内容。提交之前应先做SVN更新或与资源库同步，注意到SVN关于冲突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别，确认它们是不是你真正想

4、要提交的。 9. 如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 10. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。 11. 提前宣布修改计划。当你计划进行修改，需要影响到SVN里的许

5、多文件时，先通过邮件或者当面通知其他开发者。例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备，也会对修改提出意见和建议。12. 每次提交尽量是一个最小粒度的修改。比如一个小功能提交一次。 13. 不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。 14. 提交时注意不要提交本地自动生成的文件，提交的文件必须是开发者共用的程序文件，程序编译中产生的中间文件或文件夹

6、，如/Debug/、/Release/、*.ncb、*.obj、*.o、Thumbs.db、/build/、*.class、/classes/、/data/等不要提交到SVN里。 15. SVN管理员需对SVN的所有项目定期备份。 16. SVN的资料不允许公开给其他部门人员，确实要分发的，必须通过总经理同意。 重要说明文件要求: 硬件开发： 修改日志文件与版本文件（未修改可不写），需求分析书、源代码文件、PCB原理图、料单、技术规格书、生产测试说明书，相关开发技术文档入库。 软件开发： 源代码文件（含数据库创建脚本

7、（含静态数据））、编译构建脚本和所有源代码、修改日志与版本文件，需求分析书、技术规格书、测试重点说明书、使用手册（包含安装使用）、使用demo与测试相关工具等文件。 测试部门： 测试计划、测试用例、测试bug问题单、阶段性测试报告、问题反馈修改单、最终测试报告单、版本发布说明书，用户手册。 以上文件请开发部门领导与人员督促准备与提交。