SVN源代码管理规范_免费下载

《SVN源代码管理规范_免费下载》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、SVN源代码管理规范1.SVN版本库结构构建在大多数人眼中的Subversion，就是那个在代码里被叫做“Trunk”的东西。其实Subversion包含了更多的内容！为了让你能够更加充分体会到Subversion的好处，本文将讨论如何搭建你的版本库结构。正如你之前在Subversion的相关文章中看到的那样，Subversion最基本的结构由三个路径组成：branches，tag和trunk。每个路径在Subversion里都可以单独签出。1.1Trunk任何时候Trunk里包含的都是最新的开发代码。这

2、里的代码将会工作到你的下一个主要发布版本。据我所见，几乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好，无论是对你还是你的产品。Trunk应该只被用来开发将会成为你的下一个重要版本的代码。不要给trunk加上版本号和发布名称。仅需要保证trunk在任何时候都处于“开发模式”。1.2Branches这里有几种不同类型的分支。这里我会告诉你一些常见的类型。在branches的目录里，你可以为更多具体的目标创建路径，像即将发行版本。brahches路径包含了trunk

3、在不同发展阶段的副本。1.2.1ReleaseBranches我们已经见过了RB-x.xreleasebranches。当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），你应该创建一个releasebranches。Releasebranches只是你当前trunk的一个副本。这个branches可以被单独的签出你也可以启动branches和基于此版本的项目。你还可以使用此分支在测试期间修复Bug。这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。因此当你准备发布一个新版

4、本时，这样不会影响你trunk增加新的功能。1.2.2Bugfixbranches分支也可以用于处理trunk或releasebranches里发现的严重的Bug。这些Bug很复杂，你不能在一次提交时就修复他们。因此为了集中精力修正此错误，你应该为此问题创建一个新的分支。这样就不会影响trunk和releasebranches的继续进行，并且你也不会因为发现新的Bug和测试而干扰此Bug的修复。Bug修复分支的命名通常遵循下列方式：使用你的缺陷管理系统分配给此Bug的ID。通常这是一个数字。如：Bug-3

5、391。当然，你也可以象其它分支一样访问你的Bug分支。1.2.3Experimentalbranches有时你想将某个新技术引进项目。这很好，但是你当然不想赌上你的整个项目。想象一下，当你的应用要增加动态背景功能。你要花多少时间？在这期间你的trunk停止使用？直到你把所有到PHP5的转换做完！这是实验，可能PHP5就像彩虹的另一端一样离你的程序太远了，你应该给他创建一个分支。你可以在分支里进行更改，如果失败了，你在当前分支仍然有PHP4的代码。如果失败了，实验分支可以抛弃。如果成功，你可以很容易的将其

6、合并到trunk并继续你的新技术。实验分支命名遵循在面原则：为其名字加上前缀“TRY-”。1.3Tags标签就像分支一样备份你的代码。但是Tag不被用来开发，他们只是用来标记你代码的状态。1.3.1ReleasetagsReleaseTags标记你版本发布点的代码。ReleaseTag永远是相应发布分支的副本。ReleaseTag命名规则：“REL-”前缀加上版本号。2.SVN使用规范先更新，再提交SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。如果在

7、修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。多提交每次提交

8、的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。不要提交不能通过编译的代码代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有