要預測接下來自由軟體社群會有什麼好玩的工具出現，確實是相當困難的。可是對於目前的國外社群中，有些趨勢似乎在逐漸成型。這些部份，國內顯然也有些社群朋友已經注意到了，那就是主動的參與相關社群的發展與討論進而參與成為協助開發的角色。現在就趁這個機會來探討一下這些專案開發工具的內容，看看他們對自由軟體的系統開發及專案管理能有什麼幫助。

版本控制系統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等。除了使用svnserver作為服務器，亦能配合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六月推出」一文。