Hung-Yi Chen’s Blog

最近在處理 daily build system，要把某些 project 透過 hudson 建置成無人值守的自動化編譯系統。

不過在 git plug-in 上吃鱉….。

簡單描述一下我的狀況及解決辦法：

我在 github 上開了個 android project，想要設定 hudson 自動檢查 github 上的 code 是否有變更，有變動的話就抓回來編一份丟給 QA 去測試。

而這個 project 有兩個 branch，分別是 master 跟 bugfix。

為了清楚明瞭，在 hudson 上開了兩個不同的 project，一個專門 build master branch，另一個則專門 build bugfix branch。

這時候怪事來了….bugfix 的 SCM polling check log 看起來似乎抓到了 master 的 commit，而 master 的 polling check log 好像也抓到了 bugfix 的 commit。

本來以為是其他開發人員不小心把兩個 branch 做了 merge，不過仔細一看卻又不像這麼一回事。

稍微思考了一下，決定從 hudson 的 build log 下手。

結果發現了這種東西….

[workspace] $ c:\cygwin\bin\git.exe fetch -t git@github.com:gaod/android.git +refs/heads/bugfix:refs/remotes/origin/bugfix
[workspace] $ c:\cygwin\bin\git.exe ls-tree HEAD
[workspace] $ c:\cygwin\bin\git.exe log --all --pretty=format:'%H#%ct' origin/bugfix

等等，為什麼是 git log --all 呢？！

抓到兇手！git log --all 會去抓整個 project 的所有 branch commit log 啊！那難怪一直出現奇怪現象...

（不過奇怪的是，我搜尋了一下，似乎沒看到有人遇到這問題？）

解法就是，自己去抓 git plug-in 回來修掉這部分，拿掉做 git log 時傳入的 --all 參數，果然就好了！

下面附上 hudson 上這個 github 的 project 的 project 設定檔（好繞口:p）

URL of repository：git@github.com:gaod/android.git

Name of repository：origin

Refspec：+refs/heads/bugfix:refs/remotes/origin/bugfix

Branch Specifier：origin/bugfix

下面是用某公司內部神秘專案 KKK 做例子的示範，將整個專案內容從 cvs 搬移到 github 上，不過也適用於其他 git hosting/server

由於 code 中 big5 與 utf-8 混雜，但是 comment log 又都是 big5，導致沒辦法直接用 git cvsimport 來處理（git cvsimport 無法處理這種混亂的編碼狀況）

原先 Izero 長輩提供的做法是 cvs to svn，svn to git，切成兩段來做。但是太麻煩了，這樣還得架 svn server 才能處理。

這邊提供一個經過測試後可行的簡單完美做法…

有幾件事情當然得先做
1. 註冊 github 帳號
2. 在要 access github 上資訊的電腦做 ssh2 key，把 public key 上傳到 github
3. 在 github 開個專案

確認已經可以存取 github 上的專案內容後
1. 取得 cvs server 上的 CVSROOT & KKK repository，解開丟到 /home/cvsroot 後切換到 /home/cvsroot
2. 裝 cvs2svn(cvs2svn)，待會兒將透過 cvs2svn 中的 cvs2git 這個工具來做轉移
3. cvs2git –blobfile /tmp/cvs2git.blob –dumpfile /tmp/cvs2git.dump –fallback-encoding=utf-8 –encoding=big5 KKK –username gaod
(用 cvs 上的 gaod 身分把 KKK 專案在 cvs 上的東西 dump 到 /tmp/cvs2git.{blog,dump}。cvs 上程式碼編碼是 big5 & utf-8 混雜，comment log 則是 big5)
4. cd /tmp;git init KKK;cd KKK
(先 git init 建目錄後切換過去建出來的 KKK)
5. cat /tmp/cvs2git.{blob,dump} | git fast-import –force
(把 cvs 上的東西倒進去剛剛 git init 出來的目錄)
6. git remote add origin git@github.com:gaod/KKK.git
7. git push –force
(force push 到 remote)

早上 JoeHorn 告訴我，OpenSVN 要收了，所以原本 host 在 OpenSVN 上的 Maple-itoc project 顯然得趕快換地方了。雖然 OpenSVN 公告說五月一日開始會提供 repository dump，不過既然都要搬家了，自己 dump 一下當作練習也是不錯。

Survey 了一下，大部份的文章都是教學用 svnsync 來處理，不過我發現另一個工具也是很好用：rsvndump。

差別在於，svnsync 可以直接 mirror 整個 repository，而 rsvndump 則是 dump 成一個檔案。

svnsync 我的做法：

1.  cd ${SVNHOME}; svnadmin create Maple-itoc

　# 到 svn server 的 repos 目錄

2. 修改 ${SVNHOME}/Maple-itoc/hooks/pre-revprop-change，我是懶得設，直接丟個空白檔案然後 chmod +x

3. svnsync init file:///${SVNHOME}/Maple-itoc https://opensvn.csie.org/MapleBBSitoc

　# 初始化 dest repos，可以用 svnsync init help 看詳細參數，這裡都是匿名存取所以不需帳號密碼

4. svnsync sync file:///${SVNHOME}/Maple-itoc

　# 開始 sync….

一年前開始做 WinSCP 的正體中文翻譯，感謝 Mark Lin，今天終於全部翻譯完畢。需要的人請自行安裝 WinSCP 英文版，再抓翻譯檔下來放在 WinSCP 安裝目錄下，進入 WinSCP後即可選擇中文介面。但是因為功蓋許問題，WinSCP的作者不知道怎麼處理，所以有不少詞彙只能暫時用同義字替代，這個我還會跟 Martin Prikryl 問問，能不能我自己 compile 後再丟給他放官網:p如果發現誤義或是翻的不好，還請告訴我，謝謝:)

HomePage

http://subversion.tigris.org/

Book

http://svnbook.red-bean.com/

Chinese ver
http://freebsd.sinica.edu.tw/~plasma/svnbook/book.html (失效很久了，真可惜當時沒有先 mi 下來:~)

cvs2svn

http://cvs2svn.tigris.org/

viewcvs

http://viewcvs.sourceforge.net/

QuiteGuide

http://in2.wiki.ptt.cc/-SubversionQuickStart

http://www.me.ccu.edu.tw/svninfo/svnbook.html

1. 在 compile 時加入 -g 的參數
如果要 debug 的是 compile 過的 program
最簡單的方式就是在 compile 的時候 加入 -g 的參數
這樣 compiler ( 如 gcc ) 就會在 compile 時，
加入給 debugger ( 如 gdb ) 用的資訊
接下來產生的執行檔就能很方便的讓我們來 debug

能夠用 gdb debug 的情況有..

1. 用 gdb 來跑 program
> gdb your_prog
然後在下 run
來跑程式，或設 breakpoint 等等
( 關於 gdb 的使用，請參照 reference )
2. 用 gdb 來 detach 正在跑的 program
> gdb your_program process_id
這個方法就是先查出你要查的 process id
然後用 gdb 把這個程式停下來
來檢查看看問題出在哪
3. 有時候有的程式因為一些因素 ( 如 memory access violation )
而造成 core dump ( 這個會在作業系統留下 xxx core dump 的 message )
通常會在程式執行的 dir 產生 xxx.core 的 core file
這時候我們也可以用
> gdb your_program core_file
來做 debug 的動作
4. 最後，我們可以用 gcore(1) 這個程式
把正在跑的程式在 memory 的 image 抓成一個 core file
再用 gdb 來觀察這個 core file
5. 另外，在程式沒有 compile with -g option 的情況下
我們還是很常用到 gdb 的一個方法是 backtrace 這個指令
這個可以用來觀察程式的 call stack。
可以知道程式卡/死在哪個 function call 內

2. 觀察和 process 有關的資訊

很多情況下，我們的程式不一定有加上 -g 的 debug 參數
這個時候，有一些比較能 locate 問題的 system utils 可以幫助我們

1. truss(1)
這個可以用來觀察某個 program 使用的 system call
比如說 open(), close() 等等
這個可以讓我們了解到這個 program 正在 access 哪些檔案
卡死在哪個地方
ex: > truss -p process_pid
2. fstat or sockstat
用 sockstat | grep process_pid
可以查到這個程式開的 local address/port 及 foreign address/port

Syntax: find pathname-list expression

-name filename
-perm octnum
-print
-type t/f/c/b t:目錄 f:檔案 c:字元特殊檔 b:區域特殊檔
-exec rm -rf “{}” \;
把pathname-list裡所有file通通砍掉
-size n
+n (大於n)
-n (小於n)

-mtime n (幾天內被修改過)

example:
find ~ -name “*.c” -print
find / -size 0 -exec rm “{}” \;
find / -perm 4755 -print
find ~ -type d -print

實例:
找到大於10mb的檔案並刪除之
find . -type f -size +10000 -exec rm “{}” \;

找到所有包含 blahblah 字串的檔案
find . -type f -exec grep -l blahblah “{}” \;

列出所在目錄下所有檔案
find . -type f -print

tunefs -n enable + 掛載區

怕忘記所以寫起來:~