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 中需要安裝兩個套件：svk與libvcp-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) 整合進去，不再有無謂的人為介入，當然，最重要的是開發者與功能需求，但良好的工具讓工作變得輕鬆，也得以專注於處理問題本身。

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