项目进行二次开发，源码更新办法?
由于业务发展原因，之前开发的系统已经满足不了现在的业务需求了，所以后续对系统的二次开发会比较频繁；
但是这里就会涉及到一个问题：系统是用java写的，所以每次上线之前都会先把文件编译后，然后在生产线把相应的class文件会先备份后，然后覆盖。我想问的是，目前这个上线操作在市场上有没有比较成熟一点的更新方法，或者有其他的辅助工具？

背景描述：
由于现在我们有几个人专门对那个系统进行二次开发，也有比较规范的通过那个CVS来进行版本控制。可这样做的话，需求上线之后，系统有时候还会出现问题。因为每个人负责的需求可能不一样，比如A需求已经处理完毕，B需求还在测试阶段，但是A需求急着要上线，这时就会将B需求的相关源码也更新上去，但是B需求就会更新不完全，这样就造成生产源码管理不规范，系统出现问题的频率会比较高！

目前的想法就是：想在上线这个步骤上，做一个紧急的回退机制。万一系统出现问题之后，但是问题暂时找不出来的情况下，可以尽快回退到之前的版本，而不影响业务的进行！


所以请有经验的相关人士，提供一下你们的上线步骤，或者有什么比较好的更新工具或办法？

------解决方案--------------------
cvs这工具没怎么用，处理版本并发似乎不强。我们公司用IBM ClearCase 对于不同的版本会建不同的开发流
比如Version 1.2.1和1.3.0两个版本是同时开发的，每个版本都是继承至1.2.0。版本发布生产线后，ClearCase将上线版本归并到继承流
int
- fint 1.2.0
- dev1.2.0
- fint 1.2.1
- dev1.2.1
- fint 1.3.0
- dev1.3.0
其中int流是生产的，fint流是上staging(测试环境，也叫sandbox)，dev是开发用的。每次开发移交staging环境就会把修改的文件归并到fint流。测试完后将fint版本流归并到int流。
如上：fint1.3.0上线后会将fint1.3.0和int流进行比对归并（自动），如有冲突的地方由开发人员识别手工归并。

至于项目发布。我们采取：
1.发布应用程序版本，发布ear包
2.发布数据库版本，发布SQL脚本
3.修改配置文件，由部署人员根据部署说明项手工添加。
4.特殊部署（对于非正规系统的部署由部署人员手工执行）
以上1的应用包由编译平台脚本通过ant自动编译打包，并交付给部署人员，部署人员通过脚本命令进行部署
2通过脚本自动执行脚本内容
3.手工执行