SVN文档代码提交以及注释相关要求.docVIP

SVN文档代码提交以及注释相关要求 目前每期配置检查都发现有工程师不提交代码和文档的事情发生，综合了一下主要有以下3类原因： 各项目配置库没有配备工程师私有目录，工程师担心最新修改的程序合入到版本后，会影响到整体，所以未进行提交。 工作完成后忘记了及时去共享最新工作成果； 由于SVN提交时必须要写注释信息，少数工程师觉得写注释信息麻烦，所以就谎称项目无进展，没有需要更新的代码和文档，达到不提交工作。 导致如下问题存在： 项目过程中的中间产物公司没有收集到，需要存档保存； 配置检查、审计及统计时，数据不准确，配置管理员不知道此项目是否确实如开发人员所说已经停止，而项目管理者也不能确却了解项目的具体进展情况； 工程师连续几天甚至一周才提交一次，中间无版本记录，出错后不可恢复，不可查询，只能回退到一周前甚至更早以前的版本，中间产物将完全丢失； SVN注释信息敷衍，甚至无实际意义，没有说明做了什么事情，除工程师本人外，其他工程师想要了解比较困难。 为解决目前存在的问题，使相关人员养成良好的工作习惯，从以下几方面规范配置管理： 在服务器上新建personal配置库，由工程师自行管理，除上级管理人员可查询外，其他人员无查看权限。用于保存没有经过验证的工作有存档记录，不会影响到全局项目，也不会将私有操作的SVN版本记录叠加到具体项目中去； 工程师个人工作配置库： svn://scm/personal (scm小写) 每次提交必须有相关修改说明（SVN的注释信息），以方便今后以及其他相关工程师查阅，不符合规范（见附件2）的注释信息情况，将记录到每个人员的绩效考核中（分值见附件2） 每周进行配置检查并统计SVN用户的活跃程度（SVN检查点见附件1），及详细修改内容——SVN的注释信息（使用statsvn工具自动统计），将检查记录到每个人员的绩效考核中（分值见附件1） 说明： 只统计项目配置库，如项目配置库中无记录，而personal配置库中有提交记录时，仍属正常情况。如果两个配置库都无记录，则属违规，上级领导需要核实该工程师当天是否有实际工作。  附件1：SVN日常检查10条 SVN日常操作检查点 编号 检查点 标准说明 未达标绩效分 1 每天下班前进行一次提交操作 每人每天至少提交一次（包括源代码和文档） -1 2 每次提交需要增加注释信息 相关注释说明见附件2 见附件2 3 不同功能的文件分开提交 同一功能涉及的代码作一次提交 -1 4 代码注释 注释应简明扼要、清晰说明相关代码 -1 5 上传（增加）文件大小检查，单次上传最大为10M，如有需要可向配置管理员要求开放权限。 上传文件过大影响服务器性能；备份数据过大占用额外磁盘空间（以前因没限制，直接导致本次配置库扩容）；工具类软件无须上传。 0.5 6 上传文件类型检查 禁止上传垃圾文件，特别是Debug，Build，Release子目录 -1 7 错误修改他人代码统计 错误的修改了他人代码，或者造成团队代码合并时发生冲突 -2 8 SVN上传文档命名规范及修改遵循《软件配置管理规范.doc》 08.11.19发布已在内网公布。除归档标签外，所有文档只做升级，不得另外增加升级文档。 -1 9 SVN文件删除统计 尽量减少误操作发生 0.5 10 公共代码可以指定人员锁定，但禁止任意人员进行锁定 -1 11 被动提交，造成需要项目合并的事故 本地大量修改不合入、合入不及时，导致服务器及其他工程师需要大工作量合并代码，属严重配置事故。 -2  附件2：SVN注释说明 SVN日志默认包含了：版本号，操作类型，作者，日期和被修改对象文件等5项信息，在注释中不需要重复说明,只需说明修改的内容即可。 例如： 不规范注释信息实例： 编号 实例说明 实例案例 未达标绩效分 1 以凑字数而随意填写注释信息 -1 2 将操作类型作为注释信息 -1 3 以关键字“订阅”为注释信息 -1 4 以修改对象文件名字为注释信息 -1 5 两次修改操作，注释信息完全一致 -1 注意： 1、各配置库共用SVN账号信息，需自行保管好账号信息； 2、当前personal 配置库在scm配置服务器上，可直接从以上地址获取，为防止IP地址有变对SVN造成影戏哪个，从SVN客户端访问配置库时必须使用scm代替IP地址，外网访问时可向配置管理员索要具体svn地址（09年12月21日已完成新配置服务器的切换）