三种最新自由软件管理开发工具介绍

      要预测接下来自由软件社区会有什么好玩的工具出现，确实是相当困难的。可是对于目前的国外社区中，有些趋势似乎在逐渐成型。这些部分，国内显然也有些社区朋友已经注意到了，那就是主动的参与相关社区的发展与讨论进而参与成为协助开发的角色。现在就趁这个机会来探讨一下这些专门开发工具的內容，看看他们对自由软件的系统开发及专门管理能有什么帮助。
　　                      版本控制系统：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在进行复制时，并不真的会把原来的档案复制一份，而只是产生一份连结。因此你可以以非常节省空间的方式来进行复制，当然也就是非常优雅地替你的系统做好分支。
　　于是有人提出了问题：“为什么都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来管理专案的日历以及相关的时程管理。不但如此，这项计划也受到许多国外的开放源代码社区的重视，当然还吸引一些国外专门进驻使用。