svn管理规范,华为

svn 管理规范,华为篇一：svn 管理规范安生 SVN 管理规范 第一章 总则 第一条 目的 通过对具备 SVN 管理权限的员工进行 SVN 规范的落实工作，促使员工不断改善工作效率，规范操作过程，从而提高公司对 SVN 仓库的合理、充分、高效利用的能力。 第二条 适用范围 本制度适用于浙江安生信息科技有限公司（以下简称“公司” ）及下属子分公司全体员工。 第三条 责任说明 对于公司离职的员工，原则上由其所在部门具备 SVN管理系统管理权限人员负责清除权限，同时人事行政部必须及时通知离职员工所在部门具备 SVN 管理系统管理权限人员（通常为部门主管）的权限清除工作。 第二章 细则 第一条 库管理 1， 公司的所有 SVN 仓库（包括杭州）将整合在统一的 SVN 服务器上。 2， 公司历史迁移库在访问 URL 中以“svn-past” 标记，新建库在访问 URL 中以“svn”标记。第二条 权限下放原则 1，由具备系统管理员权限（可配置）的管理人员分配库管理员。 2，库管理员允许多个，通常将库管理员赋给对应于某库的项目经理。 3，项目经理具备分配拥有项目（对应于某库）的人员以及权限的能力。 3，SVN 访问时统一将 IP 替换为“” ，端口为 90。 第三条 目录规范 1，按业务领域创建库，再按区域和平台性质划分分支目录，在分支目录下管理开发分支（适用于开发部） 。 2，所有新建仓库默认结构为： -Branches -Tags -Trunk 各目录下的所有子目录均不允许出现 trunk、tags、branches。 3，开发分支命名规范：年月日-时分秒-编号，如“XX1223-000000-001” 。4， 标签命名规范：年月日-时分秒-release-编号，如“XX1223-000000- release -001”。 第四条 其他约束 1，对于仓库目录结构的操作，一律通过 SVN 管理系统进行，禁止使用 Eclipse 5，编号为 branches 或则 tags下已存在目录数量加 1 的结果。 svn 插件或则TortoiseSVN 客户端或则 SVN 命令等其他任何形式操作仓库默认目录结构和其他明确禁止操作的目录。 第五条 产品配置库分类及命名（适用于开发部） 安监产品配置库分类及命名： 1)、业务领域 行政许可：xzxk 安监机构：ajjg 行政执法：xzzf 标准化：bzh 隐患排查：yhpc 应急预案：yjya 2，对于某项目的项目成员在 SVN仓库中的权限控制将由项目经理全权负责。 事故管理：sggl信用管理：xygl 通知公告：tzgg 电子台帐：dztz 安全培训：aqpx 投诉举报：tsjb 法律法规：flfg 中介机构：zjjg 2)、平台性质 独立系统：dlxt 乡镇街道：xzjd 综合监管：zhjg 综合监管信息（综合监管简化版）：zhxx 权利阳光：qlyg 网站：wz 办公自动化：oa 高层次人才（.net）平台：gjrc 3)、区域 区域以行政区域的不包含省市县字样的中文名称全拼表示，并且省、地市、县市三种级别区域级别，按同级别区域管理。当区域名称相同时以区域名称后缀“-上级区域名称拼音的首字母缩略组合” 。 4)、举例 业务领域：行政许可，区域：浙江省、宁波市、象山县三级行政区域。 ? 库目录结构如下： xzxk|-trunk |-tags |-branches |-zhejiang|-dlxt |-zfz |-zhjg |-zfz |-ningbo |-dlxt |-zfz |-zhjg |-zfz |-xiangshan |-dlxt |-zfz |-zhjg |-zfz ? 开发分支结构如下： 以区域为宁波的独立系统开发分支为例。 xzxk|-trunk |-tags |-branches |-zhejiang |-dlxt |-zfz |-branches |-年月日-时分秒-编号 篇二：SVN 管理规范SVN 管理规范 SVN 客户端的常用功能有 CheckOut（第一次下载版本）、Update（更新本地的版本为服务器上最新的版本） 、Commit（提交本地做出的修改至服务器） ，对这 3 个常用的功能要求如下。 注：本规范未提及的操作或者出现的例外请联系主管确认后再进行操作。 1、CheckOut 建议将 SVN 根目录 CheckOut 到某磁盘根目录下，这样便于管理。对于需要导入开发工具的项目，可以另CheckOut 一份到需要的目录，例如 Myeclipse 的WorkSpaces 目录、Source Insight 的开发目录等。 2、Update 在开发工作前先 Update 并查看相应日志，建议每天早上先进行 Update，避免由于别人修改的提交未更新到本地而引起的代码冲突。如果 Update 出现冲突（Update 的窗口出现 Conflicts、Error 字样或者红色字体）必须联系冲突版本提交人确认冲突原因并解决，最后提交冲突解决的版本。 3、Commit 建议每日下班前对于当日做出的代码改动或者新的文档资料等进行提交，养成良好习惯，其中提交时候的日志（提交窗口的 Message 输入框）必须填写详细，不允许出现不填写日志或者日志填写模糊的提交。 如果 Commit 出现冲突（Commit 的窗口出现Conflicts、Error 字样或者红色字体）必须联系冲突版本提交人确认冲突原因并解决，最后提交冲突解决的版本。 对于自主开发维护的项目，要求有改动的情况必须每日下班前提交；对于外 包开发维护的项目，要求里程碑或者阶段性提交。篇三：SVN 管理管理规范1.使用注意事项 负责而谨慎地提交自己的代码（先更新后提交） SVN 更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。 如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。 保持原子性的提交 每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改 UI 界面的时候，可以每完成一个 UI 界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改 bug 的时候，每修改掉一个 bug 并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 不要提交自动生成的文件 Visual Studio 在生成过程中会产生很多自动文件，如.suo 等配置文件，Debug,Release,Obj 等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用 Delete 命令从仓库中删除。这个可以使用 SVN 过滤功能，在设置里面设置 ignore lists. 不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。 不要提交自己不明白的代码 代码在提交入 SVN 之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 提前宣布自己的工作计划 在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 对提交的信息采用明晰的标注 +) 表示增加了功能 *) 表示对某些功能进行了更改 -) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。 b) 表示修正了具体的某个 bug 源代码管理时项