Friday, August 7, 2009

從 Ditz 談針對分散式版本控制的 Issue Tracker

從 Ditz 談針對分散式版本控制的 Issue Tracker兩年多前提過的 [Trac 整合性開發環境],現在已在許多實驗室、公司專案開發等地見到廣泛的使用,原因無他,一套系統可涵蓋 Wiki + issue tracking + SVN 的整合,安裝與操作都很簡單,又有許多 plugin 可用,自然會流行。包含我在內,不少人將 [trac] 也裝於自己的電腦 (laptop) 中,搭配 svk 一類的分散式版本控制系統,就可隨時隨地追蹤專案進度 (internal / external)、作基本的個人知識管理 (KM),或者查核待作事項等等。那為何又要接觸 [Ditz] 這套 issue tracker 呢?

使用一個工具前,若缺乏必要的背景知識,那也是枉然,所以先來反思分散式版本控制系統。trac 背後端採用 Subversion,雖較 CVS 有著巨大的進步,不過本質上還是集中式管理的版本控制系統。正如之前文章 [SVK 與嵌入式系統開發] 與 [在 Linux kernel 外應用 GIT,兼談分散式版本控制系統] 所提及,現在開發的模式在無形中已經逐漸轉變,最顯著的領域大概是伺服器應用端與嵌入式系統開發,我們常見到過去都是研發人員封閉開發的環境,在自由軟體蓬勃發展的影響,竟以「追趕上游自由軟體發展」為重要指導原則,這裡的「上游」就是 "upstream" 一詞,也就是說源頭的自由軟體專案,比方說 Linux Kernel, MySQL, GNU Toolchain 等等,正如稍早提過的概念:

蓬勃發展的計畫如 Linux kernel,隨時都引入新的技術與硬體支援,我們當然該緊密跟上這些脈動,但開發產品不是兒戲,往往得先挑選一個堪用的軟硬體設計,然後依據功能需求,進行調整與改寫,這是我們相當清楚的。但過去的問題就是,這樣的軟體設計往往無法再銜接到日新月異的社群發展,也就難以跟新的開發版本銜接,於是乎,我們得認真的思考分散式版本控制系統 (Distributed Version Control System),對過去集中式的系統做了反撲。 儘管我們有 [git], [[url= mercurial=]mercurial[/url]], [Bazaar] 等一系列發展活躍且強大的分散式版本控制工具,但我們如今面臨新的考驗:本質上的差異,使得 issue tracking 也需改變想法。過去我們建立開發分支 (branch) 往往是基於某種特徵或實驗性設計,由一組人馬以現有的 codebase 為基礎,設立一個獨立的環境,日後有需要則可合併 (merge) 回去,而開發標籤 (tag) 則是標注某些特定的版本,作細部的調整或客製化等等,但在分散式版本控制系統的概念中,建立分支是理所當然的事情,基本上,任何人在自己的電腦取得一份副本 (clone) 時,就是一個「分支」了,隨時可從 upstream 取得、參照修改、進行本地端修改合併等操作。設計層面來看,這類分散式版本控制系統都伴隨一套數學上不會重複的 hash,讓個別修改得以追蹤,以前要解釋這個概念實在不容易,但還好有了火紅的 "Web 2.0" 名詞後,就可把 CVS/Subversion 一類看作如同 "Web 1.0" 那樣持續性、單調性、集中的開發模式,而 git 一類則如同 "Web 2.0" 般,允許全球各地的開發者共同追蹤管理專案,是分散性、社群導向的模式,所以,有人就說:

"It's real strength is that Git is a social source control system." 於是,剛剛提到的 hash,或者說 "changeset",在概念上就有了全新的意義,因為變異性提高了,不能以過去集中的開發模式來思考,如此一來,衝擊在哪?是的,就在 issue tracking。過去 issue tracking 會綁定某個 milestone,細部則是若干 changeset 或 revision number (如 Subversion),但,這對 git 一類的分散式版本控制系統來說,意義不是很大,畢竟我們現在操作的對象是「整個 tree」,也就是專案從開始進行到現在的歷程,首先在尺度上就有落差。無論工具提供哪些操作,基本上我們只要懂 "pull", "push", "merge" 等動作的對應即可,貌似過去的 Subversion 這類 "VCS 1.0" (VCS 乃是 "Version Control System" 的縮寫) 都可做到,那麼考量到 git 一類 "VCS 2.0" 又有何影響呢?重點就是分散式開發所引來的不確定性、社群模式,很可能前一次合併 (pull + merge) 還是順利運作的系統,下次就連編譯都會失敗了,這樣,更別談什麼軟體品質控管,所以這是一種「混沌」(choas) 嗎?某個角度來說是,但其背後的蜜糖才是吸引我們的地方:

「自由軟體是活的,生生不息的演化」 只要適度操作,我們可在自己的 git tree 中創造獨有的變化或新功能設計,在保有完整開發歷程的狀態下,合併任何重大的合理變更,假以時日,還可 "push" 到 upstream,並透過開發社群作合理的 merge。所以,在這個模式下,我們思考的是「一整個 tree」,其中的細節則是若干 hash/chageset 如何「變遷」,這也是核心的議題。當然,回頭看 issue tracking,還是能訂定 milestone,但落實面就要改變手法。換言之,我們需要把過去單一維度的 issue tracking 觀念捨棄,現在這些 issue 是會跟著 "tree" 變動 / 移動的,在分散式版本控制系統的維度來說,瞬間就提高許多,尤其越大的專案越顯著。[Ditz] 的提出,就是試圖針對這個本質的落差,實做出專門打造的 issue tracker,以下是官方網頁的簡介:

Ditz is a simple, light-weight distributed issue tracker designed to work with distributed version control systems like darcs and git. Ditz maintains an issue database file on disk, written in a line-based and human-editable format. This file is kept under version control, alongside project code. Changes in issue state is handled by version control like code change: included as part of a commit, merged with changes from other developers, conflict-resolved in the standard manner, etc. 現在的發展仍很陽春,但概念上就是將「分散式」、「社群開發模式」的本質予以彰顯,目前是命令列方式來操作,初期已有的 "proof-of-concept" 呈現如下圖:





除了命令列外,Ditz 還支援 HTML 輸出,示範的網站可參考 [ditz Issue Tracker]。

可想見,未來版本控制系統與專案開發走向更全面的分散式之後,issue tracking 會是相當重要的考量。試想,upstream 原本就有若干 "tree",彼此對 changeset 做了高度的互動,而在我們自己的 "tree" 也有特定的變動,這樣一來,「此 issue 非彼 issue」則是稀疏平常的事情,甚至我們難以用單一版本數字來界定 issue 的「起源」,特別是考量到發展 "tree" 之間的「繼承」或「移轉」特性,這個議題越加複雜,Ditz 是個出發點,有太多值得思量之處。

由 jserv 發表於 April 10, 2008 01:49 AM

迴響

分布式的scm还处于战国阶段。。。

一般小团队或企业应用,还是可以选择svn

在适当的时机,可以尝试git或者你介绍的这个。由 Fwolf 發表於 April 10, 2008 06:15 PM

老大你防垃圾评论的机制真是又搞又高!由 Fwolf 發表於 April 10, 2008 06:16 PM

「此 issue 非彼 issue」的問題真的很麻煩,我們公司現在使用Bazaar作版本控制,Trac為Issue Tracker,本來用hash code來追蹤是最為準確的方法,但太長太難記,所以還是用回版本號碼。

但Bazaar的版本號碼會隨merge的方法不同而改變,有同事的方法不妥當,令某計劃的rev70到90被改寫了,當中沒有什麼重要的issue,所以問題不大,只是我要花很長的時間去解釋到底發生了什麼事,及應該怎樣去解決……

Ben Lau 發表於 April 10, 2008 08:40 PM

為了更方便地使用Ditz,我寫了一個叫做Ditz Commander的圖像介面程式,讓修改issue等工作可以以更簡單的方法達成:

http://benlaux.blogspot.com/2008/10/ditz-commander.html由 Ben Lau 發表於 January 1, 2009 06:05 PM

No comments: