svn,版本管理规范

svn,版本管理规范篇一：SVN 版本管理与提交代码规范SVN 版本管理，提交代码规范 项目开发要求： 1、工作目录要及时更新，不要和 SVN服务器有太大的差别 2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交 3、提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交 4、必须保证 SVN上的版本是正确的，项目有错误时，不要进行提交 SVN 注意事项，请严格按照操作顺序操作，避免提交代码导致重大事故： 一提交之前先更新 更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己 测试 之后，谨慎地提交。2. 如果在修改的期间别人也更改了 svn的对应文件，那么 commit就可能会失败。如果别人和自己更改的是同一个文件，那么 update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突 之后，程序不会影响其他功能。 3. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免 SVN合并错误导致代码有错 二保持原子性的提交 每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改 UI界面的时候，可以每完成一个 UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个 bug并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。三提交时注意不要提交本地自动生成的文件 一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如 eclipse中的.classpath 文件等） 。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。 四不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。五不要提交自己不明白的代码 代码在提交入 SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 六提前协调好项目组成员的工作计划 项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 七对提交的信息采用明晰的标注（写注释） 在一个项目组中使用 SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。八慎用锁定功能 在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash 文件等）时，才适当的采用锁定操作。 篇二：SVN 管理管理规范1.使用注意事项 负责而谨慎地提交自己的代码（先更新后提交） SVN 更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。 如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。 保持原子性的提交 每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜。如在更改 UI界面的时候，可以每完成一个 UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改 bug的时候，每修改掉一个 bug并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 不要提交自动生成的文件 Visual Studio在生成过程中会产生很多自动文件，如.suo 等配置文件，Debug,Release,Obj 等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用 Delete命令从仓库中删除。这个可以使用 SVN过滤功能，在设置里面设置 ignore lists. 不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库或者没有放入GAC（针对.Net Framework）中，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。 不要提交自己不明白的代码 代码在提交入 SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 提前宣布自己的工作计划 在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 对提交的信息采用明晰的标注 +) 表示增加了功能 *) 表示对某些功能进行了更改 -) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。 b) 表示修正了具体的某个 bug 源代码管理时项目管理中很重要的一环，同时发现测试真的时很重要，一定要有专门的测试人员。2 使用说明： 检出 新建文件夹 RPCC 点击确定按钮，注意 RPCC大写，检出到本地文件如下： 更新当其它开发人员修改程序后，需要更新本地的程序。 修改程序前一定要先更新。检入 修改程序后，程序将设置红色感叹号，表示与配置库不同，需要检入数据库。 右键菜单 填写入库原因，做了什么修改 篇三：产品版本管理规范基于 Tortoise SVN的软件产品 版本管理规范草稿 目录1. 引言.1 目的 . 1 范围 . 1 术语定义 . 1 参考资料 . 2 版本控制记录 . 2 版本更新记录 . 2 2. 版本管理 . 4 版本标示方法 . 4 正式版本 . 4 目录结构 . 5 文档的存放 . 6 开发文档的存放 6 源代码的存放 6 SQL的语句存放 7 发行文档的存放 7 配置管理流程 . 7 权限控制的管理 . 8 3. 更新管理 . 9 源程序的修改 . 9 版本升级 .10 版本升级原则 . 10 新版本发布 . 11 文档的变更 .11 4. 备份管理 .12 5. 版本工具 Tortoise SVN的使用 13 1. 引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ? 版本标识方法 ? 软件系统数据的存放 ? 文档的修改控制 ? 文档的备份制度 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统 Subversion. 文档 一种数据媒体和其上所记录的数据。 第 1 页 共 15 页 配置管理标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。 软件配置 软件的具体形态在某时刻的瞬时影像。 配置项 软件配置管理的对象称为配置项，如：