我公司目前有这个一个版本控制的难题：
开发背景：产品分若干模块，每个模块下有若干实现子功能的若干程序。产品功能不断扩充，程序版本也不断更新。
          产品过程的开发按“任务”分，每个任务对应一个需求上的功能点。
          一个任务分给几个开发人员开发，开发完提交到配置库，然后测试人员取出来测试。
          由于工期紧，往往是多个任务同时下发，这样就会出现开发某任务的一组人员也同时会涉及开发别的任务的穿插情况。
          任务间存在较多共用程序的情况。
我们配置工具用的VSS6.0，为体现出任务对应程序版本的关系，开发人员在提交的程序上打label（任务号）。本来是希望测试人员就可以方便通过label批量get对应的程序版本啦。但目前发现问题了：由于任务开发顺序不严格，任务穿插开发，不同任务按其label拿的程序之间谁覆盖谁就成了问题。 不能按任务号顺序，也不能按任务最终完成时间，因为一个任务可能拖很长时间，期间其它有共用程序的任务会插进来，测试人员如何取呢？？？
我也想，根源也许就在"任务"上，因为"任务"的维度与程序所在的产品模块是两个维度。不知采用“任务”开发的团队在版本上是如何管理的呢？求教啊~~~~~~~~~

[ 本帖最后由 hongerchen 于 2007-10-11 18:27 编辑 ]

按照LZ这么说，我们和你们类似，也会出现类似的问题。
1、我觉得关键在于项目的管理上，任务之间安排的更加细，每周甚至每天做任务的调整，小组之间的步调要一致，把关键任务优先解决。
2、从测试拿版本编译做测试的角度，我建议也要和项目组的任务一起来看，不是每天、随时都拿，那样的话，拿出来的版本是没有意义的。我们是每周编译一下，因此也要求项目组开发小组每周一之前必须拿出一个可编译的版本，必须自己手工编译通过。
3、不知道LZ你们的小组的开发关系，建议有时候可以按照小组来进行配置管理，例如：我们有一个小组做平台基类库开发的，他们的变动会带来整个项目的联动，因此他们的配置管理是单独了，只是定期发布稳定的成果，包含了新增的接口函数等，然后项目组其他小组都按新的内容进行更新


说了这么多，我不知道自己说清除了没有。我的主要意思是治标治本，还是从管理上解决问题，关键是做好任务的分配和安排，时间细化到每天，通过项目经理任务的调整，加上项目组的硬性规定，肯定能够在指定的时间编译出可测试的版本，如果拿不出来，那么接下来的开发工作就停止，直到编译成功。