2002年的Bug A与2008年的Bug B同时穿越到2013年，并在某个场合相遇了。

上周六，项目组本应以一个愉快的心情结束一天的工作的，但一个2002年的Bug A与另外一个2008年的Bug B同时穿越时空来到了2013年，并且恰恰在那时那刻（下班前）相遇了，于是项目组由放松变成了忙碌，由愉快变成了紧张，17：30的下班点也因此延迟到了凌晨1：30。

Bug A来源于2002年我们发布给客户的一版客户端API，严格来说称其为Bug不免有些冤，它只是遇到Bug B时才会被触发，其只是在处理机制上缺少一些容错的考虑罢了。Bug B才是名副其实的Bug，居然明目张胆地违反协议，擅自在登录应答包的Body尾部补了一个字节的“脏数据“，导致使用我们客户端API的某企业短信通知系统出现故障。

关于这次的“故障”，我想感慨的不是这次的Bug有多么的诡异难找，而是下面这几点：

* 生产环境中场景的复杂性与多样性

任你用例再多，测试人员经验再丰富，脑力再强大，也很难设想出如此之情形。往往我们在模拟环境中测试的都很好，开发和测试人员都手拍胸脯保证说：“没问题了”。但一到生产环境中，问题就像滚雪球一样越来越多，弄得大家焦头烂额。究其源头还是在开发人员这里，开发人员是第一责任人。已经离职的制造出这两个Bug的“前辈们“肯定不会想到，他们的Bug居然穿越到2013年相遇了，否则我相信他们在当时一定会认真对待代码的。

* Bug是藏不住的

通过此例可以让我们看到：Bug终有一天是会暴露的，是藏不住的。这“潜伏”了10多年的问题不也在这次事件中暴露出来了吗。所以说我们写代码的时候，一定要心中有“追求0bug”的理想和目标，严格要求自己和自己的代码，采用各种手段，如代码评审、单元测试、持续集成、自动化的模拟环境验收测试等对所写代码进行“残酷”的打磨和考验，让Bug遛到生产环境的机会尽可能地小。

* 版本的变更管理有漏洞

这又是一次在产品升级后导致的“故障”，原因在于没能完整的识别出这次升级带来的所有软件变更。其少引发Bug B的那行代码的“作用”没能识别出来。这的确是个难题，如果不是原开发人员或评审人员“自发”上报此处的变更，这个变更太容易淹没在代码海洋中而丢失了。目前似乎也没有太好的办法。如果未来能有一种自动识别版本间代码不同且能识别出差异代码的语义变更的工具，那么我相信这款工具一定大卖。 

当今的软件开发更多是团队合作，团队的所有成员均工作在同一份代码库上。这样即便是有了先进的版本控制管理工具（诸如Subversion、Git等），出现冲突（Conflict）的情况也是在所难免的。这就需要你学会解决冲突。

以Subversion为例，多数人在学习这类工具时都选择了浅尝辄止，仅仅停留在会使用update和commit这些常用的命令上。这样大家就错过了那些可以帮助你快速解决冲突的命令，以致很多人无论遇到任何冲突情况都采用了低效的全手工处理的方式。实际上不同的冲突情形处理的方式是有差别的。某些情况下，利用类似svn resolve这样的命令可以帮你快速解决冲突。我们应该有意识地采用一些专业的做法，不是吗？^_^

这里简单回顾一下版本冲突的产生过程：

- 版本库中存在一个代码源文件Foo.c，当前修订号：#BASE-REV；

- 甲、乙二人同时Checkout出文件Foo.c的最新版本#BASE-REV；

- 乙对其本地目录下的文件Foo.c进行了修改，并提交了代码，提交后文件Foo.c的修订号变为了#HEAD-REV；

- 由于缺乏沟通或沟通有误，在不知乙已经作出修改的情况下，甲也对其本地的文件Foo.c进行了修改；

- 当甲尝试将其本地目录下的Foo.c文件提交（commit)到代码库时，SVN给出错误提示：提交失败(细节如下): … …；或当甲尝试Update最新代码到其本地目录下时，发现SVN给出冲突提示："C    Foo.c"或在 “Foo.c” 中发现冲突…。

Subversion 1.5版本之前不支持所谓的"交互式冲突解决(interactive conflict resolution)"，而1.5之后的版本则支持这种交互式的解决过程，即当冲突时，你会在控制台上看到的这样的提示：

在 “Foo.c” 中发现冲突。

选择: (p) 推迟，(df) 显示全部差异，(e) 编辑, (h) 使用帮助以得到更多选项:_

如果你选择p，或者你用的是低于1.5版本的Subversion，你在执行svn update后会在你的本地目录下得到如下几个文件：

Foo.c  Foo.c.mine  Foo.c.r#BASE-REV  Foo.c.r#HEAD-REV

分别解释一下这几个文件：

Foo.c – 这个是由Subversion自动将版本库中的最新改动合并到你本地的一个包含了<<<>>>等标记的冲突文件；

Foo.c.mine – 这个是甲在执行svn update前自己修改的那份Foo.c文件；

Foo.c.r#BASE-REV – 这个文件的内容与修订号为#BASE-REV的Foo.c文件一致，也就是那份基（Base）文件；

Foo.c.r#HEAD-REV – 这个文件是乙修改后并提交的Foo.c文件，也是目前代码库中的HEAD revision。

那么甲如何来处理这个冲突呢？在不会使用svn resolve命令之前，甲很可能会这么做：打开Foo.c，逐个冲突进行解决。然后删除其余的三个Foo.c.xxx文件，最后提交代码。

这么做无可厚非，不过不是所有情况下都需要这么做的。我们将冲突情况进行一下分类：

1. 甲的代码完全包含了乙对Foo.c的修改，Foo.c.mine中的内容正是我们想要的;

2. 乙的代码完全包含了甲对Foo.c的修改，Foo.c.r#HEAD-REV中的内容正式我们想要的；

3. 甲、乙两人修改的代码确实存在不可融合之处，那么需要手工分析和解决Foo.c中的冲突。

下面我们用svn resolve命令分别处理上面三种情况：

针对情况1，甲可直接在自己的环境中执行svn resolve –accept mine-full Foo.c，执行后，冲突状态消失，甲可以从容地提交代码了；

针对情况2，甲可直接在自己的环境中执行svn resolve –accept theirs-full Foo.c，执行后，冲突状态消失，甲也可以从容地提交代码；

针对情况3，工具无法给予甲更有力的支持了，只能依靠甲自己去打开Foo.c并手工解决所有冲突了。待所有冲突解决后，执行svn resolve –accept working Foo.c或直接删除其它三个Foo.c.xxx文件，使冲突状态消失，Subversion这时将允许你提交你的代码。

有两点需要注意的是：

1. svn resolve命令只是在Subversion 1.5以及以后版本中才提供，在1.5版本前Subversion提供了一个resolved命令，不过这个命令似乎不是那么给力，基本上和你手工解决没啥差别，1.5以后这个resolved命令就被废弃了。

2. 对于第三种情况，一旦你删除了其余三个Foo.c.xxx文件，那svn就会认为你的冲突状态已经不存在了，这时即使你的Foo.c中依旧包含<<<>>>等冲突标记也是可以提交成功的，这里要小心对待。

另外对于情况3，如果甲并不想打开Foo.c手工解决冲突，而是想Undo自己的修改的话，那么甲可以通过执行svn resolve –accept base Foo.c或svn revert来将Foo.c恢复到#BASE-REV状态。接下来可以先update到乙的版本，然后再做出自己的修改。不过此前要做好代码的备份，否则一旦执行这些命令，甲之前所作的修改就会瞬间消失。