?

Log in

No account? Create an account

October 10th, 2007

fedora 蓝色小药丸

VSS 做大规模开发的对策

今天的主要任务是做一个 diff-and-merge 以及学习一段代码。在编译代码之前先做掉 diff 的工作,这段时间正好可以写点什么。

VSS 还是我们所用的版本控制系统,短期不会有变化了。我们的大规模开发指的是,两个到三个产品,每个产品有两个 release 需要维护;所有产品的 devel/head 分支是合并开发的,只在 release 之后分开,devel 分支也面向将来的两个 release,因为有些 feature 不是针对将来第一个 release。所谓的对策,实际上是由于 VSS 的功能太弱,很多版本控制的“动作”都必须用手动的方式完成,模拟那些优秀系统中的功能。如果模拟得当,应该可以解决问题。

过去 VSS 采用一种相当傻X的增量模式(而且用了好久!不知道是怎么想的),假如我需要取到完整的 release 树来做 patch,需要首先取 release 时的代码,然后到 patch 树把每次 patch 的代码都取回来。因为两三个产品两个 release 有十多个目录,所以一不小心取错就得从头再来。现在这个流程被放弃了,只保留一个 release 树,包含从 release 时开始的所有代码及变更。这样,我作为程序员,总算可以省点力气了,想必每天做 build 的人也省了不少力气。我猜想增量模式是因为对代码不够信任,又无法严格地使用标签(label/tag)。现在的开发流程中,限定了整个团队只有 leader 一个人可以提交 release 树的代码,也就是说必须经过他的 review,那么 release 代码树就相当可信,用不到增量了。

这个改变解决了两三个产品两个 release 的问题,然而昨天提到的 devel 分支的两个 release 的问题还是没有解决。最佳的实践是不同的 feature (无论是否独立),都拥有自己的分支(branch);然后定期做 rebase 操作,将主干(base)合并到分支,*而且*记录下已经 rebase 的主干版本,每次只合并**主干变化的部分**;最后,将分支合并(merge)到主干之前,先将分支 rebase 到主干的最后一个版本。

问题的关键是我们的 VSS 实践中,无法像在 CVS 中那样做“合并,解决冲突”的动作。VSS 的版本控制粒度有限,一个文件要么保留为自己修改的版本,要么替换为最新的版本。另一个问题是 VSS 无法根据标签来 diff 和 merge。这时应当将每次 rebase 的主干版本保存为参考树(reference),作为 rebase 时的依据。

devel 必须完成某种 stabilize 之后才可以用作参考树。参考树是用于 diff 和 merge 的,因此不必进入仓库,只需要在硬盘上保留一份,并应各 branch 维护者(各小项目 leader)的要求,提供不同版本间的 diff。这两个要求决定了参考树必须由专人负责。而记录某个 branch 目前已经 rebase 过的主干的版本号,将 diff 合并到 branch,以及最终的合并,都是由 branch 维护者负责。这样,责任就可以很明确。参考树可以由整个团队的 leader 负责,因为他对整体的稳定情况最为熟悉。

推而广之,如果所有开发都在自己的 branch 完成,而每次向 devel/head 合并一个分支,就形成一个候选的参考树,这样可能更有助于让 devel 更清楚,更容易稳定,因为每次向 devel 提交的都是一个 feature set,可以由团队的 leader 来整体地 review。要注意的是,这样做并不能取消参考树的维护。应当时刻考虑到 VSS 的弱点,参考树必须手工准备,具体的 rebase 的时机必须由 branch 维护者完成,而 rebase 所需的 diff 也必须容易地获得。
Tags: