当今的软件开发更多是团队合作，团队的所有成员均工作在同一份代码库上。这样即便是有了先进的版本控制管理工具（诸如Subversion、Git等），出现冲突（Conflict）的情况也是在所难免的。这就需要你学会解决冲突。 以Subversion为例，多数人在学习这类工具时都选择了浅尝辄止，仅仅停留在会使用update和commit这些常用的命令上。这样大家就错过了那些可以帮助你快速解决冲突的命令，以致很多人无论遇到任何冲突情况都采用了低效的全手工处理的方式。实际上不同的冲突情形处理的方式是有差别的。某些情况下，利用类似svn resolve这样的命令可以帮你快速解决冲突。我们应该有意识地采用一些专业的做法，不是吗？^_^ ...
自从换装Ubuntu后，就一直使用Thunderbird。很是喜欢Thunderbird超快的搜索速度、按主题组织和展示Mail以及易用的快捷键。不过这两天Thunderbird一直在给我制造麻烦。通过Top查看，我发现我的Thunderbird一直在持续占用20%-30%的CPU，这导致我的本子变得很慢。虽然能看到这个进程，但是并不清楚Thunderbird究竟在做什么。开始怀疑它在后台压缩文件夹，我遂显式对每个mail较多的文件夹进行了一次压缩。压缩后Thunderbird似乎安静了一会儿，不过好景不长，不久那个进程又开始运转起来了。我怀疑这是个Bug，于是有了升级Thunderbird的想法。 翻看了一下Thunderbird的菜单，发现它似乎不支持在线升级更新。我使用的版本是3.0.6，官方最新稳定版本为3.1.9。下载最新安装包后菜发现这个包不过就是一个压缩的文件夹，文件夹里有Thunderbird可执行程序和一切它依赖的资源文件。这样看来Thunderbird的升级实际上就是一个“替换”的过程。 ...
近期产品线研发体系正式将Review Board这款优秀的基于Web的代码评审开源工具引入到开发过程中，作为产品线内各项目组进行代码评审的辅助工具。我对Review Board近两年多的关注总算没有白费，算是有了一个还算不错的结果。不过Review Board的正式使用并不代表一种结束，反而恰恰是一个新的开始。我们下一步要关注的是如何用好Review Board，让它真真正正地为改善产品质量和开发效率出力。 ...
部门一直使用Subversion作为源码版本的管理工具。说实话，Subversion比较适合目前部门的绝大多数项目：没有异地团队开发，代码中心化管理；基本上都在trunk上开发，较少使用分支，基本上没有在各个branch间切换的成本。但对于我来说，有些情况下Subversion并不能满足我的需求。 问题主要集中在本地代码的备份和版本管理上。也就是说对于尚未或暂无法提交到Subversion服务器的本地代码来说，存在着被误删除和版本更新无法回退两大杯具情形。而对于这些情况，Subversion工具是无能为力的。 这时我们就需要借助其它工具来帮我们解决问题。Git就是这样一款很给力的工具，它是一款分布式版本管理工具，由linux的缔造者Linus Torvalds设计并实现，具体关于Git的介绍和使用方法可参见其官方站。这里要说的是Git是如何做到既可以管理好本地代码又可以与已有的SVN中心库进行同步的。 ...
周四下午，收到同事的一封mail，他告诉我他的业务代码中使用的一个库接口的行为与预期不同，并在mail中给出了测试代码和测试结果。而这个接口是之前由我封装实现的。 ...
很多公司的过程中都有阶段性统计新增或修改的有效代码行数这一环节，这里先不论统计出的结果用于做什么，就统计本身而言，常常存在诸多问题，比如统计过程耗时且繁琐、统计结果中估算成分较大，不精确等。这些问题以前也一直困扰着我们，并且长时间没有想出很好的解决办法。 ...
记得上次折腾Review Board这个在线代码评审工具还是在一年前，那时的Review Board版本是1.0.3；这周部门的一位同事也在折腾Review Board，不过现在的版本已经升级到了1.5.1了。新版Review Board显然修正了许多旧版本中存在的问题，另外无法支持ssl邮件端口的问题也被我这位同事通过更换django源文件的方式搞定了。Review Board好用了，下一步需要关注的就是怎样才能用好Review Board的问题了。 ...
下班前，一位同事发来的mail中提到这样一个问题：在Solaris上，新添加到Project中的一段代码编译有Warning，由于我们在Makefile的GCC命令行中设置了"视警告如错误“的-Werror编译选项，导致了项目无法成功Build。 这个Warning内容如下： warning: `0’ flag used with `%s’ printf format 产生这个Warning的那行代码大致是类似这样的：printf("%05s%06s\n”, “11”, “222”); 其实这段代码是从老项目中Copy出来的，在老项目中，这段代码运行的很是正常，也许它在老项目Build时也会产生Warning，不过之前大家也都没有关注。 ...
除了autoconf和automake，GNU的autotools工具包中还有一种工具，它就是libtool。顾名思义，libtool是一个关于库文件制作、安装和使用的工具，它屏蔽了各个平台在库制作、安装和使用方面的差异，为上层提供了统一的接口。你可以直接使用libtool创建静态或共享库，也可以将libtool与autoconf、automake结合在一起使用。第二种方式显然更具实际意义，也更为简单。 在一个使用autoconf和automake构建的编译环境中添加libtool的支持，只需改动几处即可： 首先，你需要在configure.in(或configure.ac)中添加AC_PROG_LIBTOOL宏(注意：去掉AC_PROC_RANLIB宏)。 其次，修改Makefile.am： 如果是建立库文件，则需将lib_LIBRARIES改为lib_LTLIBRARIES，同时将库的后缀名由.a改为.la，这将告诉automake采用libtool来创建相关库： lib_LIBRARIES = libfoo.a => lib_LTLIBRARIES = libfoo.la libfoo_a_SOURCES = libfoo.c => libfoo_la_sources = libfoo.c ...
近两天一直在考量产品安装包改进的事宜。说实话，我们的安装包做得不够"专业"，不仅没有按照各个平台的标准安装包形式(比如redhat的rpm，debian的deb或solaris上的pkg包)制作，而且安装包在生产环境中还需要再进行一次链接才能得到最终的可执行程序。这样一来，每次制作安装包都很费时费力(虽然有自动打包脚本)，安装包的"体积"也很是庞大，因为包中要包含所有.o目标文件和一部分自有库以及第三方库的.a文件。 ...