cahier lukhnos

上一篇文章裡提到，我們想開發一個「（以任何現有輸入法）打完地名，輸出與地名相關之地理資訊」的新「輸入法」──或者是「超輸入法」（meta input method）。我們在上一篇文章針對了需求做過了分析，並評估了一下OpenVanilla能派上什麼用場。我們拿到了一份「生」的XML的原始資料，將它煮成了SQLite資料庫所需的SQL指令檔。

我們針對功能核心（functional core）的準備工作差不多到此。在今天這一篇，我打算從另一個方向來進行準備。這些事項通常被認為只是一個計劃的「邊緣」（periphery），或者用不那麼哲學的說法，叫做「支援／支持性結構」（supportive structure）。然而我們可以從任何一個初具規模的open source計劃中發現，這些「邊緣」與「支援／支持性結構」的重要性，絕不亞於功能核心。

好的，那麼今天的準備工作，將包括有：

• 在OpenFoundry上開設一個計劃
• 利用OpenFoundry所提供的原始碼倉庫（source repository），將我們目前為止準備的材料送進去（commit）。
• 為我們的計劃選一套open source的授權條款。

準備好了？我們開始。

為程式碼找一個家

剛開始的時候，一切都很單純：你把程式碼編好，把東西包裝起來，上傳到自己的homepage所在地，修改index.html（或其他網頁檔案），然後昭告親友，你寫了一套新軟體。

然而軟體會長大，計劃也會成長。你可能開始想找人參與，或是有人主動想開發新的功能。你開始有共同工作（collaboration）的需要。另一方面，你也可能開始有各種不同的版本要發布。你想要使用subversion一類的工具來管理程式碼，可是又不想或無法自己架subversion在server端所需的各種工具。然後你還需要有bug tracker、mailing list，你發現你開始分心去做這些「務虛」但必要的管理工作……

許多龐大的open source計劃，因為資源較為足夠，得以發展出一套完整的分工體系，讓其中一部份參與者擔負各種管理及「顧家」（housekeeping）的工作。這些大型計劃像是自給自足或自成體系的大企業。然而我們只是個剛開始的計劃，我們不可能花費這些心神來處理這些「顧家」的工作。

像SourceForge、OpenFoundry一類的服務，所幫你分擔的，就是這種「安家」（hosting）的憂愁。它們為你的計劃提供一個家、一個發布的空間、一套具有版本管理功能的原始碼倉庫，並提供一些基本的計劃管理工具，供你的計劃公開給世人使用。

可以說SourceForge、OpenFoundry是一種公共服務，我們可以把各種顧家、安家的工作「外包」出去，利用它們來節省我們的管理時間。

到OpenFoundry上開一個計劃

在這個時點上選擇OpenFoundry的理由，不外是它有中文介面，又不像SourceForge那麼複雜。

要在OpenFoundry上開一個新計劃的方法很簡單。首先，你要先成為註冊使用者，然後就可以開設新計劃。

我們在計劃資料上填上以下的內容：

• 計劃名稱：地理資訊輸入法
• 計劃的id：ovgeoinfo （我們將來以此名稱來存取原始碼倉庫）
• 版本管理工作：使用預設的 subversion

然後，在選擇授權的時候，我們使用 BSD License ，文件的授權則使用Creative Commons的Attribution-NonCommercial-NoDerivs。

稍後我會說明（在此時點）做這個選擇的理由。

將原始碼送進原始碼倉庫中

嗯，到此為止，我已經用了兩個我實在用不慣的中文詞，幾乎快到爆炸的程度。以後我會只講check in、check out跟source repository（簡稱repo）。

在OpenFoundry上把計劃開設好後，我們就可以透過這個URL來存取和計劃相關的資訊。同時，OpenFoundry也會幫我們設定好計劃要用的subversion repo：http://svn.openfoundry.org/ovgeoinfo

接著，我們利用subversion這套工具，把先前寫的Perl煮XML工具，以及範例的資料檔，check in（或說commit）進入我們的repo中。

使用subversion

Subversion屬於UNIX「一脈相承」的的版本管理系統，它的使用方式和命令語法都承襲自CVS，而CVS又是承襲自RCS。目前Subversion的中文文件，最重要的，當然要屬plasmaball翻譯的手冊全文。不過，subversion雖然功能強大複雜，對於我們來說，日常的工作，其實只有以下四種：

1. 用svn checkout指令取得原始碼
2. 用svn update指令將放在我們自家硬碟裡的拷貝，更新到最新版本
3. 用svn commit指令將我們做過的修改，送進repo裡
4. 用svn log瞭解最近的更動記錄
5. 萬一在svn update時遇到衝突，做衝突的修正

其實 (1.) 只有第一次工作時會需要用到。一般對只需要取得程式碼、或僅有唯讀（read-only）權限的人，也只會用到 (2.) 和 (3.)，只有真正在修改程式的人會需要碰到 (4.) 和 (5.) ，而且 (5.) 的情況不多見。

將repo目錄checkout到自己硬碟上

Ok, 我們可以把repo給checkout出來了：

svn co http://svn.openfoundry.org/ovgeoinfo

事實上，當你看到這篇文章的時候，我已經把上一篇文章提到的幾份東西，都一一送了進去，除此之外還有很多別的東西。為了說明方便，我想先「還原現場」，向你說明我在第一次checkin時，到底送進去了哪些東西。

我送進去了哪些東西

如果你觀察一下 checkout 出的 ovgeoinfo/ 目錄，你會發現如下的結構：

ovgeoinfo/
  trunk/
    License/
    Mk/
    Module/
        OVGeoInfo/
    SharedHeaders/

之所以會有這樣的安排有有原因的。

許多subversion的使用者承襲了CVS的習慣，把repo最頂層區分為以下兩種目錄：

• trunk/: 字面意思是「樹幹」，意思是程式碼的主支幹，也就是現行的最新版本（latest version）
• branches/: 意思是「支幹」，也就是程式碼的分支。

事實上，許多計劃承繼自CVS的習慣，還有一個名叫 tags/ 的目錄，用來標示各種已經推出的版本。但是由於 subversion 不再依靠這種方式，有一些計劃（例如 OpenVanilla）把各固定的版本放在 releases/ 目錄中。

這些習慣雖然在計劃初期看不出好處，儼然只是增加麻煩，但是隨著計劃成長，這些過去open source計劃所慢慢累積出來的經驗法則，就會顯露出其效用。

放在 trunk/ 裡的東西

至於，trunk/ 裡的四個目錄，功能是這樣的：

• License/: 這是屬於服務性質的目錄，主要將放進我們的 BSD License 全文。
• Mk/: 這是 OpenVanilla 模組共用的 Makefile
• Module/: OpenVanilla 的模組會放在這個目錄裡，裡面的 OVGeoInfo/ 是我們真正要開發的模組。
• SharedHeaders/: OpenVanilla 的一些供模組使用的程式庫標頭檔。我們在此將只用到 OVSQLite3.h 這個 sqlite3 程式庫的包裝紙（wrapper）。

OpenVanilla 之所以會這樣安排目錄結構，當然也是有原因的，我們會慢慢解釋。至於為何目錄名一反 UNIX 的慣例，首字都是以大寫開頭？那是因為 OpenVanilla 受到了 Mac OS X 的目錄命名習慣影響所致。

我們可以從命名看出一個計劃的文化背景。:)

然後，我們把上一篇文章所提到的內容，都放到了 OVGeoInfo/ 這個目錄中了。

選擇 BSD 授權

大抵說來 free/open source 軟體的授權只有兩種：GPL 系的跟 BSD 系的。我選擇所謂的「三條文式BSD授權條款」有以下幾個理由：

• 它很短
• 比較起來算是好懂
• 它的限制少
• 我翻譯了一個中文版本

當然，這兩種軟體授權代表了兩種哲學差異，在此無法一一細述。

我們 reuse 了一下 OpenVanilla 的 trunk/License/ 目錄裡的授權條款文字，將之放進了地理資訊輸入法的 trunk/License 中

到此…

到此，我們完成了這些「邊緣」或「支持性結構」的準備工作了。我們可以試一下先前提過的煮XML的程式碼：

cd ovgeoinfo/trunk/Modules
./gendb.pl example.xml

你也可以用svn log指令閱讀最近的修訂記錄，了解這個實驗的最新進度。

lukhnos :: Jul.01.2006 :: tekhnologia 技術或者藝術 :: 1 Comment »