要预测接下来自由软体社群会有什么好玩的工具出现，确实是相当困难的。可是对于目前的国外社群中，有些趋势似乎在逐渐成型。这些部份，国内显然也有些社群朋友已经注意到了，那就是主动的参与相关社群的发展与讨论进而参与成为协助开发的角色。现在就趁这个机会来探讨一下这些专案开发工具的内容，看看他们对自由软体的系统开发及专案管理能有什么帮助。

版本控制系统Subversion:

这是目前开放源码社群中，当红的版本控制系统专案。根据一般的说法，也就是即将取代 CVS (Concurrent Version Control) 的开放源码版本控制系统。 CVS 一直以来几乎都是开放源码专案的标准版本控制系统，也就是几乎大多数的开放源码专案都有提供 CVS 的档案库让一般使用者来取得专案的源码。但是随着开放源码社群的快速成长，有许多专案也不断的成长，渐渐的，CVS 似乎有些瓶颈。于是许多新的版本控制系统陆续出现，例如 Aegis，Bitkeeper 或是 Perforce。相较于 CVS，这些后起之秀其实以功能性而言，其实大多好过 CVS 不少。但是不论是哪一套系统，似乎都多少有些版权上的限制，或者基本上就是商业软体。所以虽然有很多大型开放源码专案使用这些版本控制系统 (例如 Linux 核心开发就是使用 Bitkeeper，而 Perl 团队则是使用 Perforce)，但是却很难像 CVS 这么广泛的被使用。

然而这些新一代的版本控制系统却指出了一些方向，或者也可以说，他们确实提出了一些见解，在专案越来越庞大时，专案管理上到底需要什么样的版本控制系统，而确实也获得了许多肯定。但是这些拥有强大功能的版本控制系统却各自有着不同的问题，例如被Perl 核心开发团队所用来进行开发使用的Perforce 就是属于商业软体，虽然支援开放源码计画的开发，但是一但进行商业使用，就必须负担一笔不少的软体费用。但是并非所有人都希望多学习另一套的版本控制系统，却只能用来进行某些专案的开发。因此虽然许多看起来在功能性虽然相对于 CVS 有着绝对的优势，但是却无法动摇 CVS 在开放源码社群的地位。

但是对于许多透过 CVS 管理的专案却遇到越来越多的问题，例如要在 CVS 上进行分支，虽然功能上可以达到，但是却也相当困难。类似这样的问题在 CVS 逐渐发展的过程持续的浮现出来，但是以 CVS 最初的设计结构，要一一修改这些为人所诟病的问题却并不容易。而且 CVS 的学习曲线相较于后来陆续开发出来的各种版本控制系统明显来得陡峭。这许多的原因让 CVS 团队决定以改变底层的结构来进行时代性的转变，而这个计画正是 Subversion 专案的起源。

首先，Subverion 改变了原来 CVS 一个存档就是一个版本的问题，而是让使用者可以在解决一个问题之后，再一次把所有修改的档案送回伺服器上。这么一来，即使我们发现送上去的档案把原来的系统搞烂了，也可以透过回到上次的版本而恢复系统正常的状况。使用 Subversion 进行系统的分支比起 CVS 也显得容易许多。因为基本上如果你希望在 Subversion 上产生系统的一个分支，你只需要将现有版本进行复制就轻松的完成了分支的动作。如果有人使用过 CVS 来进行分支，大概会觉得这样的方式简单地近乎不可思议，也因此反而让人不太容易安心。其实因为所谓的分支，其实只是从目前的系统版本复制一份，并且能够保存原来的系统纪录 (log)，所以 Subversion 的作法实在是能够确实理解的。另一个使用 Subversion 来进行分支的大利多则是空间的使用。 Subversion 在进行复制时，并不真的会把原来的档案复制一份，而只是产生一份连结。因此你可以以非常节省空间的方式来进行复制，当然也就是非常优雅得替你的系统做好分支。

如果有人使用过 CVS 来进行分支，大概会觉得这样的方式简单地近乎不可思议，也因此反而让人不太容易安心。其实因为所谓的分支，其实只是从目前的系统版本复制一份，并且能够保存原来的系统纪录 (log)，所以 Subversion 的作法实在是能够确实理解的。另一个使用 Subversion 来进行分支的则是空间的使用。 Subversion 在进行复制时，并不真的会把原来的档案复制一份，而只是产生一份连结。因此你可以以非常节省空间的方式来进行复制，当然也就是非常优雅得替你的系统做好分支。

于是有人提出了问题：「为什么都 2004 年了，还有人在写版本控制系统？」，因为 Subversion 虽然大幅改进了 CVS 的不足，但是却让人有更多的期待。于是 SVK 利用 Subversion 的基础开始发展了起来。

离线版本控制系统SVK

当我们在使用 Subversion 的时候，似乎有些时候会发现系统完全不灵光了。例如我在火车上想要拿出笔记型电脑来解决某个程式上的问题时，却发现我没有办法透过 Subversion 来工作，因为我没办法取得版本控制上的任何资讯。等到你终于回到网路世界时，可能得面临解决在你离线的期间，跟其他人修改的部份冲突。而且当初 Subversion 刚开始发展时，程式执行的速度实在不特别让人满意。后来在功能部分大致底定之后,开发团队才慢慢修正执行效率的问题,但是这些原因却让 SVK 正式诞生了。

SVK 其实是根基于 Subversion 之上，也就是利用 Subversion 的档案库，以及大量的 Subversion 函式库所开发出来的 Perl 程式。而且主要的概念在于可以进行分散式管理的版本控制系统，所谓分散式的意义其实就在于每个人都应该要可以简单的复制一份完整的档案库在自己的电脑中。用比较口语的解释，也就是说，每个人在取出一个Subversion 档案库时，其实就可以映射(Mirror)一份在自己的电脑中，而这一份映射就可以包含所有修改内容以及纪录档案的完整资料库。

这样一来，如果你在你的笔记型电脑取得了一份完整的档案映射，你所有关于档案库的操作都可以离线进行。因此即使你在火车上或飞机上也都可以正常工作，而且你每次工作到一个段落时，也都可以把档案送回(commit) 档案库中，只不过这时候你的档案库其实是在你自己的电脑中，不过至少你可以安心的进行自己本地的版本控制。

可是接下来还是有另一个棘手的问题，也就是当你在离线进行工作时，还是可能发生和其他人修改了同样档案的问题，因此只要你想要把自己映射下来的这一份档案库和本地的档案库进行同步化，合并是非常重要，而且免不了的状况。既然大量合并是分散式版本控制必须面对的一个问题，因此如果每次合并都必须人工去确定就显得不太智慧了。所以 SVK 发展出自己的 smerge，也就是「聪明的合并方式」，透过这样的合并方式，只要大家修改的部份没有造成冲突，SVK 可以自动的完成合并的动作。而最近更进步的发展则是当你在送回档案时，发现修改的步奋发生冲突，那么 SVK 可以呼叫图形介面的合并工具程式来帮助你完成合并的工作。这个部份其实满重要的，因为在Subversion 的部份，一但发现修改部份产生冲突，他会产生新的档案，并且标示两边发生冲突的状况，但是却必须手动去进行解决，而没有好的工具可以帮助使用者进行。因此这一部份，SVK 就显得平易近人多了。

专案追踪系统RT及RTx::Foundry

刚刚我们所提到的两个都是关于版本控制，这对于专案的开发占有非常重要的地位。很多人可能并不觉得，但是这些人却通常花了更多时间用工人智慧来进行类似的工作。而除了专案开发之外，专案管理也是非常重要的一部份，尤其当一个专案慢慢成长，参与的专案成员也慢慢增加时，要如何管理专案的进行就显得非常重要了。当然，进行工作管理的重要部份就是工作的安排以及追踪。

这种事件追踪的系统其实并不少见，例如有名的 Bugzilla 就是很好的例子，而另外一套相当受到欢迎的则是 RT。当然，以单纯的事件追踪功能而言，两套系统都相当足以应付大多数的需求。但是以跨平台的容易性与方便性来说，RT 发挥的空间就占有较多的优势，尤其在Windows 上的安装，这对Bugzilla 几乎是非常难以达成的，可是RT 却有已经打包好的安装套件，使用传统的Windows 「下一步」安装法，很快就可以装起一套RT。

利用 RT，可以让专案的计画与工作的分配与追踪变得十分容易。对于 RT 来说，每个专案就是一个「表单」，而专案的每一个工作项目则是一个「申请单」。因此当我们有了一个新的表单时，也就是我们开了一个新的专案。接下来，只要关于这个专案的相关工作，我们就透过这个专案的申请单来控制。当然，每个工作都可以指定给专案中的成员。所以我们可以很快的掌握专案中有那些待解决的工作，而且谁应该来负责这些工作。

透过上面的方式，我们可以很简单的追踪专案中的各个工作项目的状态与进度，并且透过系统进行讨论。但是对于一个完整的专案来说，我们需要的东西更多，就像 sourceforge 一样，我们并不是只有事件追踪，我们还需要管理文件，系统的版本以及各式各样的讨论。而 RTx::Foundry 就是以 RT 为底层架构，结合各种资源所产生的专案管理工具。

RTx::Foundry 其实是整合了RT，Kwiki，Sympa，以及Subversion 的复合式专案管理介面，也就是说，他只是所有这些套件的统一介面，而所有的操作就透过这些套件原来已经运行的十分顺畅的功能来进行。而且这个计画目前还在中研院继续发展中，目前也有更完整的专案计画支援，所以专案的管理员可以利用 RTx::Foundry 来管理专案的行事历以及相关的时程管理。不但如此，这项计画也受到许多国外的开放源码社群的重视，当然还吸引一些国外专案进驻使用。

延 伸 阅 读

Subversion 1.0版本的新功能包括atomic commit、directory versioning、file renaming等。除了使用svn server作为服务器,亦能配合Apache httpd 2.0使用以达到更fine-grained的 access control。相关介绍请见「Subversion 1.0弥补CVS缺陷 」一文。 Subversion 安装简易指南，说明在Windows环境下安装 Subversion伺服器的步骤，以及TortoiseSVN用户端工具的安装步骤。你可在「 Subversion for Windows安装指南 」一文中得到进一步的介绍。 CVS（Concurrent Version Control System）是一个能让很多程式开发者同​​时做软体开发的非常强大工具。它使用了RCS的档案规定格式但多了一层像应用程式介面的包装，架在RCS的上层。在「CVS功能简介 」一文为你做了相关的评析。 越来越多的核心开发者开始使用BitKeeper工具来管理补缀（patch）和补缀的过程。亳无疑问的，BitKeeper不是自由软体，因此许多核心开发者决定不使用BitKeeper。在「开发Linux内核所使用的BitKeeper本身却是私权软体」一文为你做了相关的评析。 BitKeeper是一个分布式开发环境的软件源码管理方案，其出现与Linux Kernel开发有莫大关系，因为Linux开发工作日渐庞大，BitKeeper的可扩展性，令即使有超过一千人参与，开发工作也可井然有序，BitKeeper针对的是未来即将涌现的各式开放源码项目。在「BitKeeper源码管理方案」一文为你做了相关的评析。 SVK内定的「预设仓储」目录（也就是 '//'）在 ~/.svk/local，你可以在后面加上更多的仓储名。在「depotmap」里面，一行便表示一项仓储的目录对应。在「从本机仓储介绍SVK的使用」一文为你做了相关的评析。

最新消息	Linux计画创始人linus Torvalds上周表示，最新版的Linux作业系统核心将在明年六月就绪。除了宣布新功能与程式码截止日外，Torvalds也因应Linux的成熟化作了其他改变，例如他在今年二月将Linux程式码的管理转移至专属的BitKeeper软体上。相关介绍请见「新版Linux六月推出」一文。