本系列目前有四篇文章，建議依照以下順序閱讀：
wcfind - avoid find(1) into subversion meta directories
use grep(1) accompany with my wcfind via xargs(1)
Setting svn:keywords in many files simultaneously
再探 wcfind — 用 find2perl 實作
由於 CVS、Subversion 這類的 version control systems，通常會在 working copy 目錄下，建立如 CVS/、.svn/ 的 meta directories，使得一些 command-line 工具會水土不服。例如，grep 會連 .svn/ 目錄下的檔案都去尋找，不僅拖慢速度，更讓結果雜亂，難以使用。因此，很久以前，我參照了 Ben Reser 的作法，弄了一個 wcfind 給自己用。
可是，之前的 wcfind 是使用 Bourne Shell 實作，並依賴於 FreeBSD 下的 find [...]
很久以前就想要好好地重整一下我的 blog 了，剛好趁著搬家重灌系統的機會，好好地整理一番。那時的目標有
真正的版本控制
資料庫瘦身
升級後台編輯用的 FCKeditor
與 Sidebar Widget 相容
IE 下的畫面極為慘烈
其中，「升級後台編輯用的 FCKeditor」已經在《Wordpress 編輯器升級到 FCKeditor 2.5.x》時搞定，theme 的問題暫時先不解決，所以剩下「真正的版本控制」與「資料庫瘦身」兩個目標。
真正的版本控制
以前的作法是，用 Subversion 管理我的 Wordpress 目錄，不過只是簡單的直接 checkout 出 Wordpress 程式。雖然升級或更換版本很方便，svn update 或 svn switch 一下即可，不過自己在 local 端，因應自己的喜好而做的更改，就沒辦法有好的版本控制機制，加以管理了。
也就是說，我希望在能夠隨時將 Wordpress 主網站的更新同步回來之外，還能夠保有自己因喜好而產生的一些小改變。如果 Wordpress 主程式和我自己的改變，是存放在同一個 subversion repository 裡，那這一切就可以做到。
簡單講就是，如上圖，我希望能夠隨時 incrementally 從 Wordpress 主 subversion repository 將最新的修正，mirror 到自己電腦上的 subversion repository 裡，成為一條 mirror branch。然後，又能夠有自己的一條 local branch，儲存自己的喜好，同時又能夠隨時視需要，將 mirror branch 裡的東西，merge 進我的 local [...]
今天看到的，讚：TracWiki WYSIWYG Editor Plugin。
能夠真正產生 Trac 的 wiki 語法存在資料庫裡，故能完美地與 Trac 協同合作。不像 TinyMce Wiki Plugin 會存入 html，造成相容問題。
經測試，能夠直接從 word 把內容複製貼上，樣式會盡可能地保留[1]。
雖然不甚完美，但毋須苛求了。 ↩
因為我們常要寫 wiki page 以便追蹤專案的進度、列出待辦事項等等，由於在 Trac 裡寫 #1 只會顯示 ticket number，往往我們必須要手動把 ticket summary 加在後面，當 ticket 有所變動時，wiki 與 ticket 兩邊就會不同步，維護起來非常麻煩。所以剛剛練習寫了一個 WikiMacro，取名為 TicketStatus.py，列出 ticket number、summary、status 與 owner，開會時一打開，所有事情一目了然。
WikiMacro 不難寫，不過因為我不太熟 python，所以比較麻煩的地方在於怎樣抓取資料。可能是由於 dynamic language 的特性，很難直接從原始碼追蹤，了解手上可以用的參數，其型別與屬性分別可以輾轉得到哪些資料。不過這對熟悉 python programming 的人，應該不是問題。因為多半有現成的工具，如 ipython 等，幫助我們直接取得、分析、追蹤整個物件結構。
TicketStatus.py 的原始碼如下：
"""
Display status and summaries of specified ticket numbers. Useful for listing
TODOs.
Example:
{{{
[[TicketStatus(#1,#7,#31)]] [...]
剛剛看到這篇《Upcoming Subversion 1.5 Feature: Changelists》，介紹了 Subversion 1.5 新增加的功能：changelist。簡單講，就是可以替 working copy 裡尚未 commit 的 changes，標上 tag (label)，以區分出不同的 groups。
文章的前半段講的我心有戚戚焉，這正是開發生活的寫照啊。為了能夠同時解多個不同的 issues (bugs)，而不會把事情混在一起搞得一團亂，開發者通常可以有兩種作法：
使用多個不同的 working copies，每個 working copy 負責一個 issue，也許都對應到同一個 branch，也許對應到不同的 branch。
使用一個 working copy，但在要解不同的 issue 時，利用 svn switch 切換到不同的 branch。
我通常的作法，是兩者混和，準備個兩、三個 working copies，輪流使用。因為專案太大，光是 checkout 就要好久，再加上執行時會需要一些 intermediate files，因為不會放在 repository 裡，重新產生耗時更久，所以必須得事先備好多個 working copies 使用[1]。可惜因為專案架構還不夠好的關係，runtime 目錄不能共用[2]，所以無法進 repository 的 runtime 目錄下的 intermediate files 的同步問題，就有些麻煩。
可惜的是，這樣的 changelist 還不完全，要扣兩分。
要扣的第一分是，只能以路徑為單位標註 tag [...]
看到這篇《Tree-structured FSFS repositories》真的必須記錄一下。不過還是先前情提要一番，再來記錄重點，與自己的想法好了。
Subversion 的 FSFS 原本是把每個 revision 存成一個檔案，放在同一個目錄下。所以，如文中舉例的 Apache Software Foundation (ASF) 的 repository clone，如果總共有 500k 個 revisions，就會有 500k 個檔案，塞在同一個目錄裡。而即將推出的 Subversion 1.5，會改進 FSFS，將檔案以 1000 為單位，分散在不同的子目錄下。
本篇文章值得記錄的有以下幾點：
"Macro-benchmarks using a clone of the ASF repository (about 500k revisions) showed that the new scheme might be slightly (<1%) slower than the old scheme for reads"
"VFAT exhibits roughly O(N) behaviour, and [...]
由於某些技術上的原因，TortoiseSVN 的效率，其實不是很好。我在處理一些大 project 的時候，常常會有整台機器 hang 住的情況，直到把 TSVNCache.exe 砍掉後才能恢復。所以 TortoiseSVN 的主要開發者 Stefan Kueng 最近就發表了一篇文章叫《Optimize performance》，教大家如何調校，以增進 TortoiseSVN 的運作效率。
不過，原文標題是「增進效率」，但我實在是要換個方法來講，因為這些調校，其實是在「避免系統效率被 TortoiseSVN 拖累」啊！
以下用我自己的話，簡單介紹怎樣不被 TortoiseSVN 拖累：
不要把你的 working copy，放在網路磁碟機裡。TortoiseSVN 常要作一些複雜的事，好比說 recursive 進去每個子目錄，檢查是否有檔案被更動過，以便顯示 icon overlay。網路磁碟機的運作速度本來就很慢了，如果這些複雜的事，必須在網路磁碟機上做，當然效率就更差了。這第一條建議，就把我打死在路邊，因為我總是為了貪圖 unix tool 的方便，而使用 samba 分享 working copy 到 windows 上使用，也因此，所以常會碰到這些效率的問題。解決之道當然就是不要這麼作，幸好最近發現 GnuWin32 比起以前的 UnxTools 要來的齊全很多，現在大部分的 unix style 操作，也都可以在 Windows 上進行了。
減少 working copy 的量。TortoiseSVN 會監控「所有」被 checkout 出來的 working copy，偵測其是否有所更動，以便存於 cache [...]
首先先介紹一下 Subversion 是什麼 (節錄自《Subversion Book 中譯版》)：
Subversion 是一個自由/開放源碼的版本控制系統，也就是說 Subversion 管理著隨時間改變的檔案。這些檔案放置在一個中央檔案庫 (repository) 中。這個檔案庫很像一個尋常的檔案伺服器，不過它會記住每一次檔案的變動。這樣你就可以把檔案回復到舊的版本，或是瀏覽檔案的變動歷程。許多人會把版本控制系統想像成某種「時光機器」。
某些版本控制系統也是 Software Configuration Management (SCM) 系統。這些系統是特別設計來管理大量程式碼的，而且具有許多功能，專門用在軟體發展之用：像是可完全了解程式語言，或是提供編譯軟體的工作。不過 Subversion 並不是這樣的系統；它是一個泛用系統，可用來管理任何類型的檔案，其中包括了程式源碼。
一般我們會簡稱 Subversion 為 SVN，簡單講，如果您用過 CVS 或 Visual SourceSafe 的話，SVN 就是那樣的一個東西，而且功能更為強大，設計更為合理，使用更為簡便。就我個人的看法是，SVN 再搭配另外幾個 open source 的軟體，其功能就可以比得上百萬等級的 SCM 軟體；當然，前提是我們有時間搞懂它。
所以，為了節省大家的時間，也為了節省我自己的時間[1]，以下整理 SVN 的相關資源。
Subversion 與相關工具之官方網站
Subversion 官方網站：http://subversion.tigris.org/
官方網站 hosting 在由 CollabNet 架設的 tigris.org，CollabNet 提供了 Karl Fogel 全職的工作，專職發展 CVS 的替代程式：Subversion。
Subversion Book (英)：http://svnbook.red-bean.com/
最新、最完整、最標準的 Subversion 參考文件。
Subversion Book (中)：http://svn.stu.edu.tw/svnbook/
由 Plasma [...]
Eclipse 已經是個非常成功的 open source 軟體開發平台，其涵蓋的範圍，不僅包括了 Java development，亦在 embedded development[1] 開花結果，成為許多 platform 的預設開發環境。作為一個完整的開發平台，在這樣子的成功之下，隨之而來的，便是 team development 的需求，尤其是與最近鋒頭最健的 Subversion 整合，更是擁有超過 100 votes，名列 top 5 的 feature request。因此，SVN Team Provider 這個 project，便出現了，目前處於 proposal / gathering community 的階段。
在以往，我們若要在 Eclipse 裡使用 Subversion，通常需要安裝 Subclipse 這個 plug-in。Subclipse 解決了在 Eclipse 連結 Subversion native libraries 的技術問題，不過，其與 Eclipse 的整合程度，只能算是初級，人心總是不足的，總是希冀能有更強大、更徹底的整合。因此，SoftLanding Systems、CollabNet[2]、TMate[3] 以及其他重量人士如 Karl Fogel 等，並結合與 team development [...]
Subversion (SVN) 是一個集中式的版本控制系統，因此，其中一個主要的限制便是，在使用的時候，必須要連上網路，以便與其 server 連結。儘管在架構設計上，SVN 已經盡可能的減少網路頻寬的使用，但在正常運作上，仍然是有許多操作，是必須連結到 server 上進行的。
然而，實際上，在開發的過程當中，並不是能夠無時無刻的連結在網路上。最近我們就遇到了這樣子的一個需求，因應業務需要，我們需要有一組人，南下到客戶的工廠 on site，當場在工廠內改程式。由於環境的因素，在該處無法連結到 Internet，因此也就不可能連回位於公司內的 SVN server。因為程式複雜度的關係，這支遠在南部的特遣隊，有可能需要北部辦公室的支援，方能解決一些程式的問題，因此我們需要一套機制，讓在南部的同事，能夠與台北辦公室，進行程式碼的同步。換言之，我們需要一套機制，能夠 offline 使用 SVN。
也正是為了 offline 開發的需求，clkao 開發了 SVK 這套建基於 SVN 的工具，使開發者可以將 SVN repository 映射 (mirror) 在自己的電腦裡，離線進行開發、commit，事後在得以 online 時，再與主 SVN repository 進行同步。SVK 是套很棒的工具，然而卻還是沒有辦法滿足我們的需求。最主要的問題在於，SVK 是設計給單人使用，而我們外派到南部的，是一整組人馬，且彼此之間，也有程式碼相互同步的需求。換句話說，實際上我們需要的，是要能夠複製一份 SVN repository，並能夠在特定的時候，與主 SVN repository 同步。這樣一來，複製出來的 SVN repository，就可以作為在南部的同事們之間，協同開發的基礎。
我們希望，透過這樣子的機制，能夠在南下前，將主 repository 予以 split 出一個複本，帶到南部去工作。白天時，南下的組員們，彼此之間就使用南部的 repository 同步工作。等到晚上回到宿舍，能夠上網時，再透過 SSH tunnel，將南部的 repository，與北部的主 repository，予以 synchronize：將北部新修改的程式，送進南部的 repository 裡；亦將南部新修改的程式，送進北部的 [...]
