6.3. SVN源代码管理规范

1. SVN 版本库结构构建

在大多数人眼中的Subversion，就是那个在代码里被叫做“Trunk”的东西。其实Subversion包含了更多的内容！ 为了让你能够更加充分体会到Subversion的好处，本文将讨论如何搭建你的版本库结构。 正如你之前在Subversion的相关文章中看到的那样，Subversion最基本的结构由三个路径组成：branches，tag和trunk。

每个路径在Subversion里都可以单独签出。

1.1 Trunk

任何时候Trunk里包含的都是最新的开发代码。 这里的代码将会工作到你的下一个主要发布版本。

据我所见，几乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好，无论是对你还是你的产品。

Trunk应该只被用来开发将会成为你的下一个重要版本的代码。 不要给trunk加上版本号和发布名称。 仅需要保证trunk在任何时候都处于“开发模式”。

例子：

https://svn.example.com/svnroot/project/trunk

1.2 Branches

这里有几种不同类型的分支。这里我会告诉你一些常见的类型。在branches的目录里，你可以为更多具体的目标创建路径，像即将发行版本。 正如我的文章“article on releasing software from Subversion”里讨论的那样，brahches路径包含了trunk在不同发展阶段的副本。

1.2.1 Release Branches

我们已经见过了 RB-x.x release branches。当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），你应该创建一个release branches。 Release branches只是你当前trunk的一个副本。

这个branches可以被单独的签出你也可以启动branches和基于此版本的项目。你还可以使用此分支在测试期间修复Bug。 这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。 因此当你准备发布一个新版本时，这样不会影响你trunk增加新的功能。

1.2.2 Bug fix branches

分支也可以用于处理trunk或release branches里发现的严重的Bug。这些Bug很复杂，你不能在一次提交时就修复他们。因此为了集中精力修正此错误，你应该为此问题创建一个新的分支。这样就不会影响trunk 和 release branches的继续进行，并且你也不会因为发现新的Bug 和测试而干扰此Bug 的修复。

Bug 修复分支的命名通常遵循下列方式：使用你的缺陷管理系统分配给此Bug的ID。通常这是一个数字。如：Bug-3391。

当然，你也可以象其它分支一样访问你的Bug分支。

1.2.3 Experimental branches

有时你想将某个新技术引进项目。这很好，但是你当然不想赌上你的整个项目。想象一下，你想把你的Web程序从PHP4改为PHP5。你要花多少时间？在这期间你的trunk停止使用？直到你把所有到PHP5的转换做完！

这是实验，可能PHP5就像彩虹的另一端一样离你的程序太远了，你应该给他创建一个分支。 你可以在分支里进行更改，如果失败了，你在当前分支仍然有PHP4的代码。

推荐：SVN源代码管理心得

[负责而谨慎地提交自己的代码（先更新后提交）SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。如果提交过程中

如果失败了，实验分支可以抛弃。 如果成功，你可以很容易的将其合并到trunk并继续你的新技术。 实验分支命名遵循在面原则：为其名字加上前缀“TRY-”。

1.3 Tags

标签就像分支一样备份你的代码。 但是 Tag不被用来开发，他们只是用来标记你代码的状态。

1.3.1 Release tags

Release Tags 标记你版本发布点的代码。 Release Tag 永远是相应发布分支的副本。 Release Tag命名规则：“REL-”前缀加上版本号。

1.3.2 Bug fix PRE and POST tags

当你创建了一个Bug fix分支，你想标记代码在BugFix之前和之后的状态。 这样你就很容易的引用你所做的更改，合并到trunk或Release branches。

命名规则：   “PRE-”加上Bug ID；

“POST-”加上Bug ID。

2. SVN使用规范

  • 先更新，再提交

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

  • 多提交

    每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。

  • 不要提交不能通过编译的代码

    代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

  • 每次提交必须书写明晰的标注

    在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。

  • 提交时注意不要提交本地自动生成的文件

    例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编译生成的临时文件.obj, .class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。

  • 不要提交自己不明白的代码

    代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。

  • 慎用锁定功能

    在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。

Previous6.2. Git分支模型Next6.4. SVN的标准目录结构

Last updated

Was this helpful?