版本管理 大项目不等于大 trunk

liuxue.gu@hotmail.com · 2012年08月23日 · 5 次阅读

董昊 http://rdc.taobao.com/blog/cs/?p=147

最近参与一个大项目,几十个开发人员,代码都放在一个 trunk 下,也就是说,这几十个人的代码都在一起编译,一起跑单元测试,一起在半夜跑自动化测试用例。反正我以前是从未加入过这么大的 trunk(之前我参加的项目最多就四五个人在一起写代码而已),现在发现巨大的 trunk 造成了一些很郁闷的问题。

首先,编译越来越慢。项目用 scons 来编译(我暂时还没发现 scons 比 Makefile 好在哪里),一编译就耗干系统的内存(我们的系统是 8G 内存),整个 trunk 重编译一次是两个多小时,好在我负责的只是其中一部分,但是即使是这一部分,也要花十多分钟编译(我目前还不能说这是 scons 慢造成的,但是 python 占内存偏多,嫌疑很大),这在我调试阶段很费时间。

其次,互相干扰很严重。几十个程序员,就算一个人每一个月才出现一次代码错误,那加起来就是:每天都有人至少犯一次代码错误。虽然使用了 ReviewBoard,但是 review 不可能洞察一切,还是会有单元测试频繁的不过。后来加了一个提交代码的工具,为每个提交代码的人单独编译并跑单元测试,通过了才真正交给 subversion,但这样还是有问题:每次提交,我都发现有很多人排着队的等前面的人编译完,我有几次好不容易排上了,跟别人的提交一起编译,结果由于别人的提交编译不过,我还得重新排队……问题的根源在于:这个 trunk 上的提交太过频繁了。毕竟几十个人呢,几乎每十分钟就有新的 code 需要提交。

可能长期在互联网公司干,我对那种动辄几百万行 code,几十兆可执行文件的大软件越来越反感。我觉得好的软件,一定是满足且刚好满足了某一类用户的某一个需要,而不是妄图去满足所有用户的很多需要。说白了:尽量做小巧的东西。如果项目真的是个大项目,那最好是能拆成多个小软件,好歹代码能分到不同的 trunk 下去,trunk 小了,挤在一个 trunk 下的开发人员就会少很多,就不会有漫长的编译和频繁的提交了,然后,这些小软件一起运行,完成某个大工作。

说得有点理想化了,把大项目拆成小部分,这个道理谁都懂,但难度在于怎么拆?这种问题我回答不了,也许《unix 编程艺术》能够回答:不要写一个巨大的进程,应该写多个,然后一起工作。进程都可以拆开,代码有什么不能拆开的?有人可能担心效率,但是相比于混乱的管理,这点效率损失我觉得还算值得。

以上是我的看法。实际中,反例也是有的,比如 windows NT 就是一堆人挤在一个代码 trunk 下做出来的,而且产品还很成功。但是从《观止》里可以看出,NT 的开发人员也一样被频繁的 build break 和单元测试 fail 折磨得人不人鬼不鬼,也许这就是为什么他们要辛苦上 6 年才能开发完成,以及为什么操作系统的未来是属于微内核的(微内核巧妙的把 OS 拆开了)

哪些工具可以做这些?

我猜想下,是否是在 pre-commit hook 中加了判断,在提交前触发调用编译工具执行编译、跑单元测试,成功后再执行 clean,和 commit。

有模块化吗?

模块化就能解决这个问题么?咋解决? 是否有必要都放在 trunk 上?

模块化后,各个模块形成单独的 repository,各自编译,然后再向一个大的 repository 做总的集成。

不知道 svn 是否支持。但是我觉得应该可以做到。

SCons 是出了名的慢,这个没啥可怀疑的。

貌似目前大 trunk 是发展趋势。

我们之前有 100 多个库各种模块,现在只有一个库一套代码了。

即使在互联网公司当中,Google 的 trunk 有上亿行的代码,5000 人一起工作,Facebook 的可执行文件有 1.5G。

是用的 svn 吗?是否涉及异地开发?把 100 多个库的代码归并到一个库里面,访问库的性能有没有受影响? 现在对与 svn 的性能问题比较关注,不知道哪些因素会影响 svn 性能。性能测试数据是怎样的。不知道哪里有。

现在我们不谈是否是 svn,我们单独来分析下是否是一个大 trunk 合适?

需要 登录 后方可回复。