Official Python Planet@Taiwan

為了讓 Python 程式能容易在團隊之間快速流動，我們要求大家在程式編碼上一律使用 utf8 。只要在程式檔的第一行宣告 #-*- coding: utf8 -*- 以及使用 utf-8 編碼存檔即可。

學弟把我們已經作好的分枝要合併進主線時，不知怎麼搞地 merge 得非常混亂，而且也 push -f 進 hg 伺服器。

我們總共有三種分枝： 'default', 'Release for XXX', 'convert to InnoDB'，這次是要把 'convert to InnoDB' 的成果合併進 'default' ，再合併到 'Release for XXX' 。'convert to InnoDB' 是我們將 django-based 的系統從 MyISAM 引擎改到 InnoDB 所作的程式碼修改。主要的修改是發生在索引上，因為原本有一個地方設定了 unique_together = (('name', 'uplevel_id'), ) ，而它會造成 MySQL Error code 1071錯誤('Specified key was too long; max key length is 767 bytes')，因為 name 的原長度是 256 ，而我們又使用 utf8 ，所以它的實際長度為 256 * 3 = 768 ，但在 InnoDB 的索引中，限制為 767 以下，所以我們必須將 name 的長度限制為 255 。

當我改完程式碼後，就請學弟們在自己的本機上測試，如果沒問題的話，就作合併的動作，並送到實際運作的網站去。

結果，他合出了下面這個東西：



D 版是我的分枝成果，我希望他把 D 合併到 B 跟 C 中。但他生出了 E, F, G, H 。這 4 個版本都不是我想要的。

一開始，我的作法是再次作手動合併，結果我迷失在那些修改的程式碼中，花了快 3 個小時，依舊無法解開，所以我當時用下策來處理，就是以 hg strip 指令把 hg 伺服器上的 E ~ H 的版本洗掉。然後重作合併。

這個方法十分爛，但當下，剛好沒有人上傳程式碼，而我又陷在那堆程式碼中，所以我選了這個作法。

這種作法，會有一個大問題，如果有人在未刪除版本前，就作了 pull, update ，那麼下次他在 push 時，就會出現衝突。他一定會 merge 到亂掉，因為他手上的 E ~ H 版本的程式碼不具含意，所以他也無法以程式碼內含意義來作合併，這樣他會像我一樣陷入毛線當中。

所以，在我解決 hg 伺服器上的亂象後，我靜下心來仔細思考，才發現我何必管 E ~ H 作了什麼事呢! 我只要在 merge 時，忽略它們的修改就行啦!

首先，我 clone 一個 LOCAL 儲存庫，而且只 clone A, B, C, D 之前的版本。作法必須分兩次，因為 clone 只會把該版本的媽媽下載下來，所以像是 A, B, C, D 4 個版本，卻有 2 個 heads ，我就得分兩個指令來下載，指令如下：

$ hg clone https://SERVER/my_software LOCAL -r C
$ cd LOCAL
$ hg pull -u -r D

然後，依我原本想要的合併方式處理：

$ hg ci -m '"convert to InnoDB" branch ...' --close-branch #P.S. 這個作法事後會造成問題 *1
$ hg merge -r B
$ hg ci -m WRITE_f'_COMMIT_MESAGE # 產生 f'
$ hg merge -r C
$ hg ci -m WRITE_g'_COMMIT_MESAGE # 產生 g'

這樣 LOCAL 的版本圖就像下圖一樣。



再來，我把伺服器上的錯誤版本 clone 到本機的 SERVER-FIX ，然後在 SERVER-FIX 中依 branch 作合併，最後合併出 'convert to InnoDB' 及 'Release for XXX' 兩種 heads ，指令如下：

$ hg clone https://SERVER/my_software SERVER-FIX
$ cd SERVER-FIX
$ hg update -C H
$ hg merge -r E
$ hg ci -m WHATEVER_MESSAGE

成果如下圖：



接下來，我回到 LOCAL 儲存庫中，把 changeset push 到 SERVER-FIX 中，成果如下圖：



最後，我要作的就是把 I, G, g' 三者合而為一，而且要在 merge 時，完全忽略 I, G 的程式碼修改，怎麼作呢? 指令如下：

$ cd SERVER-FIX
$ hg update -C g'
$ hg merge -r I
$ hg status
M models.py
$ hg cat -r g' models.py > models.py # I 版的修改，只在 models.py 上，而我又用 g' 版的 models.py 把 I 版修改完全洗掉了
$ hg ci -m MERGE_g'_I_MESSAGE
$ hg merge -r G
$ hg status
M models.py
$ hg cat -r g' models.py > models.py # G 版的修改，只在 models.py 上，而我又用 g' 版的 models.py 把 G 版修改完全洗掉了
$ hg ci -m MERGE_g'_I_G_MESSAGE

最後成果如下圖：



再為各位整理一下，合併「錯誤的 hg 儲存庫」步驟：

1. 在本機上，重作一個完全正確的 LOCAl 儲存庫。
2. 在本機上，重現一個與伺服器相同的 SERVER-FIX 儲存庫，並依 branch 作合併，讓一個 branch 只有一個 head 。
3. 將 LOCAL 的成果 push 到 SERVER-FIX 中。
4. 讓 SERVER-FIX 中的 head 與 LOCAL 的 tip 合併。而且在合併時，完全消除程式碼的修改，讓它們合併完，程式碼是與 LOCAL 的 tip 程式碼完全相同。
5. 確認無誤，就能 push 到 hg 伺服器了。

以這種方式處理完的 hg 伺服器，才可以讓所有人都免去再次合併 E~H 這段錯誤程式碼的痛苦。

基本上， hg 的主要運作方法，就是要讓所有人習慣在自己的本機上， merge 自己與其他人的成果，如果你能順暢地走完 1 ~ 4 的步驟，也代表你足以應用 hg 在大部份的程式碼修改工作了。

註1 我太早在 'convert to InnoDB' 分枝上下 --close-branch ，所以我後來在使用 hg update -C 'convert to InnoDB' 時，它居然是 update 到 I 版，而不是 e' 版。

因為 Windows 在紀錄檔案名稱時，是用 UTF-16 ，而不是 UTF-8 作紀錄，所以如果在 Windows 中，加入一個「中文檔名(嚴格來說，是非 ascii 編碼的名稱)」的檔案，那麼這個檔案到了 Mac OS X, Linux 平台時，就無法使用了。

前幾天，學弟問了我一個問題，讓我發現原來我們對 branch 的概念還不是很熟悉。事實上，這是件好事，從問問題中，才能發現原來事情不是我們所想像的，早發現早好。最痛苦的是在弄亂運作中的程式碼後才驚醒。

在說明學弟的問題前，要先來前情提要。我們研究室到目前為止至少開發了 4 套系統，用「至少」是因為這 4 套比較大型，除 django 程式碼外，自己所寫的 .py 及 .js 近 4 萬行，且不含樣版。而這 4 套系統當然有部份的程式碼是一樣的，我想程式碼寫得多的設計師一定也是這麼想，常用的 bug 紀錄器、郵政地址選擇、政府機關資料等東西，一定會弄個模組另外放，到時候開發新系統時，整個模組(資料夾)拿進來就行了。

但是一個模組該如何與主系統共存開發呢? 尤其是模組與主系統程式碼都還在變動階段。
使用 Mercurial 讓這件事，變得非常輕鬆，假設我們有 A, B, C, D 等 4 個系統，而有一個 common 模組，這時，我們應該在 common 模組開 4 個 branches ，分別是

• 'release for A
• ''releasr for B
• ''release for C'
• 'release for D'

假設這 4 個 branches 都是在 changeset:300 時 branch 出去的。然後，過了一段時間，因為 C 系統的需求，我們修改了 common 模組，它的 changeset 來到了 340 ，且我們也將這 300:340 的修改 merge 到 'release for C' 了，這樣對其他 3 個系統有沒有影響? 當然沒有。

因為在伺服器運作的儲存庫上，以 A 系統為例，一定是把 common 模組切到 'release for A' 了(用 hg update -C 'release for A' 這個指令)，就算某天將 A 系統上的 common 更新至 changeset:340 ，但這也只有在 common/.hg 的資料是 340 的， common/* 的資料一定還是停在 'release for A' 這個 branch 上，而 'release for A' 的最新版仍舊是 300 。

所以那天如果負責 A 系統的程設師有空了，它想使用 common 模組的最新功能時，他只要在 'release for A' 的 branch 中， merge tip 版本，並處理 A 系統這邊應對新 common 模組的修改，就可無痛昇級。

利用 branch 觀念，我們可以輕鬆整合多種函式庫、模組之間的版本整合問題，那麼學弟的問題是什麼呢?
如下圖：



學弟很貼心地在 branch 後，再為 " default 分枝" 作一個 manual commit ，以維持兩個 heads ，這樣會讓其他人在使用時，不致於出現 +1 head 的訊息(但這也只是在某些情況下)。

結果我後來又把 " default 分枝" 的成果 merge 到 'Release for XXX' ，這讓儲存庫上只剩下 1 個 head ，這個結果讓學弟有點困惑，他以為剩下一個 head ，那其他人在寫程式時，會不小心 commit 錯 branch 。
我說不會，因為他們原本手頭上的儲存庫就指定好是用那一種 branch ，所以在 hg pull -u 後，程式碼會變成該 branch 的最新版，在改完程式後，他們 commit 的成果也寫入相同的 branch ，而不會在 " default 分枝" 上， commit 到 'Release for XXX' 。

這惟一的小問題是其他學弟要把 commit 後的成果 push 到 HG Server 時，會出現提醒 +1 head 的訊息，但這是沒辦法避免的，用 hg push -f 就解決，因為既然 branch 了，就一定會有 multi heads 的情形。

目前常見的作業系統有 Solaris, Ubuntu Linux, Fedora Linux, FreeBSD, XXX Linux, YYY BSD, Mac OS X 及 Windows ，而這些系統中，除了 Windows 的換行符號是用 \r\n 外，其他的都是用 \n 。

所以當 Windows 使用者將他們的程式碼上傳至版本控制器時，換行符號會以 \r\n 為主，然後我們其他使用 Mac OS X 及 Ubuntu Linux 的人，在上傳程式碼時，又可能會將換行符號換成 \n ，那麼在作版本比對的時候，只差 \r 的資料行也秀出來了，這實在不利於比對效率。不過這一點， NetBeans 倒是聰明地將只差 \r 及空白的資料行作忽略。

但話說回來，有時候，我們是在遠端 ssh 連線下，作設定檔或是程式碼的比對，這時候，如果出現一堆 ^M 符號也是挻困惱的。

所以這時候，就要請 Windows 使用者多作一個設定，讓他們在 push 檔案時，能自動將 \r 移除。

如果你安裝的是 TortoiseHg ，那麼請到你的安裝目錄下找一個 Mercurial.ini 的檔案，把它打開，加入下列內容：

[extensions]

最近，我們的系統要作二周的使用者教育訓練，且接受他們的回饋意見，而系統功能離真正的完工還有一段小距離，因為他們可能會提出一些新的想法，若可行性高的話，我們也會把功能實作上去。

而這種「兩線並進」的程式碼維護該如何處理? 因為我們使用的是分散式版本控制器，所以這策略可分簡單及進階方法兩種，當然啦，進階方法必定有優點比簡單方法多一點，要不然，大家都用簡單方法不就得了。

首先，我們要先了解為什麼會有「兩線並進」的現象發生。

在作系統展示及教育訓練的時候，有可能會面臨到第一次出現的 bug ，因為這時候所輸入的資料、操作流程會因使用者的真實需求而與我們開發者在測試階段有所不同，造成我們會有 debug 的需求。但在這二周之間，除了去作教育訓練的人外，其他沒去的開發者會繼續作其他功能的設計，那系統程式碼也會有因新增功能而產生的修改。

那如果兩者所新增、修改的程式碼都在同一個儲存庫中，那是不是一定會發生開發者寫的新功能變成教育訓練時的新 bug 呢! 我相信會的。

所以這時候，一定要用兩線各自獨立運作的方式，才會避免雙方互挖牆腳。

首先介紹簡單方法：

在展示主機上，先作 hg clone ，得到一個 xxx 專案資料夾，然後再作一次 hg clone xxx xxx-bugfix 。這時候，我們使用 xxx-bugfix 來作系統展示之用，如果有 bug 的話，也直接修改在這個 xxx-bugfix 專案中，並把這些修改 push 回到 xxx 之中，而在 xxx 之中，我們則是作新功能(從伺服器 pull -u 來的)及 fixed bug 的合併。合併後再整個 push 回程式碼伺服器上。這樣一來，訓練者所作的 bug fix 也可以讓開發者獲得，而開發者寫的新功能不會影響訓練者使用的展示系統。

以上方法的確可以滿足「兩線並進」的需求，然而它有一些麻煩的事要處理，當訓練者在作 bug fix 時，他要不是在展示主機上直接修改，要不然就是把展示主機的 xxx-bugfix 抓回自己的電腦來處理，改回後，再放回展示主機，這造成了另一個問題，如果訓練者有兩個以上，而他們同時要作 bug fix 呢! 又回到 copy 的時光了，要不然就是在展示主機上再搞一個程式碼伺服器讓 xxx-bugfix 可以變成多人合作的 debug 專案。

Mercurial 的分散式架構讓「兩線並進策略」變得非常簡單，但如果只用了這一招，這有點小看了 Mercurial 的強大。

下節我將介紹使用 branch, merge 指令實現「兩線並進策略」。

因為 hg 不同與 svn 可以資料夾結構來看待專案，在 hg 中，一個專案就是一個資料夾，其下不會有子專案，所以像我手頭有二十幾個 hg 專案時，如果要同時更新( pull -u )這些專案，我必須一個專案一個專案進去打 hg pull -u ，這實在太花時間了。但還好我用的是 Linux ，所以就把這些煩人且重複的指令寫成一個 shell script ，執行一次就更新全部。以下是我的程式碼：

#!/bin/bash
today=`date +%Y%m%d`
me=`whoami`
echo ${today}
original_dir=${PWD}
touch '/tmp/.'${today}

if [ "$1" != "" ];then
    dest=`find $1 -regex ".*\/\.hg$"`
else
    dest=`locate -r "\/home\/${me}\/.*\/\.hg$"`
fi

for dir in $dest;do
    if [ ! ${dir/*mercurial_appengine*/} ];then
        continue
    fi
    cd ${dir}/..
    echo -ne "\t*** ${PWD} ***\n"
    hg pull -u || exit
    cd $original_dir
done

今天晃到自己的專案 django-pgpauth 時，才發現多了 Mercurial 的選項。原來早在 5 月 28 日時就己經正式推出了。

要轉移原來的 subversion 資料庫到 hg 儲存庫中是很簡單的一件事。

在 Ubuntu 下，先安裝 python-subversion 套件。然後將 /etc/mercurial/hgrc.d/hgext.rc 中「# hgext.convert =」的註解拿掉。

接下來，作轉換的動作。

# hg convert http://projectname.googlecode.com/svn hg-client
# cd hg-client
# hg push https://projectname.googlecode.com/hg

最後，記得到 administer > source > Repository type，把 Version control system 改成 Mercurial 即可。

一個因為中文檔名，讓我必須在 Windows 下工作的專案 *。今天我多花了 2 個小時，只為了要送出 4.3 MB 的中文檔名資料夾。是什麼問題呢! 是 {urlopen 10053} ，但倒底它是個什麼問題，我還是搞不懂。我後來是把它的檔名改短一點，然後先 copy 至學校的其他 windows 後，再作 hg push ，這樣總算成功了。

PS 我有試過 hg-fixutf8 了。但它只會在 commit 及 update 時作 utf8 <=> cp950 的轉換。這樣我無法在 NetBeans 中工作。

這都怪 NetBeans 把 Mercurial 整合的太好了。

原本我都是用 Gvim 來寫 Web-base 程式的，事實上，我的 Gvim 也調校的不錯，有 File Tab 、 Class/Function Navigator 、 Tab Complete ，而重要的是它還有 1G, G, yy, dd, cw, <ctrl>+f, <ctrl>+b, H, M, L...等。

不過，當我要比對修改後的程式時，單純只用 hg diff|colordiff|less 就顯得有點薄弱了。

而這時，我發現 NetBeans 編輯器可以整合 vi key-binding ，天呀! 這是多麼棒的一件事，之前我在試用 Eclipse 時，就覺得它的 vi key-binding 效果不是很好用，而且還要花錢買，讓我打消了轉換平台的欲望，但這個 NetBeans + vi 的功能就實實在在地滿足了我的需求。

更棒的是， NetBeans 整合版本控制的功能比 Eclipse 好。在 Eclipse 中，所謂的版本控制只不過是把我在 shell 裡用的指令，放進它的 menu 中而已。但 NetBeans 卻可以讓你在 Editor 中，實際看到程式差異並選擇回復。而在設定方面， Eclipse 的 menu/option/perspective 實在太多了, 常常讓我搞不懂，這玩意到底要到那去找。

令人驚奇的是 NetBeans 還結合了 jdbc 的功能讓我可以把它當作是 Mysql/PostgreSQL 客戶端介面使用。這也一併讓我省了設定 phpMyAdmin 的功夫。 NetBeans 真的作到了 One Stop Shopping 。

在安裝上， NetBeans 6.5 也比 Eclipse 3.X 來得簡單， Python, Mercurial 它已內建，我只去了 http://jvi.sourceforge.net/ 下載 vi plugin 。況且，之前我在安裝 Eclipse 時，有些機器會遇到裝不起來的情況，這也讓我頭痛呀~ 害我先將安裝成功好的 Eclise 打包起來，然後看誰需要，就整個給他。

只是使用 NetBeans 我得付出一個代價， NetBeans Editor 的反應略比 Gvim 慢一點，雖不致造成我的困惱，但就是感覺得到。我想這也是沒辦法地，因為 NetBeans/Eclipse 之類的 IDE 平台還得即時看你輸入的單字去找它相關的說明，以及檢驗文法是否錯誤。

It's enough for me to test/learn/use mercurial, i decide to convert my old subversion repositories now.

To convert subversion repository, you need the '''python-svn''', '''python-subversion''' plugins in the Ubuntu.

Then you should check the working subversion repository has no need to type username/password at the status of '''svn update''', or you will get the '''XXX does not look like a Subversion repo''' message from '''hg convert'''.

When you are ready, just type '''hg convert -s svn your_svn_repo_dir''', and you can get a dir named '''your_svn_repo_dir-hg'''.

Congratulation! It's a peice of cake.

實際上， Mercurial 這種分散式版本控制器是不太需要架個 Web Server 來 Run 的，尤其是我多半都是獨自在寫程式，但架了個 Web Server 後，我會比較方便在多台個人電腦中轉移陣地，且這也多了一種備份的機制。

不過，目前已有人將 hg 成功移植成 GAE 版(hg-repos.appspot.com)，現在只待作者把說明文件完成，我就會將跑在 apache 上的部份儲存庫再移至 GAE 去。

廢話不多說，透過 mod_python 來跑 HTTPS 版的 Mercurial 儲存庫方式如下：

一、 下載 modpython_gateway.py ，載點何處? Google 比較快且安全。下載後放到 /raid1/A2B2/www/HG/ (可自行更換其他資料夾) ，也就是在 apache.conf 中所設定 PythonPath 。此檔案內容不用修改。

二、 設定如何執行 modpython_gateway.py ，一樣在 /raid1/A2B2/www/HG/ 下，新增一個 hgwebdir.py ，其內容如下：

import os
os.environ["HGENCODING"] = "UTF-8"

from mercurial.hgweb.hgweb_mod import hgweb
from mercurial.hgweb.hgwebdir_mod import hgwebdir
from mercurial.hgweb.request import wsgiapplication

def make_web_app():
    return hgwebdir("/raid1/A2B2/www/HG/hgweb.config")

def test(environ, start_response):
    toto = wsgiapplication(make_web_app)
    return toto (environ, start_response)

三、 設定你的檔案庫位置，一樣在 /raid1/A2B2/www/HG 下新增一個 hgweb.config 其內容如下：

[paths]
/trachg = /raid1/A2B2/www/trac/hg

[collections]
#我把 /raid1/A2B2/www/HG/product soft link 到 /product
#這樣在連結上，才會是用 /product/product1 來觀看 product1 儲存庫。
/PathDoesNotMatter = /product/

[web]
style = gitweb
allow_archive = bz2 gz zip

四、 apache.conf 設定如下：

<virtualhost *:443>
--ServerSignature Off
--ServerName hg.yoursite.name
--DocumentRoot /raid1/A2B2/www/HG/tmp
--RewriteEngine On
--RewriteRule ^/(.*) /DoesNotMatter/$1
--<Location />
----PythonPath "sys.path + [ '/raid1/A2B2/www/HG' ]"
----#PythonDebug On #Uncomment this ligne if you got a problem and need debug information
----SetHandler mod_python
----PythonHandler modpython_gateway::handler
----#PythonOption SCRIPT_NAME /repo
----PythonOption wsgi.application hgwebdir::test
----AuthType Basic
----AuthName "Mercurial Repository"
----AuthUserFile /raid1/A2B2/www/auth_users
----Require valid-user
--</Location>
--LogLevel warn
--ErrorLog /var/log/apache2/hg_error.log
--CustomLog /var/log/apache2/hg_access.log combined
--SSLEngine On
--SSLCertificateFile /etc/apache2/ssl/apache.pem
</virtualhost>

五、 重啟 apache

你就會在 https://hg.yoursite.name/ 中，看到 trachg 、 product/product1 、 product/XXXproduct ... 的儲存庫了。

這個問題搞了我很久。

用 trac 內帶的 tracd 來跑， changelog 部份的中文就是正常的，但跑在 apache 上時，它就亂了，而且只亂 changelog 部份，程式碼的 diff 結果及 raw 格式都沒事。

看了很久的 mercurial-plugin-0.11 程式碼，看來看去覺得這應該是 mercurial 的錯，不過為什麼我在 shell 中用沒事，或是用 tracd 跑也沒問題，但它跑在 apache 上就錯了呢???

hg 在讀 changelog 的部份，它是用 mercurial.changelog.changelog 函式來處理，但裡面有一個 read() 被 mercurial-plugin 拿來用了，而這個 read 函式在解讀字串時，要叫用 util.tolocal() 來處理編碼，只要沒設定 os.environ['HGENCODING'] 的話，它就會預設為 ascii ，這就是造成 changelog 亂碼問題的地方。

以前，我只須在 /etc/python2.5/sitecustomize.py 設定 sys.setdefaultencoding('utf8') 就行了，現在還得加上 os.environ['HGENCODING'] = 'utf-8' 。

我還是不太懂 os 及 sys 的差別是什麼?

已經使用 zotero 來管理我研讀期刊、網頁有好一陣子了，幾天前終於把我的小黑昇級成 Ubuntu 8.04 ，用得很開心，只是今天我終於想到 firefox 中的 zotero 資料夾我並沒有作備份，呀! 一整個悶，嘿~只有再讀一遍了。還是趕快把資料夾交給 mercurial 管理吧!

什麼，你不知道什麼是 zotero ，那趕快看這裡、這裡還有這裡。

重灌了 XP，拿掉了 TortoiseHg，又拿掉了 TortoiseSVN。

... continue...

我的工作除了寫程式，還得寫文件，最近與其他人一起作文件編輯的動作，覺得很令我難受。

subversion 我已教過 N 遍了，但使用者用起來就只是把它當成 FTP 來用，註解也不寫，光是改檔名。這說明了他們根本沒學會『版本控制器』。

唉~年紀輕輕地，腦袋就裝不下了。

我很失望~

這讓我想起，之前還是社會新鮮人時，面試工作時，我都會說：『請給我一個學習的機會，我會認真學習的。』我可是確實作到。

http://www.selenic.com/pipermail/mercurial/2008-March/018014.html

在 Windows 上安裝 Mercurial 又安裝了 TortoiseHg 的人請注意，TortoiseHg 在 HKEY_LOCAL_MACHINESOFTWAREMercurial 裡塞了它自己的 hgrc，啟用了 1.0 裡沒了的 hgext.qct 和 hgext.hgconfig。錯誤訊息很擾人，可用：

hgext.qct=!
hgext.hgconfig=!

關掉。

#!/usr/bin/env python
from mercurial import demandimport; demandimport.enable()
import cgitb; cgitb.enable()
import os; os.environ["HGENCODING"] = "UTF-8"

from mercurial.hgweb.hgwebdir_mod import hgwebdir
from mercurial.hgweb.request import wsgiapplication
import mercurial.hgweb.wsgicgi as wsgicgi
def make_web_app():
    return hgwebdir({
        'name1': '/path/to/the/repository',
        'name2': '/path/to/the/repository',
    })
wsgicgi.launch(wsgiapplication(make_web_app))

... continue...

最近我把 $HOME 裝進 Mercurial 了。

應該有很多人會這樣作。還沒有試的人可以試試看，味道不錯。下個 hg init ~/ 來在 $HOME 裡建立 .hg 貯庫，然後 .bashrc、.vimrc 和 .irssi/ 就可以通通塞進去了。

... continue...