并行开发版本管理之路(二) --- 典型的版本管理难题

上一篇:并行开发版本管理之路(一) --- 版本管理危机

看完了上篇,我们对于多分支开发容易产生的问题应该有了一些基本的了解吧。事实上,通常,并行开发的版本管理面临以下几个典型的难题

  1.  如何保证新版本开发与BugFix同时进行?也就是要求修改过的BUG不能存在于新版本中
  2. 如何保证两个新版本并行开发?可能的情况是两个完全不同的版本,或者一个是另外一个基础
  3.  如何保证版本的发布不受开发人员无意的代码检入影响?  

不再拐弯抹角了,解决这三个难题的答案是使用分支(这里设计到一个著名的版本管理工具-ClearCase,分支正是其中的重要工具和概念)。

 

[OK,这里有个术语,就是分支。要理解分支必须同时理解其他的术语,比如说标签、视图。本文不打算详细的描述基础的概念,相关的概念可以参考ClearCase(一个强大的版本管理工具)的文档。]



`
 

   上面是一颗版本树,形象的记载了一个文件的版本变化情况。

 1 其中1、2、3是不同的版本,
 2 MainVer2.0就是分支。
 3 Release1023
Ver2.0Begin则是标签,标签就像是打在代码版本上的标记。
 4 视图就是由分支类型、标签名称、获取规则动态的决定的代码横截面。我可以建立
Main分支的视图,在这个视图中我就看不到Ver2.0分支中的任何代码修改,我也可以建立Ver2.0分支的视图,在这个视图中我们可以看到Ver2.0分支的最新代码和未在Ver2.0分支中产生修改的Main分支中位于Ver2.0Begin标签处的代码。开发人员总是习惯工作于一个视图上。

 

       OK,那看看解决第一个问题的办法。

 

         

  1. 建立用于修改BUG的分支视图,在此视图上进行修改
  2. 将在BugFix上修改的代码合并到主分支中,合并产生新的版本3,移动Ver2.0Begin标签到版本3,Ver2.0分支自动获取到修复BUG以后的代码,同时,主分支上的BUG也得到了修正
  3. 如果此时代码已经在Ver2.0上发生了变化,则需要执行另外一个合并,将更改合并到Ver2.0中。但是幸运的是,大多数时候不会在BugFix之前修改Ver2.0的代码。

   这样做我们至少收获了几个附加的好处

  1. 我们获得了从Main分支发布稳定版本的能力
  2. 我们获得了从Ver2.0分支发布最新预览版的能力
  3. 开发人员的检入检出不影响版本发布
  4. 版本管理员可以对Main分支进行锁定等控制,防止其他人员越权或者意外的修改Main分支的代码


待续……

posted @ 2006-10-23 22:56  quitgame  阅读(2739)  评论(4编辑  收藏