你所在的开发团队提交到CVS上面的代码有什么样的要求？分支蔦\0...

因为原来开发时出现编译过不去的，所以，强烈要求加强对于编译的重视，后来编译问题得以重视，CVS上面的代码可以保证编译了。
但是现在出现了争论，认为不可能保证CVS上面的代码都好用，我认为要在开发的过程中开发人员要保证主线的流畅。

能不能将项目规模以及人员对于CVS掌握时间有大致的描述？

开发人员达到80人，是一个大项目，可惜管理就—— sigh~~

我在的团队最多的时候有33人，现在只有10人左右。由于当时很大部分人对于CVS的使用都没有什么认识，所以导致花掉了差不多1到2个月的时间在熟悉CVS的基本使用，然而在开发的过程中没有很好的注意到提交的代码的测试质量，从CVS上下代码来打包编译的话，肯定是不能用的。

然后我们合作公司的做法，竟然是要求先测试通过了再提交CVS，当然，这个和当前的状况也有关系，我们所有的用例都会和一个工作流的产品打交道，而这个工作流的产品，目前不是很稳定，导致如果我们的流程有任何变动，都只能够全部调整完成才可一起发布，非常被动。

可以做到 cvs 上的代码是可用的代码。
cvs 上的代码可以 compile 是最基本的要求。
如果你们写测试，最好能做到 cvs 上的代码都能通过测试


但是要做到这点，除了让开发人员熟悉 cvs 这个工具外，还得让他们理解和遵守一定
的开发规则。

我们使用 XP ，写代码的时候也写测试，是这么做的：
提交到 cvs 的代码必须有测试，而且在提交前必须在本地通过所有测试。
具体做法看这篇文章：
http://cinc.3322.org/mywiki/AddNewFeatureToSystem


另外还有一项技术，叫 Nightly build，或者叫每日构建，也必须遵守：

专门拿一台机器做 integration test，写个脚本，每天晚上，自动从 cvs 获取最新的
代码，然后运行所有的测试，并生成报告，并把报告发给 manager。
如果有错，第二天必须先修正错误后才能继续做开发。
其实 apache 的项目都使用了 nightly build 技术。
有本书介绍，好像叫《cvs 和 nightly build 技术》

开始的时候会比较痛苦，但是必须强制执行，必要时实现一些奖惩制度，但这样可以很好的保证软件的质量。
慢慢的，习惯了这种做法，对将来的开发会很有好处，也不用到了快 release 的时候才加班
加点的找 bug。

顺便说下，10 个人的开发小组已经是很多了，我们一般不超过 8 个人，人越多，浪费在管理
交流沟通上的时间越多。

nightly build也使用过。
我的要求是在写代码实现的之前要先有测试用例，这样就比较自由了。
因为有了测试用例说明已经对设计完全理解了，而且通过测试可以得到当前的项目进度。那些通过了哪些没有通过，错误是什么。

gKarerM ,哈，才知道你原来有那么多马甲：）

我投了第三项，居然是最多的。