SVN分支管理模式解析(精编).docxVIP

  1. 1、本文档共8页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
SVN分支管理模式解析(精编)

SVN分支管理模式探析 本文试图从SVN分支管理的结构模式、规则模式、使用场景、优缺点分析等几个方面阐述几种不同的分支管理模式。 结构模式——通过约束和指导项目的整体目录结构,实现并行开发的组织结构、开发模式及开发过程的约束和指导。 规则模式——通过对项目不同分支的相关的操作实施约束,如访问控制、分支合并及发布等操作的约束和指导。 单主干-串行开发模式 使用场景 你的系统只有一个版本发布给最终用户; 你的维护方式是让客户不断升级到下一个版本; 所有对系统的修改都必须包含在下一个版本中; 已发布版本的bug是可控的,极少存在进行下一个版本开发过程中进行上一版本bug的修复工作。 图例 结构模式 分支名称源分支开发方式对应版本trunk无项目开发人员主要分支,其他人员无需使用该分支当前正在开发的版本-Devtagstrunk测试和发布专用分支,该分支代码不允许任何形式的修改当前正在测试的版本-Test 当前已经发布的版本-Rbranches─── 规则模式 权限规则:Trunk分支对项目开发人员读写权限、tags分支对所有人只读权限、banches分支废弃不用或很少用。 分支规则:开发人员直接在trunk上进行项目的开发,提测阶段从trunk上拉测试分支2010-12-15-1.0-T1到tags下,供测试人员进行测试;发布阶段从trunk上拉发布分支2010-12-15-1.0-R1到tags 下,供发布人员进行发布。 优缺点分析 优点:分支结构简单、清晰;开发过程中无分支合并/冲突解决等操作 缺点:不支持并行开发;不支持多版本发布。 单主干多分支-并行开发模式 使用场景 你的系统只有一个版本发布给最终用户; 你的维护方式是让客户不断升级到下一个版本; 所有对系统的修改都必须包含在下一个版本中; 需要频繁的修改前一个发布版本的bug,以及不断开发新的版本。 图例 结构模式 分支名称源分支开发方式对应版本trunk无主干冻结,不允许开发当前已经发布的版本-Rtagstrunk测试和发布专用分支,该分支代码不允许任何形式的修改当前正在测试的版本-Test 当前已经发布的版本-Rbranchestrunk开发专用分支当前正在开发的版本-Dev规则模式 权限规则: Trunk权限冻结开发,只有发布上线以后的版本才可以由SCM或SCM系统合并到trunk上; tags分支对所有人只读权限,用户测试、集成和发布分支用; banches分支是任何版本开发的唯一分支。 分支规则: 任何开发版本发起,都必须从trunk上copy出分支到branches进行开发; 提交测试(集成、发布)必须先从trunk创建测试(集成、发布)分支,然后合并branches分支内容,保证trunk内容的更新及时反馈到集成; 发布阶段从trunk上拉发布分支2010-12-15-1.0-R1到tags 下,然后合并branches内容到tags,供发布人员进行发布,发布成功后,合并tags分支到trunk。Trunk完成一次发布升级。 优缺点分析 优点:可以随时保证trunk上东西的稳定性,使trunk随时可用;可以从trunk上随时拿到已发布的任意一个版本。 缺点: 违背了SVN的规范,把trunk库当成了tag库去使用;分支合并频繁,导致冲突多,处理这些会消耗不少的资源,以及引入额外错误的可能;不支持多版本发布。 多主干-串行开发模式 使用场景 你的系统有多个版本发布给最终用户; 每个版本的维护都是独立进行的,只在需要的时候才进行各版本的合并维护; 已发布版本的bug是可控的,极少存在进行下一个版本开发过程中进行上一版本bug的修复工作。 图例 结构模式 分支名称源分支开发方式对应版本trunk无主版本的开发分支当前正在开发的版本-DevversionTrunk/version维护版本的开发分支当前正在开发的版本-Devtagstrunk测试和发布专用分支,该分支代码不允许任何形式的修改当前正在测试的版本-Test 当前已经发布的版本-Rbranches------------规则模式 权限规则:Trunk和version分支对项目开发人员读写权限、tags分支对所有人只读权限、banches分支废弃不用或很少用。 分支规则:开发人员直接在trunk或version上进行项目的开发,提测阶段从trunk或version上拉测试分支2010-12-15-1.0-T1到tags下,供测试人员进行测试;发布阶段从trunk或version上拉发布分支2010-12-15-1.0-R1到tags 下,供发布人员进行发布。 Version开发分

文档评论(0)

cuotian + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档