2008年末和一位同事在山西出差，发现那位同事在用TiddlyWiki写一些日记，那时候算是第一次知道TiddlyWiki，但不知是为什么，当时的我并没有被TiddlyWiki所吸引，也就失去了一次使用TiddlyWiki的机会。

近期新启动了一个产品版本的开发任务，该版本是对之前遗留系统版本的重构和优化，我们想趁此机会将梳理遗留系统时总结下来的东西以及一些新的设计想法记录下来，以便于后人参考并迅速上手。曾经使用Confluence搭建过一个Wiki，但是该系统因公司政策被取消了。公司一年多以前建立了一个知识管理系统，不过我们发现这个系统极其难用，完全不能满足我们需要，这时我们又想起了TiddlyWiki。

TiddlyWiki应该算是世界上最小巧、最简单的Wiki工具了，只有一个大概300多K的html文件，所有功能都内置在该文件里，你编辑的内容也会在文件中存储着。从官方站下载后，用Firefox打开即算安装完毕了。

-> 定制你的TiddlyWiki
使用TiddlyWiki第一步想必都是定制界面吧。如果你想用TiddlyWiki写日记，那起码应该把Wiki页面上方的"My TiddlyWiki a reusable non-linear personal web notebook"字样修改一下，改成"Tony's Diary"之类的描述文字。另外英文看起来比较费劲，至少都应翻译成中文，TiddlyWiki默认采用UTF-8编码，对中文的支持完全没有问题。

TiddlyWiki默认页面中的"GettingStarted"会引导你做一些页面元素信息修改和定制。
* SiteTitle: 页面的主标题，点击斜体的"SiteTitle"，在延伸打开的"SiteTitle"编辑区域中找到"edit"，点击它编辑SiteTitle，比如改为“XX Developer Guide"。

* SiteSubtitle：
页面副标题，修改方式同上。

-> 关于Tiddler
在Wiki页面上你会看到较多的提示说明中都有Tiddler一词，官方给出的术语解释是”A content pane inside TiddlyWiki“，实际上Tiddler就是我们输入内容、图片、链接的地方。我们可以新建、修改和删除一个Tiddler，我们的Wiki实际上也是众多Tiddler的聚合体。系统有很多内建的特殊Tiddler，比如SiteTitle、SiteSubtitle、MainMenu、DefaultTidders(记录在启动时自动打开的Tiddlers列表)等，对于这些内建的Tiddlers建议保留。Tiddlers是按照名字识别和组织的，在页面右侧的包含多个Tab的那个栏里有一个"all" Tab，那里记录着所有的Tiddlers。
       
-> Tiddler内容编辑
新建一个Tiddler，我们就可以编辑Tiddler的内容了，一般我们最常使用文字、图片和超链接来表达我们的想法。

文字没有什么特殊的地方，顶多是字体上的差异，关于字体语法在中文TiddlyWiki上有详尽的说明。

贴图编辑格式：[img[果果|images/果果.jpg]] ，其中“果果”是鼠标悬浮在图片上时显示的文字，“images/果果.jpg”是图片的本地地址或Web Url”。当使用本地地址时，当前目录为TiddlyWiki文件所在目录。

链接到某文件：[[安装方法|install_guide.txt]]中的xxxx，其中“安装方法”将在界面中以带下划线的超链接显示出来，点击后Firefox会自动打开install_guide.txt; 如果把install_guide.txt换成install_guide.odt，那么Firefox会弹出对话框让你选择是打开还是Save。

链接到另外一个TiddlyWiki的Tiddler: [[安装指南|user_guide.html#快速入门]]中的xxx，其中user_guide.html是另外一个TiddlyWiki文件，“快速入门”是user_guide.html中的一个Tiddler，用一个#号将两者联系起来，这样点击后，Firefox会自动打开user_guide.html并跳转到打开的“快速入门”Tiddler上。

TiddlyWiki有一些高级功能还待挖掘中，不过估计可能也用不上多少，毕竟我们更多是提供内容。

由于不能为TiddlyWiki搭建一个Web服务器，因为那可能又与公司策略抵触，因此我们用svn管理TiddlyWiki文件(必要时可采用lock-modify-unlock模式。 另外TiddlyWiki毕竟采用的是单文件格式，一旦内容过多会导致文件Size过大，所以在使用TiddlyWiki之前最好做好规划，采用多TiddlyWiki files配合使用的方式，充分利用TiddlyWiki file之间的超链接和自动识别功能。

最后建议设立专人定期负责内容的整理和重编排，使信息的组织逻辑更清晰合理，也算是对Wiki的“重构”了。

近期在为一个新项目作版本库规划，并策划一些即将应用于该项目的版本控制和发布流程的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，到了在发布分支上再建立发布分支的时候了。但为了减少后期分支数多、在各个分支上同步代码工作量大且较难跟踪管理的情况，我们采取了一些措施。比如我们目前采取的策略是尽量减少版本的个数、减少发布的次数(达到减少发布分支个数的目的)，将两个版本之间交付间隔拉长（版本多为我们自己策划），将不同客户的需求转化为产品的通用功能进行统一管理，减少因版本功能差异带来的版本管理上复杂性。当然了也不能少了与客户沟通和协调，说服客户接受将其提出的个性化功能纳入到某个大版本中统一发布。

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