剛用 C# 寫了一個 Subversion pre-commit hook，這個小工具能夠在開發人員執行 Subversion 送交命令時檢查是否有輸入送交說明（log message），如果沒輸入的話，就告訴 Subversion server 停止 commit 動作，並傳回錯誤訊息給用戶端，例如：

目前 Subversion 官網上面列了三種不同口味的 server 打包版本：

• CollabNet
• Tigris
• VisualSVN

以往我一直是用 CollabNet 打包的版本，這個版本（我用的是 v1.5）有個小缺點：若要使用 Windows 帳戶驗證，還得自己手動調整一些設定（參考這篇：Subversion 從 1.4.x 升級到 1.5 的注意事項）。

近日手癢，試了一下 VisualSVN v1.7。安裝方法非常簡單，幾乎都是按「下一步」就裝完了。在安裝過程中會讓你指定身分驗證機制要採用 Windows 帳戶驗證還是 VisualSVN 本身維護的帳戶，以及要用 HTTP 還是 HTTPS 協定。參考以下畫面：


不用三分鐘就裝完了，裝完之後不需要手動編輯組態檔，也不用其他額外設定，一台 Subversion 伺服器就能開始運作了。連我原本使用 CollabNet Subversion server 建立的檔案庫，也都是直接複製到 VisualSVN 的檔案庫目錄下就能直接使用。不過，我原本的檔案庫就是用 VisualSVN 預設支援的 FSFS 格式，若檔案庫是之前的 BDB 格式，我就不確定能否直接掛上了。

VisualSVN 安裝完後，Windows 系統會多出一項服務：VisualSVN Server，如下圖所示：

此外，程式集裡面還有一個管理工具：VisualSVN Server Manager。你可以利用此工具修改 Subversion server 的相關設定，例如身分驗證方式、傳輸協定、檔案庫所在路徑等等；也可以管理你的檔案庫，包括：檢視檔案庫、設定檔案庫存取權限（No Access、Read Only、Read/Write），甚至編輯 hooks。

缺點

雖然 VisualSVN 有著安裝簡單、對 Windows 帳戶驗證的支援較強（Active Driectory 帳戶也支援）、提供視覺化管理工具等優點，但也有些缺點（這裡指的是 v1.7 的版本），例如：

1. 不支援 svn:// 協定（svnserve）
2. 預設的檔案庫目錄底下不能再建立子目錄

第二項缺點需要解釋一下。以往使用 CollabNET Subversion server 時，我可以在檔案庫路徑底下建一些子目錄來區分不同類型的專案，比如說，檔案庫位置在 D:\SvnRepos，我可能會在此目錄下另外建立三個子目錄：Books、Projects、Thesis，然後在這些目錄底下建立真正的 subversion 檔案庫。如此一來，檔案庫的 URL 會類似這樣：http://localhost/svn/Books/ooad。這種方式的好處是可以讓我依自己的習慣組織檔案庫所在目錄的樹狀結構。

可是 VisualSVN 預設不支援這樣的目錄配置。以剛才的例子來說，若嘗試 svn checkout http://localhost/svn/Books/ooad，結果會無法取出檔案。解決辦法是在 Apache 的組態檔中增加一個 URI 位置的設定，像這樣：

<Location /svn/Books/>
DAV svn

SVNListParentPath on
SVNParentPath "D:/SvnRepos/Books"
SVNIndexXSLT "/svnindex.xsl"

AuthName "Subversion Repositories"
AuthType Basic
AuthBasicProvider visualsvn
AuthzVisualSVNAccessFile "D:/SvnRepos/authz-windows"
AuthnVisualSVNUPN Off

require valid-user
</Location>

組態檔位於 Program Files\VisualSVN Server\conf\，此目錄底下有兩個組態檔，一個是預設的 httpd.conf，另一個是 httpd-custom.conf。從檔名可以看出，我們只要把自訂組態寫在 httpd-custom.conf 就行了，這樣就不用去動預設的組態檔。附帶一提，你不見得一定要用 SVNParentPath 來指定檔案庫路徑，還有一種方法是設定 SVNPath（適用於檔案庫散置各處，不在同一個父資料夾路徑下的情況）。

奇怪的是，CollabNet 和 VisualSVN 都是用 Apache HTTP Server，同樣的 SVNParentPath 設定卻有不同的作用，不知是否為二者採用之 Apache 版本不同所致，或者我漏掉了某個設定？

有位未具名的朋友在《物件導向分析設計與應用》書籍相關資訊的回應中問到：「還有什麼樣的書，類似這本，把關於IT設計的概念、方法、目的、應用等，都整理出來的好書。」在回覆時，寫著寫著覺得內容有點長了，於是拉出來自成一篇。

我第一個想到的是四人幫的《Design Patterns》。雖然手邊還有其他討論軟體設計的書籍，但每次我有設計方面的疑問時，都會先從這本書下手。名副其實的經典！這本書有中文版：《物件導向設計模式》，葉秉哲翻譯。書中的範例是以 C++ 撰寫，也許有些人會覺得不夠親切吧。

其他討論 design patterns 的書籍，我手邊有而且覺得不錯的：

• 深入淺出設計模式（Head First Design Patterns），蔡學鏞 譯。
  無責評論：透過輕鬆詼諧的對話和圖片帶領讀者進入 design patterns 的世界，應該挺適合初學者。
  
• 敏捷軟體開發－原則、樣式及實務（Agile Software Development），林昆穎、吳京子 譯。
  無責評論：Agile + Design Patterns + Case Study，我主要是看裡面的 OCP、DIP、ISP 等設計原則。
  

以上這些書籍所介紹的 design patterns，大都屬於比較通用的、一般目的的 patterns。另外還有一些書籍是針對特定問題領域或架構方面的 patterns，像是：

• Patterns of Enterprise Application Architecture
• Pattern-Oriented Software Architecture Volume 1: A System of Patterns
• Pattern-Oriented Software Architecture Volume 2: Patterns for Concurrent and Networked Objects
• Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management

這幾本書我自己並沒有全看過，只能說稍微瞄過一些。PoEAA 的作者是 Martin Fowler，其中收錄了許多企業級應用程式經常用到的 patterns。之所以列出 POSA 這三冊，是有一次我在隨便翻看時，才發現原來自己寫的一套軟體中用來解決某個複雜問題的方法，就是 POSA Volumn 1 中介紹的 Blackboard pattern；此外，《物件導向分析設計與應用》也有一個 case study 用到此模式。Volumn 2、3 的 patterns 可能就稍嫌冷門了些。

目前大概先想到這幾本，若有想到其他值得推薦的書籍再補上來。

BugTracker.NET 除了安裝簡單，也有考慮到一些客製化的需求。例如，web.config 裡面有下列參數：

<add key="AppTitle" value="BugTracker.NET"/>
<add key="SingularBugLabel" value="bug"/>
<add key="PluralBugLabel" value="bugs"/>

AppTitle 是顯示於瀏覽器視窗標題的文字，SingularBugLabel 和 PluralBugLabel 則可以讓你用別的名稱取代 bug/bugs。如果覺得 bug 這個名詞太侷限，或太敏感，我們可以改用其他名稱，像這樣：

<add key="AppTitle" value="問題管理系統"/>
<add key="SingularBugLabel" value="issue"/>
<add key="PluralBugLabel" value="issues"/>

注意如果有用到中文字，在顯示時可能會變成亂碼，因此得將 web.config 改以 UTF-8 編碼的格式儲存。結果如下圖：

其他可客製化的頁面都放在 custom 目錄下，你可以藉由修改 custom_logo.html 把左上角的 Logo 換掉，或者修改 custom_header.html，以便在每頁的上方顯示公司或單位名稱，例如：

同樣地，這些檔案也都要存成 UTF-8 編碼，否則網頁無法正確顯示中文字。此外，上述修改動作都必須重啟 IIS 才會生效。

除了頁面文字的客製化，BugTracker.NET 還提供了 custom fields，讓你可以增加問題登錄頁面的輸入欄位。在 3.1.6 版，每個專案最多可有三個自訂欄位，而且都是下拉清單（drop-down list），如果這三個下拉清單欄位仍不夠用，還可以增加全域的自訂欄位。參考下面這張登錄新問題的畫面截圖：

圖中的「預定完成日」是全域自訂欄位，「子系統」則為該專案 'project 1' 的自訂欄位（若選擇其他專案，則不會出現此欄位）。在建立全域自訂欄位時，可指定輸入方式是否為下拉清單，並可指定資料型態；如果資料型態是 datetime，還有日曆元件可用。

有個小地方可能要注意一下：管理員可以隨時刪除全域自訂欄位。也就是說，如果你已經有登錄 issues，後來又把某個自訂欄位刪除，那麼之前登錄的 issues 資料就不會有那個自訂欄位了。實際上，在建立全域自訂欄位時，程式會真的在資料表 bugs 中動態建立新欄位，而刪除全域自訂欄位時，也會真的刪除實體欄位。至於專案的自訂欄位，則只是預先在資料表中預留三個欄位而已。

跟 BugNET 比起來，BugTracker.NET 的程式寫法顯得「樸實」許多，因為它主要是以 .aspx 和 html 構成，完全沒有 code-behind 類別，但整個設計給我的感覺是非常簡單、易用，也很彈性，有需要架設問題管理系統的人不妨試試。

相關文章：BugTracker.NET 簡介

本文介紹 Subversion 版本控制系統的基礎觀念和術語，以及導入版本控制系統時應考慮的事項。

P.S. 這篇文章原本寫於 2004 年 6 月，之前將部落格搬到 blogger.com 時沒有整理進來，現在補上，順便重新編排、修剪。

延續上一篇測試報告，這次測試的作業平台是 Windows Vista 繁體中文版，已內建微軟新注音 10.0。結果出乎意料，ImeLib 的範例程式竟無法取得注音和拼音字根，只有日文平假名／片假名的功能可正常運作。用 RegEdit 搜尋關鍵字 MSIME，只能找到 MSIME.Japan 的註冊資訊。
這情形跟我在測試 Windows Server 2008 的情況一樣，但這次的解決方法並不是安裝 Office 2007 。

這裡記錄一下自己測試 ImeLib v0.1 的結果，並簡單比較 IFELanguage 與 IMM32.dll。

剛剛把這兩天寫的一個取注音字根的元件放到 CodePlex 上面，取名為 ImeLib，以 LGPL 授權方式發布，附完整 C# 原始碼和一個範例程式。目前的版本是 0.1，還缺很多東西，但基本上我自己需要的部份（取得中文注音字根）已經大致完成且測試 OK。以下是範例程式的畫面：