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 也必须容易地获得。
