SVN源代码管理规范 1. SVN 版本库结构构建在大多数人眼中的Subversion,就是那个在代码里被叫做“Trunk”的东西。其实Subversion包含了更多的内容! 为了让你能够更加充分体会到Subversion的好处,本文将讨论如何搭建你的版本库结构。 正如你之前在Subversion的相关文章中看到的那样,Subversion最基本的结构由三个路径组成:branches,tag和trunk。 每个路径在Subversion里都可以单独签出。 1.1 Trunk任何时候Trunk里包含的都是最新的开发代码。 这里的代码将会工作到你的下一个主要发布版本。 据我所见,几乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好,无论是对你还是你的产品。 Trunk应该只被用来开发将会成为你的下一个重要版本的代码。 不要给trunk加上版本号和发布名称。 仅需要保证trunk在任何时候都处于“开发模式”。 例子: https://svn./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的代码。 如果失败了,实验分支可以抛弃。 如果成功,你可以很容易的将其合并到trunk并继续你的新技术。 实验分支命名遵循在面原则:为其名字加上前缀“TRY-”。 1.3 Tags标签就像分支一样备份你的代码。 但是 Tag不被用来开发,他们只是用来标记你代码的状态。 Release Tags 标记你版本发布点的代码。 Release Tag 永远是相应发布分支的副本。 Release Tag命名规则:“REL-”前缀加上版本号。 当你创建了一个Bug fix分支,你想标记代码在BugFix之前和之后的状态。 这样你就很容易的引用你所做的更改,合并到trunk或Release branches。 命名规则: “PRE-”加上Bug ID; “POST-”加上Bug ID。
2. SVN使用规范先更新,再提交 多提交 |
|