VSS 还是我们所用的版本控制系统,短期不会有变化了。我们的大规模开发指的是,两个到三个
过去 VSS 采用一种相当傻X的增量模式(而且用了好久!不知道是怎么想的),假如我需要取到完整
这个改变解决了两三个产品两个 release 的问题,然而昨天提到的 devel 分支的两个 release 的问题还是没有解决。最佳的实践是不同的 feature (无论是否独立),都拥有自己的分支(branch);然后定期做 rebase 操作,将主干(base)合并到分支,*而且*记录下已经 rebase 的主干版本,每次只合并**主干变化的部分**;最后,将分支合并(merge)到主
问题的关键是我们的 VSS 实践中,无法像在 CVS 中那样做“合并,解决冲突”的动作。VSS 的版本控制粒度有限,一个文件要么保留为自己修改的版本,要么替换为最新的版本。另一
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 也必须容易地获得。