请教各位公司都是如何做版本的日常构建的啊
请问各位公司都是怎么做版本的日常构建的啊？版本构建最头疼的是老有人的代码出编译错误，请问了解每日构建
请问各位公司都是怎么做版本的日常构建的啊？
版本构建最头疼的是老有人的代码出编译错误，请问了解每日构建的大侠，有什么样的机制和手段能保证构建质量？谢谢！
[解决办法]
Subversion?
[解决办法]
我们做持续集成用的是hudson，当然主要就是持续构建。
其实这也靠大家养成好的习惯。提交代码前，先update一下，然后再自己在本地build一下，没问题了再提交。
刚开始的时候，需要有个比较“讨厌”的人来促使大家养成这种习惯。如果谁在下班前打破了构建却拍拍屁股下班回家，可以从第二天开始，连续批斗一周，呵呵。
[解决办法]
[解决办法]谁出错，谁去维护每日构建，直到抓住下一个为止
[解决办法]这主要靠纪律，如果有谁这么干，天天批评，并扣发奖金
每次系统构建完成后，立刻发送邮件到所有人邮箱，谁最后checkin的名字也列上
[解决办法][解决办法]一般来说由于代码问题导致的编译不过,是能够靠单元编译来发现的吧.
BUILD时间太长,那能不能把整个工程划分为若干个小工程来缩短时间呢?
[解决办法][解决办法]如果某一天之后每个人都不出错
还需要Daily Build吗
肯定不需要
但是没有人能保证这一点
所以，每日构建的目的不是不出错，而是尽早发现错误
第二天发现编译不通过，还是很好定位和修改的
如果一个星期之后才发现，找出bug的代价就大了
针对公司员工能力不高的现状
每天能发现问题值得庆幸啊
[解决办法]有专门SCM管理人员是最好的，要不就让项目经理兼职这个了。
目前用得最多的SCM工具还是SVN(即Subversion，它从CVS发展而来的，同一个人写的)，由于是免费的所以使用很广，不过最专业的还是Rational的ClearCase了
[解决办法]SVN搞版本控制可以
[解决办法]使用svn，写编译脚本，每晚自动打包源代码，执行全部编译。如有编译错误，修改提交后马上做增量编译，应当能省不少时间
