SVN是什么鬼我就不描述了。不懂的直接撞墙。
一:主干发布
如下图:
如果按照这种方式发布的优点:
第一:可以随时保证trunk上的东西的稳定性,使trunk随时可用;
第二:大部分开发人员不会去触碰trunk,用分支的方式解决实际开发过程中的一些变更(需求变更或设计变更等);
第三:可以从trunk上随时拿到已发布的任意一个版本。
如果按照这种方式发布存在的不足:
第一:
第二:违背了SVN的规范,把trunk库当成了tag库去使用;
第三:某些开源项目会采用这种开发(发布)模式,但其中对于验证要求非常严格,merge起来很费时,鉴于开源项目的特殊性,暂不做讨论;
第四:一般采用这种模式发布,是有自己的考虑在里面的。那就是trunk上的东西是不能损坏的,必须随时是好的,即使偶尔出现问题也能及时修正,但trunk已经完全失去了它做为主干的意义,也很难保证SVN库的一致性。
我个人认为这个主干发布就是一个坑。如果我一个项目要进行大的重构,但是老版本一直需要维护、升级。那怎么整?怎么整。
二:分支发布
如下图:
如果按照这种方式发布的优点:
第一:trunk做为开发主线,开发人员可以随时将自己符合要求的代码提交到trunk上,如果在没有必要的条件下,不开分支。同时对trunk做持续集成验证,最大程度上保证trunk的稳定性。
第二:对每次成功的持续集成都同时对库和集成环境做tag操作,发挥tag库的强大作用。
第三:最大量的减少了merge操作,降低了误差。一旦要发布产品,只需从一个稳定的版本(公司上层同意的)发一个分支出来,然后再投入少量的开发人员去进一步优化,主要是fix bug。而这时,大部分开发人员就可以投入到下一个版本的开发中,最大力度的使用人力资源。
第四:其它.
如果按照这种方式发布存在的不足:
第一:配置管理需要随时了解pre-release的分支是否需要保留,以为下一次发布update等做准备。
第二:如果有大型的变更,trunk可能会被破坏,但是如果有一套规范,可以把风险降到最低。(或者也可以通过开分支的方式来解决这种问题)
第三:如果想要真正发挥这种发布模式的威力,配置管理,变更管理,持续集成,质量管理,发布管理每一个模块都是不可少的。
个人观点:略微复杂的项目可能的采用分支上创建分支的方式,不过这个要根据业务需求了。