1、SVN源代码管理规范,姓名：舒定波 部门：软件产品开发部 邮箱： ,SVN简述,Subversion 是一种集中的分享信息的系统，它的核心是版本库，储存所有的数据，版本库按照文件树形式储存数据包括文件和目录，任意数量的客户端可以连接到版本库，读写这些文件。通过写数据，别人可以看到这些信息；通过读数据，可以看到别人的修改。 Subversion 会记录每一次的更改，不仅针对文件也包括目录本身，包括增加、删除和重新组织文件和目录,SVN版本库结构,Trunk Branches Tags,Trunk,任何时候Trunk里包含的都是最新开发代码。这里的代码将会工作到你的下一个主要发布版本。据我所见，几
2、乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好，无论是对你还是你的产品。Trunk应该只被用来开发将会成为你的下一个重要版本的代码。 不要给trunk加上版本号和发布名称。 仅需要保证trunk在任何时候都处于“开发模式”。,Branches,Release Branches Bug fix branches Experimental branches,Release Branches,当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），你应该创建一个release branches。 Release branches只是你当前trun
3、k的一个副本。这类branches可以被单独签出你也可以启动branches和基于此版本的项目。你还可以使用此分支在测试期间修复Bug。 这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。 因此当你准备发布一个新版本时，这样不会影响你trunk增加新的功能。 命名方式： RB-x.x,Bug fix branches,分支也可以用于处理trunk或release branches里发现的严重的Bug。当某些Bug很复杂，你不能通过只提交一次就修复他们。因此为了集中精力修正此错误，你应该为此问题创建一个新的分支。这样就不会影响trunk 和 release branches的
4、继续进行，并且你也不会因为发现新的Bug 和测试而干扰此Bug 的修复。Bug 修复分支的命名通常遵循下列方式：使用你的缺陷管理系统分配给此Bug的ID。通常这是一个数字。如：Bug-3391。当然，你也可以象其它分支一样访问你的Bug分支。,Experimental branches,有时你想将某个新技术引进项目。这很好，但是你当然不想赌上你的整个项目。想象一下，你想把你的Web程序从PHP4改为PHP5。你要花多少时间？在这期间你的trunk停止使用？直到你把所有到PHP5的转换做完！ 这是实验，可能PHP5就像彩虹的另一端一样离你的程序太远了，你应该给他创建一个分支。 你可以在分支里进行
5、更改，如果失败了，你在当前分支仍然有PHP4的代码。如果失败了，实验分支可以抛弃。 如果成功，你可以很容易的将其合并到trunk并继续你的新技术。 实验分支命名遵循在面原则：为其名字加上前缀“TRY-”。,Tags,标签就像分支一样备份你的代码。 但是 Tag不被用来开发，他们只是用来标记你代码的状态。,Tags,标签就像分支一样备份你的代码。 但是 Tag不被用来开发，他们只是用来标记你代码的状态。,Release tags Bug fix PRE and POST tags,Release tags,Release Tags 标记你版本发布点的代码。 Release Tag 永远是相应发布
6、分支的副本。 Release Tag命名规则：“REL-”前缀加上版本号。,Bug fix PRE and POST tags,当你创建了一个Bug fix分支，你想标记代码在BugFix之前和之后的状态。 这样你就很容易的引用你所做的更改，合并到trunk或Release branches。命名规则： “PRE-” 加上Bug ID； “POST-”加上Bug ID。,SVN使用规范,先更新，再提交 多提交 不要提交不能通过编译的代码 每次提交必须书写明晰的标注 提交时注意不要提交本地自动生成的临时文件 不要提交自己不明白的代码 慎用锁定功能,先更新，再提交,SVN更新的原则是要随时更新，随
7、时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自 己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。,多提交,每次提交的间歇
8、尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。,不要提交不能通过编译的代码,代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。,每次提交必须书写明晰
9、的标注,在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。,不要提交本地自动生成的文件,例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编译生成的临时文件.obj等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。,不要提交自己不明白的代码,代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。,慎用锁定功能,在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。,谢谢！,
