近期在为一个新项目作版本库规划，并策划一些即将应用于该项目的版本控制和发布流程的Rules。借此机会我也花上一些时间对我们之前的版本控制和发布流程进行一下反思，也翻看了一些书籍(比如《版本控制之道-使用subversion》、社区自由图书《Subversion与版本控制》等)，了解一下Best Practice是什么样子的，同时也纠正一下我之前理解不正确的地方。

我们这些年来一直在使用CVS/Subversion这些版本控制系统进行源码管理，但若干年来似乎没有什么改善，仍然在走最初的路子进行版本控制和发布，这也导致我们仍旧挣扎在繁乱的版本库中。未经精心策划过的版本库组织及发布管理流程还在一定程度上降低了团队的工作效率。

年初曾协调开发团队和测试团队共同制定了一些版本管理和发布流程的改善措施，目前收到了一定效果，但是我个人觉得与最佳状态相比，我们还是有差距的。差距主要还是体现在对VCS系统的几个概念拿捏的不够好，比如说分支。

现在的程序员已经足够幸福了，前人经过几十年的实践给我们留下了版本控制的一些最佳实践，你在介绍CVS、SVN或GIT等VCS工具的书籍中都能读得到。之前没有静下心来好好读一读这类的书籍真是有些遗憾，走了许多弯路。

版本控制工具应用的核心应该是对分支、标签的把握，这其实也是最难的，它可不仅仅是简单命令的使用，而是体现着对软件开发流程的整体把握能力。

如何使用分支等高级概念取决于你对软件生命周期的规划，如果一个软件产品极其简单，简单到发布一个版本后就不需要增加feature和Bugfix了，那你根本不需要用到分支，甚至标签都可省去。但实际生活中我们面对的是一个复杂的世界，多数软件产品都会有一个较长的生命周期，在这个生命周期里程序员们需要为它增添feature，为它Fix bug，这样分支等概念就能派上用场，可以帮助你更佳清晰的管理版本以及提升开发和测试的效率。

Subversion引入了“TTB(Trunk-Tags-Branches)”的实践，其核心也是分支的使用。资料中多将分支分成两种类型，一种称为”Release Branch(发行分支)”，另外一种是”Feature Branch(特性分支)”。我们还是结合一个例子来说明两者的差异吧。

一般一个项目在初始阶段都会有相应的负责人对产品的版本进行规划，比如对与testproj这个项目来说，规划如下：
version 1.0.0
    – feature#1
    – feature#2
    – feature#3
version 2.0.0
    – feature#4
    – feature#5
version 3.0.0
    – feature#6
    – feature#7

规划版本号采用标准的[major.minor.revision]格式。版本库组织采用标准的TTB形式，即：
testproj(root)
    – trunk
    – branches
    – tags
之后大家就一起在trunk上编码，测试，提交，乐此不疲^_^。直到有一天开发leader宣布feature#1~#3编码+UT的工作基本OK了。下面的工作将会出现岔路口，一组人要继续在trunk上开发feature#4~#5，另外一组人则要继续执著于feature#1~#3直到1.0.0版本最终发布。分支此时该出面解决问题了。不过如何创建分支、创建什么类型的分支，出现了两种意见:
1、创建”发布分支，Release Branch”
                                        ——- Rel_1.0.0(Tag)
                                        |
         —–rel_branch_1.0 —————————->
         |
—————————————————————> trunk
如上图所示，在leader宣布feature#1~#3基本OK时创建了一个分支rel_branch_1.0，一组人将转移到这个分支上开发，另外一组将继续在thunk上开发后续features。QA对rel_branch_1.0进行严酷的测试，测试完毕后打Tag发布Rel_1.0.0正式版本。也就是说发布版是基于Branch的，且该branch会与trunk长时间并行开发一段时间（甚至可能很长），并得到足够支持。比如后续在trunk上或其他分支上发现的bug需要merge到该分支上，并在适当时刻发布补丁版本，比如Rel_1.0.1等。甚至可继续在此分支上继续增加新Feature，形成1.1.0等发布版本。

2、创建”特性分支，Feature Branch”

         ———Feature_branch_2.0 ——-
         |                                              |
—————————————————————> trunk
                 |
                 ——- Rel_1.0.0(Tag)
特性分支与发布分支恰相反，如上图所示，一组人继续在trunk上fix bug，直到Rel_1.0.0版本发布;其他人建立一个Feature_branch_2.0的特性分支，在该分支上开发新Features，并定期从trunk上merge trunk上的bugfix。Feature_branch_2.0开发完毕后，将分支代码merge回trunk，之后QA对trunk的最新代码进行测试，直到完毕后发布Rel_2.0.0，此后Feature_branch_2.0这个特性分支已经不再需要，它的生命周期也到此为止，可删除之。

两种类型分支如何选择呢？其实实际软件开发中两种类型分支是你中有我，我中有你的。如果从宏观来看，其实更多还要看你的产品的特点和规划，如果类似GCC这样的产品，“发布分支”必不可少。比如我曾用过的GCC的版本有2.95.x、3.2.x、3.3.x、3.4.x等，GCC对于每组[major,minor]都要有一个“发布分支”，至少是用来fix bug的，在3.2上发现的bug要同步回2.95，发布2.95新补丁，除非GNU宣布对GCC 2.95不再支持。如果一个产品的bugfix不需要回溯到以前的版本，而是一直采用trunk上的最新版本，那特性分支则更适合，这样也避免了在N多发布分支上频繁merge代码的情况了。但是特性分支不宜建多，最初我也考虑是否每人建立一个关于自己任务的分支，后来发现这样会给后期merge代码带来诸多不便。

发布分支上如果要新增个性化feature，就好比发布分支变成了”trunk”，后期也可以采用feature分支的形式来开发，保持了”trunk”上代码的稳定、可用;当然如果不太在意这点，你大可直接在该”trunk”上直接开发。

目前我所在的产品线采用的就是发布分支和特性分支结合的方式，不过产品的电信行业背景决定了产品需求多变、客户间需求差异较大，增加了我们的版本发布管理复杂性。单独在该分支上采用“特性分支”的开发流程已经不能满足需要了，因为我们有时候需要回溯到某个早期发布版上fix bug或增加feature，到了在发布分支上再建立发布分支的时候了。但为了减少后期分支数多、在各个分支上同步代码工作量大且较难跟踪管理的情况，我们采取了一些措施。比如我们目前采取的策略是尽量减少版本的个数、减少发布的次数(达到减少发布分支个数的目的)，将两个版本之间交付间隔拉长（版本多为我们自己策划），将不同客户的需求转化为产品的通用功能进行统一管理，减少因版本功能差异带来的版本管理上复杂性。当然了也不能少了与客户沟通和协调，说服客户接受将其提出的个性化功能纳入到某个大版本中统一发布。

工具和概念都有了，一切还在于人的规划。简单和清晰是我们应该在版本规划、控制和管理中追求的目标，这样才易于理解、易于执行，减少不必要的工作，毕竟不是所有人都是这方面的专家。

自从知道Ubuntu这个linux发行版后，就有了彻底迁移到Linux上的想法。但迫于各种各样的因素一直未能下定决心，这期间Ubuntu发行版已经从6.10进化到了10.04。经过长时间(近四年，时间长的的确有些夸张^_^)的准备，再借着Ubuntu 10.04 LTS发布的东风， 我终于下决心彻底走进Ubuntu的世界。

安装Ubuntu对我来说已经是驾轻就熟的事情了，这里也没什么好说的。对我来说，迁移到Ubuntu的主要工作集中在：
1、完成两个平台数据共享和迁移
2、选择和安装用于替代Windows上常见应用的软件

Ubuntu在与Windows分区互操作方面作了很多工作，Ubuntu下打开Windows分区与访问Ubuntu分区基本没什么区别，无论是NTFS还是FAT32(vfat)分区，保存在Windows分区中的数据都可以直接被访问和使用。

我平时使用最多的就是文本文件了，在Windows下使用GVIM或记事本打开;在Ubuntu下可继续使用GVIM(gedit已经被我卸载)。当然,VIM需要做一些字符集转换方面的设置才能保证对文件中的中文字符做正确的转换，具体如何配置可参考我的上一篇文章。

平时工作中最常用的沟通方式就是Mail了，之前在Windows下使用Thunderbird收发Mail。当初之所以舍弃Outlook而转用Thunderbird也是为今天转移到Linux上工作做的准备，因为只有Thunderbird才能很好的支持在多个平台间共享数据，共享数据的配置方法可参考我去年写的一篇关于thunderbird的文章。

之前在体验Ubuntu9.10时知道了iBus这个新输入法框架，当时的体验还不错，不过使用10.04后，发现Gvim/Vim和iBus有冲突，在Vim下Insert模式和Normal模式切换时iBus提词窗口总是自动退出，严重影响输入效率，后换成fcitx后冲突解决。

公司的办公软件早在年初就都切换到OpenOffice 3.0上了，公司的所有模板、通启也都以OpenOffice的文件格式发布了，所以在日常文档编辑和数据交换方面不存在什么问题。不过对于Microsoft专有格式的Project和Visio我目前还没有找到合适的替代品。

日常开发过程中，组内同事喜欢使用Feiq作为内部即时通信工具，可惜Feiq只有Windows版本，我曾经尝试用Wine 1.2去装载和运行Feiq，但都提示错误。无奈下，只能选择iptux。iptux采用的是以前飞鸽传书(ipmsg)的协议，只支持文字和文件传输，不支持在对话框中直接贴图。

思维导图软件近几年很受大家欢迎，之前一直在使用MindManager。迁移到Ubuntu上后，急需找到一款MindManager的替代品，而且还必须可以打开MindManager格式的文件。XMind恰是我所需要的。测试了一下，使用习惯和界面布局与MindManager差不多，且导入MindManager的文件也很顺利。

tortoriseSVN想必是每个使用svn作为代码版本控制工具的程序员必装的一款svn客户端软件，功能很强大，易用性也很好。不过在Ubuntu下可没有这么好的运气，也曾尝试过用Wine运行TortoriseSVN，但以失败告终。看见Ubuntu软件中心中有一款名为RapidSVN的工具，安装试用了一下，发现与TortoriseSVN差距很大，在没有找到更好的软件之前，先凑合用着。

Windows优化大师之类的软件我是一概不会安装的，但在Ubuntu下，国人开源的一款工具Ubuntu Tweak值得支持一下。特别是对linux桌面和窗口配置还不是很熟悉的情况下。

注重实效(pragmatic)的程序员都会在电脑里安装一款能帮助快速打开程序、快速定位文件的程序。Ubuntu下有Gnome Do，但是我更喜欢Launchy，之前在Windows上就用Launchy。现在发现Launchy也有Ubuntu版本，这样就不须重新学习了。

公司的某些OA系统对Firefox的支持很差，于是我下载安装了Chromium Web Browser，这个浏览器的体验不错，而且上述问题也得到了解决。不过由于使用Firefox + Vimperator时间久了，习惯了用一个'd'关闭一个标签页的VIM化的快捷命令，我暂时只将Chromium作为备份浏览器使用。

公司办公以台式机居多，这样在开会的时候我们会经常通过远程桌面访问到自己的PC上; Ubuntu内置远程桌面访问工具，而且可以命令行操作，rdesktop -f ip -u USER_NAME -p PASSWD即可直接进入你的PC桌面，就好比你在操作你自己的机器一样。你可以在.bashrc中用alias给上面命令串起个别名，这样只需敲入一串别名即可完成远程登录和操作了。

上周安装Ubuntu 10.04.1后，曾经有一种删除本子上Win7的冲动，但后来还是将Win7保留了下来。因为还有一些操作是在Ubuntu下无法做到的，比如说招行专业版。另外国内很多知名站点（如中国网络电视台）对非IE浏览器的支持都不好，有些时候你还不得不使用IE。

Ubuntu 10.04总体来说还是很稳定的，不过在使用过程中也有一些小插曲，比如：XWindows曾两次提示重启，点击确定后，N长时间也无法回到GUI界面，无奈只能重启系统。再比如：Ubuntu接投影后，桌面只能显示出2/3区域，似乎是我安装的Docky出现了什么问题。关闭Docky后，一切OK。

适应Ubuntu Linux的过程还在继续，希望过了磨合期后一切都会越来越好^_^。