1. SVN标准目录 Subversion有一个很标准的目录结构,是这样的。比如项目是 proj,svn地址为 svn://proj/,那么标准的 svn 布局是:
这是一个标准的布局,trunk为主开发目录,branches为分支开发目录,tags为tag存档目录(不允许修改)。但是具体这几个目录应该如何使用,svn并没有明确的规范,更多的还是用户自己的习惯。
示例如图:
2 集中式:trunk进行主要开发一般的,我们的所有的开发都是基于trunk进行开发,当一个版本/release开发告一段落(开发、测试、文档、制作安装程序、打包等)结束后,代码处于冻结状态(人为规定,可以通过hook来进行管理)。此时应该基于当前冻结的代码库,打tag。当下一个版本/阶段的开发任务开始,继续在trunk进行开发。 此时,如果发现了上一个已发行版本(Released Version)有一些bug,或者一些很急迫的功能要求,而正在开发的版本(Developing Version)无法满足时间要求,这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag,做相应的分支(branch)进行开发。 例如,刚刚发布1.0,正在开发2.0,此时要在1.0的基础上进行bug修正。按照时间的顺序:
这是一种很标准的开发模式,很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。 3 分散式:分支进行主要开发这种开发模式当中,trunk是不承担具体开发任务的,主要承担版本发布,一个版本/阶段的开发任务在开始的时候,根据已经release的版本做新的开发分支,并且基于这个分支进行开发。还是举上面的例子,这里面的时序关系是。
这其实是一种分散式的开发,当各个部分相对独立一些(功能性的),可以开多个dev的分支进行开发,这样各人/组都不会相互影响。比如dev_2.0_Search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。 所以,第六步进行选择性的merge,是可以当2.0开发结束后一起把dev_1.0(bugfix用)和dev_2.0(新版本开发用)merge回trunk。或者先把dev_1.0 merge到dev_2.0,进行测试等之后再merge回trunk。 这两种方法各有利弊,第一种方法是可以得到一个比较纯的dev_2.0的开发分支,而第二种方法则更加的保险,因为要测试嘛。 多人协作时,第六步是最经常出问题的地方,严重的甚至会导致代码被覆盖回滚情况,其原因在于分支管理者创建分支后不再或长时间从主干拉回数据,导致最终合并回主干时分支的文件甚至结构都与主干有较大差别,产生较多冲突。需要人手解决,浪费了很多时间。 针对这个问题,是否有一种方案可以在分支提交时即检测该分支最后一次合并的版本是否与主干版本相符,如果不符则不允许提交,强制要求大家养成从主干拉数据的习惯呢?如果可以实现,那么在分支合并回主干时将几乎可以消灭掉冲突。 当前解决思路主要有3种:
以上呢,就是SVN的两种开发模式了,具体哪种好,并没有定论。这里大致的说一下各自的优缺点: 第一种开发模式(trunk进行主要开发,集中式):
第二种开发模式(分支进行主要开发,分散式):
4 最后,推荐第一种开发模式
责职说明:
过程说明:
|
|