上一篇文章裡提到,我們想開發一個「(以任何現有輸入法)打完地名,輸出與地名相關之地理資訊」的新「輸入法」──或者是「超輸入法」(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雖然功能強大複雜,對於我們來說,日常的工作,其實只有以下四種:
- 用svn checkout指令取得原始碼
- 用svn update指令將放在我們自家硬碟裡的拷貝,更新到最新版本
- 用svn commit指令將我們做過的修改,送進repo裡
- 用svn log瞭解最近的更動記錄
- 萬一在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 »