2007年5月10日 星期四

SVK與嵌入式系統開發

為什麼我們考慮要採用Linux與一系列自由軟體?姑且不論軟體品質,保持更新與強大的QA就是其中關鍵因素,但就個人的經驗來說,過去看到太多公司僅知曉自由軟體的「自由下載與使用」,卻不清楚其體用或本質,於是,仍以過去封閉的方式開發,也就是說,只是把自由軟體當作書本的「範例程式」,當然,這樣的確可行,但在這個 "Programming 2.0" 的新紀元,我們有必要改變思維。

首先,所謂「流水不腐」,這就是自由軟體的精神其中一個面向,蓬勃發展的計畫如Linux kernel,隨時都引入新的技術與硬體支援,我們當然該緊密跟上這些脈動,但開發產品不是兒戲,往往得先挑選一個堪用的軟硬體設計,然後依據功能需求,進行調整與改寫,這是我們相當清楚的。但過去的問題就是,這樣的軟體設計往往無法再銜接到日新月異的社群發展,也就難以跟新的開發版本銜接,於是乎,我們得認真的思考分散式版本控制系統 (Distributed Version Control System),對過去集中式的系統做了反撲。在多方的評估與實驗下,我們的建議是採用SVK,大幅降低許多嵌入式系統開發的維護難度。

2004年在Asia BSD Conference就聽過clkao (高嘉良) 前輩介紹SVK,也在一些專案用過,不過後來都不了了之,總是卡在技術問題上。今年二月份為了維護 PXA27x Linux計畫,又使用了SVK。在之前的blog "Qemu patches" 可看到系統模擬所做了修改,但事實上那還是一部分,更別考慮到qemu的活躍發展所導致頻繁的API changes,還好,我們有SVK

參考 "Using SVK As A Repository Mirroring System" 一文提供了簡要的SVK用法,可輕鬆的維護發展分支,PXA27x Linux計畫的子項目PXAemu就是以qemu為基礎的設計,要保持跟upstream (Qemu官方) 同步發展,可以很簡單,以下是運作的輸出畫面:

jserv@work:~/virt/pxaemu$ svk pull
svk: $ cvs login # for 'anonymous'
CVS password:
svk: $ cvs ... checkout qemu # establish local CVS workspace
svk: appending required ChangeSets, StringEdit filters
svk: running cvs log qemu
svk: found 587 rev(s) with 1073 tag applications
svk: no revisions to write
svk: sorting by change_id
svk: committed 0 revisions
自動合併(2812, 2814)/mirrors/qemu/trunk 到 /projects/pxaemu(源頭為 /mirrors/qemu/trunk:2812)
U target-sparc/op.c
U target-sparc/cpu.h
U target-sparc/translate.c
新的合併歷史紀錄:b2c12b54-451a-302e-ae34-065fcc141066:qemu/.../trunk:2814
已送交編號 2815 的更動。
同步化 //projects/pxaemu(/projects/pxaemu)於 /home/jserv/virt/pxaemu 到第 2815 版。
target-sparc - 略過
target-sparc/op.c - 略過
target-sparc/cpu.h - 略過
target-sparc/translate.c - 略過
在 Debian 中需要安裝兩個套件:svklibvcp-dest-svk-perl。如上所示,這就是智慧型的 merge,因為PXAemu本身已移除ARM以外的target,所以即便upstream的qemu有其他架構的更新,也會自動忽略。如此一來,建立特定需求的版本分支可以相當輕鬆,卻可擁有強大的離線版本控制能力,對於許多Embedded Linux專案來說,其Know-How其實就是「如何基於原本的原始程式碼,針對需求去調整」,那麼,我們就可以善用SVK,當然,上面只展示一部分特性,事實上,在SVK 2.0又提出一堆強大的功能。

最近我也利用SVK來管理Build system,我們都知道OpenEmbedded有豐富的支援,但入門不容易,又常常無法順利建構套件或系統,OpenedHand則建立Poky這個特製的系統,試圖去降低OpenEmbedded的難度,於是,我有個簡單的想法:
「能否把原本依賴OpenEmbedded的OpenMoko建構系統,改成Poky為基礎的形式?」
想法很單純,但實現有很大的難度,這相當跨越了OpenEmbedded、Poky,以及OpenMoko這三個repository。過去我們往往得訴諸大量人工介入,但有了SVK,一切都改觀了,以下是操作畫面:
~/openmoko-builder$ svk mirror --list
Path Source
============================================================
//mirror/openmoko http://svn.openmoko.org/trunk
//mirror/poky http://svn.o-hand.com/repos/poky/trunk
~/openmoko-builder$ svk pull
Syncing http://svn.o-hand.com/repos/poky/trunk
Auto-merging (3059, 3149) /mirror/poky to /project/openmoko-builder (base /mirror/poky:3059).
U meta/conf/distro/include/preferred-xorg-versions.inc
meta/conf/distro/poky.conf - skipped
U meta/classes/cpan.bbclass
U meta/packages/avahi/avahi_0.6.15.bb
...
A meta/packages/xorg-xserver/xserver-kdrive-common.inc
meta/packages/mozilla - skipped
meta/packages/mozilla/minimo_0.016+cvs.bb - skipped
New merge ticket: 311d38ba-8fff-0310-9ca6-ca027cbcb966:/trunk:1691
Committed revision 3151.
Syncing //mirror/openmoko in /home1/jserv/openmoko-builder to 3151.
U meta/conf/distro/include/preferred-xorg-versions.inc
U meta/classes/cpan.bbclass
...
上述的動作,僅有svk pull,就輕易的把Poky與OpenMoko的SVN repository的更動「拉」下來,並自動與本地端 (openmoko-builder) 整合進去,不再有無謂的人為介入,當然,最重要的是開發者與功能需求,但良好的工具讓工作變得輕鬆,也得以專注於處理問題本身。

未來如果有機會,或許也可以分享這方面的經驗,並導入既有的系統開發中。

2 則留言:

vinx 提到...

我以前用cvs后来改用svn,还从来没有考虑过离线的版本管理软件,不知道svk是否也可以离线管理cvs库以及保持一个cvs库和一个svn库的同步?

jserv 提到...

svk 就是離線的 distributed version control system,所以您說的要求,可以很容易達到。