关于开发管理的一些思考
目前我们组内对开发的管理还十分初级。Wiki刚刚开始用，没有用trac、bugzilla之类的工程控制工具，只用了Mercurial进行了版本控制，交流主要靠每周例会。
学生开发组织，我觉得是比较难做到规范化开发的。一则因为外围工具的学习成本高，项目等不及；二则因为学生组织与公司不一样，至少不会因为开发流程不规范而被fire掉。在学校里面，老板要的是效果、演示，不管你用什么方法去做。
在目前开发的过程中，也出现了一些问题。原来使用Mercurial的原因，就是一个DVCS看起来更适合我们项目。组内对于Xen都处于摸索的状态，需要做大量的实验，会产生大量的commit。使用svn的话，必须等到特性稳定之后才可以commit，不合适。
当然，实际使用过程中，我们仍然保持有一个“主”版本库，其中含有稳定的代码。原则上来说，主版本库更新之后，每个人都应该与之保持同步。
现在问题来了，大家都没有及时与主版本进行同步，所以现在diverge得越来越远了。到时再想merge的话，conflict将是一个很头痛的问题。但是用svn的话，这种情况就不会出现了。
当然，只要DVCS的使用者注意同步，这也不会是什么大问题。CVCS的好处是，这个步骤是强制的，不能有意无意的略过，大家必须保持一致。
现在我已经预见到以后merge会遇到的痛苦了。
UPDATE：和小胖聊了一下，发现其实还是工作流的问题。人是活的，工具是死的。工作流做好了，活用branch，CVCS也可以解决“不稳定的新特性commit”的问题。所以最现实的，就是把工作流做好。我们缺的不是工具，而是完整的工作流。
© 2010, liuw. All rights reserved.
最早我架过svn，也架过一个wordpress用来大家讨论留言什么的，我在开会的时候还说过。不过真的没办法，大家的思想太难改了，最后架好了基本就是我一个人在用。。
那时到是知道mercurial, 因为Xen就是用的这个嘛，不过hg确实没给我留下好印象，主要就是当时从xen的源下代码留下的，Xen庞大的源码，实验室的网络的龟速，及一旦checkou失败就得再重头checkout的悲剧。
我现在还是觉得Git比较好，至于merge的问题，估计可以采用linux kernel的开发方法，每个人fork一个主版本，在自己的版本上开发，然后发patch给你，然后你在主版本上打patch。。
不过真的很无奈，即使工作流搞好了，但大家的思想还是不转变，不养成好的开发习惯，我觉得还是没用。态度有点悲观了，恩。。
wayne(Quote)
wayne
19 Apr 10 at 13:05
@wayne
现在Wiki是强制大家必须每天都写，效果还有待观察。
Mercurial和Git没有本质上的区别，都是DVCS，都会有我文中提到的问题。要说导出patch，Mercurial也可以轻松做到。现在的问题是，他们fork之后，没有及时回归到主版本上，缺乏上下游版本的交流。
实际情况是，现在每人一个fork，最后patch和merge由我来做。但是开发流程不规范，编码风格不一致，设计理解得不够深，对Xen本身机制理解的不一致，带来了很多问题。merge的时候，很痛苦。
想解决问题，关键不是工具，而是规范和习惯，而这恰恰是我们最缺少的。大家的时间和精力都有限，开发任务重，太难了。
liuw(Quote)
liuw
19 Apr 10 at 15:03