Mercurial on Google Code is available to every project

今天晃到自己的專案 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 即可。

from subversion to mercurial

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.

problem with django: use __year or not && use subversion or not

when i put the new sources in the remote web server, and something happened!

the query result had nothing!! when i 'diff' the environment of server and mine, i got one thing difference. one is python 2.5.2 and the other is 2.5.1, but i have no idea about why!

the problem is 『__year』, i set a datetime field in a django model, and i can query it by year with suffix parameter __year like filter(date__year=datetime.date.today().year). and it's work for mine but not for remote server. so for the general case, i changed the code to two queries like below:

filter(date__gte=datetime.date(datetime.date.today().year, 1,1), date__lte=datetime.date(datetime.date.today().year, 12,31))

then i changed 5 files in my application. before svn commit, i use svn diff to see what i modified and found a error.

Can you see??

--- apps/supervise/views.py     (revision 1256)
+++ apps/supervise/views.py     (working copy)
@@ -145,7 +145,8 @@
if h.has_key('year') and h['year'] != '':
    Y = Year.objects.get(id=h['year'])
    try:
-            sc = sc.filter(date__year=Y.date.year)
+            sc = sc.filter(date__get=datetime.date(Y.date.year, 1, 1),
+            date__lte=datetime.date(Y.date.year, 12, 31))
    except:
        pass
........

if i have no subversion, i will write a bug after a debug.

版本控制器不只是用來管程式碼，一般可編輯的辦公室電子文件也可以

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

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

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

我很失望~

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

subversion 的 commit log 寫錯了。

把伺服器中的 svn/hooks/pre-revprop-change.tmpl copy 一份成 svn/hooks/pre-revprop-change ，並且要給它可執行的權限。

然後在自己 co 出來的專案資料夾中，打

# svn propset svn:log "xxxxxxx" -r 903 --revprop

即可把 903 版的 log 變成 xxxxxxx

Trac0.11b1 + Mercurial + Postgresql

基於對 Python 的喜愛，所以想要把 subversion 換成 Mercurial ，但目前還只是測試階段，真正上線使用的還是 subversion 。另外一直都想要找個機會把 Mysql 換掉，到不是說 Mysql 不好用，而是我對於 PostgreSQL 本來就有一分感情，那是在 Mysql3,4 還不支援 UTF-8 時，我用 Perl 寫了一個 unicode 字的查詢系統。

而今天所要介紹的，不過是我在工餘之際把玩的小小玩意，既然成功了，那就作個紀錄。

在 Ubuntu 安裝軟體是一點都不難的(只要有 .deb 檔)，所以要裝 Trac + PostgreSQL + Mercurial ，請執行下面指令：

# sudo apt-get install postgresql-client-8.2 postgresql-8.2 python-psycopg2 \
> python-setuptools python-genshi \
> python-psycopg2 python-pygments python-docutils mercurial

接下來，安裝 Trac 0.11b1 主程式
# sudo easy_install http://ftp.edgewall.com/pub/trac/Trac-0.11b1.tar.gz

最後安裝 Trac 控制 Mercurial 的外掛
# svn co http://svn.edgewall.com/repos/trac/sandbox/mercurial-plugin-0.11
# cd mercurial-plugin-0.11/
# sudo python setup.py install

再來是設定，首先我們建立一個 dbuser ，這方面， PostgreSQL 有點奇怪，或許是我 Mysql 用久了，
# sudo -u postgres createuser trac -P
Enter password for new role:
再輸入一次:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) n
CREATE ROLE
# sudo createdb -O trac trac
並將 pg_hba.conf 中的
local all all ident sameuser
改成
local all all password

這樣你的 trac 程式就可以透過帳號: trac 密碼: trac host: localhost 的方式與 PostgreSQL 連接了。

接下來，初始化 trac 設定目錄及 hg 儲存庫：
# trac-admin /path/to/myproject initenv
# hg init /path/to/myproject/hg

另外在 trac.ini 中加入
[components]
tracext.hg.* = enabled

[hg]
show_rev = yes
node_format = short

用 tracd --port 8000 /path/to/myproject 測試一下有沒有問題，沒有問題就讓 mod_python 來跑吧!

下面則是 mod_python 的設定檔

NameVirtualHost *:443

  ServerAdmin admin@xxx.com
  ServerName trac.xxx.com
  DocumentRoot /www/trac
  
      SetHandler mod_python
      PythonHandler trac.web.modpython_frontend
      #PythonPath "sys.path+['/usr/local/Trac/lib/python2.5/site-packages/']"
      PythonOption TracEnv /www/trac
      PythonOption TracUriRoot /
      PythonDebug Off
      SetEnv PYTHON_EGG_CACHE /www/trac/tmp
      SetEnv LANG UTF-8
      SetEnv HTTPS 1
      AuthType Basic
      AuthName "Trac Server"
      AuthUserFile /www/htpasswd_users
      Require valid-user
  
  ErrorLog /var/log/apache2/trac_error.log
  LogLevel warn
  CustomLog /var/log/apache2/trac_access.log combined
  ServerSignature Off
  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/apache.pem

高級 Subversion GUI: Eclipse

對滑鼠重度使用者來說，編寫 python 程式是需要一個稱手的 IDE 工具的，在這方面，我強烈建議使用 Eclipse ，原因是跨平台、開源及外掛多，所以你可以用它來寫 java, PHP, perl, python, ruby...，缺點只有一個，要學會 java 才能幫它加特殊功能，還好你想得到的，多半有人作了。

但對不在乎滑鼠的使用者來說， Eclipse 是有點麻煩的，在編寫文字上，方便性就不如 VIM 了，快速移動、大區塊剪貼、尋找 re 字串、自動補齊(需 VIM 外掛)等，用 VIM 是十分容易作到的，像是你要打個 SuperviseCase.objects.all() ，你只要 Sup.obj.all() 這樣就夠了。

所以我並不常用 Eclipse 來開發程式，大部份是用它來 Demo 程式碼給學弟妹看，因為他們都是用這一套的。

但是 GUI 工具有一個好處，比較程式碼差異及看 svn log 時很方便，只要是使用 svn 時，會用到 less 指令的，都適合用 Eclipse + subclipse 來作。雖然 subversion 也有其他 GUI 工具配合，但 Eclipse 牌子比較大，用戶也比較多。建議各位試試。

= 後記 =

現在我改用 NetBeans 了。

損失的不過是4~50行程式碼

話說今天早上，用我的 IBM R51 寫著督導報表的程式，主要是建立了一個表單，大部份是設定有那些欄位及其屬性而已。

突然接了一通電話要改報名網站，聽完了需求後，就到另一台桌上型電腦 Core Duo 2 (桌上型是組裝的，我都習慣以 cpu 版本來當作它的名字)去寫，因為報名網站我已經在 Core Duo 2 上設定過了，改這一兩個功能就懶得在 R51 上再設一個網站出來。而修完後也剛好中午吃飯，所以就和內人出門了。

回來後，繼續用我的 R51 ，因為我的習慣相當不好，跟這位老兄一樣，喜歡邊開火邊移動，不過我的頻率比較短，通常只發作於與電腦見面的一開始，或許這也是我成就比較低的原因，所以著實在 youtube 上看了不少棒球、羽球的影片後，才進入我的工作。

因為與上午開發督導表單的時間有一陣子(3~4小時)了，我根本忘了還沒有 check in 的動作，又因為臨時想到放督導程式的資料夾位置不好，想用 Eclipse 作 svn co ，將來也用 Eclipse 作版本管理的動作。所以在 Eclipse 中作 svn co 後，我的 R51 同時有兩個督導程式資料夾。

系統中有兩個相同的檔案，對一個硬碟有 60 G 的 NB 來說，一點問題也沒有，有問題的是我覺得這樣的放法會讓我亂掉，於是我刪除了之前一直開發的那一個。所以結果就如本文題目一樣了。

因為我還沒有 check in ，所以那個表單設定的程式就沒有了。剛發現這個事實時，我很生氣，我居然可以用 subversion ，用到這種地步，想把自己打死。

接著，我開始尋求正面想法，以前在用 copy 的年代，我還丟過整個 lib.pl 呢!而丟了之後，還讓我想出比較有效率的 lib.pl ，難怪我覺得我的程式能力好像沒有之前好，因為現在不容易丟掉程式碼了。嗯~程式技術與版本管理能力似乎呈反比。

不過，我可不想回到過去手動整理麵條的時代，在用了 subversion 後，通常一天至少 check in 一次，丟掉程式的機率相當低，也就今天這麼一次，於是寫這篇文章來作個紀念。

Eclipse + PyDev

一直以來，都是用 Vim 作編輯的：寫網頁、 Perl 、 Python 、 shell script 、設定檔…，但學弟妹們還不會用 Vim 就要求他們拿來寫 Python ，這有點為難。對很多人來說，「鍵盤」絕對是「沒有生產力」可言的。

那如果不用 Vim 的話，那麼我的第二選擇會是 Eclipse ，因為它是 open source ，是 IBM 拱的，可以跨平台，也適合拿來寫網頁、 Latex 、 Python 、 PHP ...。

寫了一份簡單講義教他們如何在 Windows 上搞定 Eclipse + PyDev 。結果自己在 Ubuntu 平台上卻搞不定 Eclipse + Subclipse ，問題是出在我使用 Gnu 的 Java Run Time ，而它在 ssl key 的部份會發生無法接受過長的 ssl 憑證，卡在這裡非常久，試著安裝 javahl 函式庫，但我不知道到那裡改設定( Eclipse 的選項實在太多了，雖然我現在終於知道要到那裡改了)，所以我放棄了 Gnu 的 jre ，改用 sun 出的 j2se sdk 。裝完後，在啟動 eclipse 前，先作如下設定

export JAVA_HOME=/usr/local/jdk1.6.0_01
export PATH=$JAVA_HOEE/jre:$JAVA_HOME/bin:$PATH
export CLASSPATH=$JAVA_HOME/lib

即可。

我打算給 Eclipse 一個機會，讓我在跑 Python 程式時能更有效率，編輯的部份當然還是得靠 VIM 了。

svn/cvs除了copy效率比copy快，還有其他的優點：備份及復原…

之前 debian 的版本控制伺服器發生過怪客入侵事件，而他們的解決之道是立即讓伺服器下線，並比對所有協助開發的程式設計師手邊的沙箱，藉此找出有問題的程式碼。因為每個人手頭都有一份全專案副本，所以有跡可尋。

如果是發生在 copy 來 copy 去的專案中，那要比對程式版本的差異就麻煩了，因為可能沒有工程師有所有的專案程式碼。這最常發生在使用「copy」概念的軟體專案中，他們使用元件化、模組化的概念來開發程式，Amon負責A元件、Bill負責B元件，這樣雖不會有衝突，但如果Amon掛了，搞不好還得找個人來重寫A元件。

所以如果你用了 svn/cvs ，你還有機會快速比對被怪的程式碼以及每個程設師會幫你備份1個專案。

使用svn/cvs的重要觀念：人的溝通才能花解程式碼的衝突

幾天前跟一個在軟體業界滿長時間的朋友談程式碼管理的技巧，他說：「小專案一定不用版本控制，而大專案也不一定要用。」

這原因出在他們有一個慘痛的教訓。因為一個程設師忽視其他程設師的錯誤修正，強制把他的patch檔送 VSS 儲存庫(我不是故意指名道姓的，因為事實上，他們是用 VSS)，於是1個bug，兩個人解決，也就是等於沒人解決。所以他們衍生出使用版本控制器一定要用 lock 動作，單一檔同時間只允許1個程設師修改，而且不可以破壞別人建立的 lock 。這麼作，只是把 VSS 當作高級 cpoy 指令來用而已。

我跟這位朋友提到使用 svn/cvs 的一個重要觀念：每次 commit 前，要先作 update ，且要看看別人所修改的程式碼及註解，如果與自己的程式發生嚴重的邏輯衝突時，不是硬幹別人的程式，而是打個電話跟他聊聊。

如果軟體公司沒有正確地使用版本控制，而是使用老舊的copy思維。為此，他們會衍生出一種與 copy 相輔相成的工作模式：專業分工。把一個軟體專案元件化、模組化，切完再丟給工程師作，每個人專注自己的小區塊，出了問題自己解決，然後再找一位菜鳥程設師來作 SA ，時間到了，就跟大家要要程式碼，兜在一起跑。這麼作看似解決了程式碼衝突的問題，但也帶來新的問題：

1. 程設師漠視團體的效益，專注自己的效益。
   
2. 認為只要開幾次會，定下模組溝通的介面，就可以不再溝通了。
3. 少了彼此學習的機會。

可是如果你是正確使用版本控制器的，舉個例子( http://chinesetrad.joelonsoftware.com/Articles/TheJoelTest.html )來說說：「約耳老兄在Excel 團隊時有個規定，每天要將專案編譯1次，且導致編譯失敗的人必須從此負責重新編譯的動作(作為處罰)， 一直到有其他人出錯為止。這是個讓人不要導致編譯失敗的好誘因，同時是個讓大家輪流處理重新編譯的好方法，這樣大家都會知道怎麼做。」

當你可以綜觀整個專案時，你可以了解模組之間的關係，可以看看別人的程式精華，可以少1個SA(或許軟體公司對這個比較心動)，而你只是花1~3個小時，去學1個你未來都用得到的版本控制器，很划算吧!

等等，我聽到有人反應「如果公司不想讓所有人接觸整個專案呢」!這個例子我有遇到過，曾經就遇到一間公司要求1個工程師把商業邏輯都寫在資料庫的預存程序中，而另1個工程師則是撰寫網頁程式來呼叫這些預存程序，這公司希望產品不要讓1個工程師全把握住。遇到這種例子，就善用 subversion 的權限管理，把一個專案中的兩個模組設定1個只有A工程師可讀寫，另1個只有B工程師可讀寫。但我想，這個管 subversion 的人，該是公司老闆來，還是他美貌的秘書呢!

誰還在用 copy 呀!

曾看過一個網友留言，說道他的小組才3個人而已，用不上 VSS(Visual SourceSafe) 之類的東西，他都是用 copy 的方式與其他人交換程式的。不曉得他這番話的重點是說 VSS 不好用，還是版本控制器不適合小組作業，只能用在大專案上。

從我認識了 cvs 及 subversion 後，就算是只有我自己在開發程式，如果不用版本控制器管理純文字格式文件的話，會覺得十分對不起自己。

想想看，一個程式檔你除了思考程式邏輯外，還要拿一份「記憶體」放置今天的算法與昨天算法在程式碼的差別，喔~饒了我吧!我的腦袋放不了那麼多東西了。

況且有那麼多的 open source 工具協助你，實在沒有理由不用版本控制器。想想看程式/文件寫了3個月後，你忽然覺得後悔了，想回復3天前放棄的演算法，你要拿出 xxx_070321.tgz、xxx_070322.tgz 出來，一個檔一個檔地找嗎?還是用 Trac + subversion 之類的工具，讓你可以點選
http://ptrac.hoamon.info/changeset/3 ，然後從這找出你想要的算法呢!!

嗨~朋友，我懇求你學一下 subversion 吧!別把你的青春放在這，多一點時間玩 online game 會比較好。

我的另一篇文章： 版本控制系統 svn(subversion)

Trac安裝筆記(上)

2006年在自由軟體的最佳開發人員協助工具領域獲得評審肯定大獎的 Trac 軟體，是一套結合 Wiki 及 Request Ticket 的網頁程式。

wiki 適合來作規格書的共同開發; RT 則適合作程式專案的回饋追蹤。本來以為只有我會把這兩樣東西合在一起使用，正想裝一個 kwiki 及一個 RT 系統時(真巧兩個都是 Perl 寫的)，居然讓我發現這個用 Python 寫的整合系統 Trac ，嘿嘿~世事難料!果然如此。

Trac 官網： http://trac.edgewall.org/ (原 http://trac.edgewall.com/ )
它本來應是一間公司，不過現在改成 .org 的，站上也沒看見任何販賣及商業支援的資訊，應該不會是搞 Python 的，都賺不了錢吧!希望是錢賺太多，不想賺了。

閱讀更多…

版本控制系統：svn(subversion)

不管你是寫程式還是系統設定檔的管理，在在都是一門學門，尤其是你得和其他人一同工作的時候。如果你是把工作完成的程式檔壓縮起來寄給別人的話，那你一定得聽聽什麼是版本控制。

目前市面上，比較有名(而且是open source)的版本控制系統有兩種：cvs及subversion。之前我也是用cvs的，不過在我看了這一篇文章後，我就把cvs丟了。

版本控制系統不外乎要解決的是三個地方的文件(含純文字檔、圖檔等)合併問題，依術語來說就是檔案庫、你的工作複本及別人的工作複本。

檔案庫永遠是文件最後該放置的地方，而你的工作複本一開始是從檔案庫來的，經過你的修改，最後再送回檔案庫中;而別人的工作複本也是一樣是從檔案庫來的，也是經由別人的修改，最後再送回檔案庫中。

而版本控制系統的工作就是在於能合諧地整合你所修改的工作複本及別人修改的工作複本，讓他們能在送進檔案庫時不會蓋掉任一方的成果。

說到這裡，你一定很心動了吧!畢竟當你只能用copy的方式作版本控制時，經常發生的蓋檔問題絕對讓你到現在還記憶猶新。

所以，請花個30分鐘來看看這一篇文章吧。距離你不寫程式的年紀，應該還有個五~十年的光景，早學早超生呀!

在使用svn時候，有二個觀念是很重要的。

一、詳實的送交註解

一定要詳實地寫上送交註解(commit comment)，不要只是寫：「又更新版本了」、「解決一個bug」…等等之類無用的訊息，應該是「解決$input變數在$_GET ['input']=''時不能賦值的問題」、「給grace--在樣版中的$greeting應該定義為$hello，因為…」…等等之類的訊息。

二、看別人寫的commet

使用者在svn update前應該先查出自已目前的版本號，查目前版本號的方法如下，最大的號碼即為你目前的版本號

# svn status -N -v

然後在svn update後，把原本版本號到最新版本號之間的送交註解看一下。例如：原本你的工作複本版本號為13，當你修改過後要送交之前得作一次svn update，版本號跳為17，那你這時候應該要作一次看comment的指令：

# svn log -r 13:17
或是
# svn log -r 13:17 -v

先看看別人之前改了什麼，然後你自已評估與目前你所修改的程式流程有沒有衝突，例如：別人在16版的時候把$content[_msg]變數改為 $content[_lang]變數，那麼如果你有使用$content[_msg]的話，你就應該先改好手邊的工作複本，再作svn commit。

如果你覺得看comment不夠清楚，那麼直接比較一下程式碼到底有那裡是不同，指令是：

# svn diff -r 16

上面的指令會比較第16版與你手邊已修改但還未送交的版本作比較，如果你只想比較單一檔案的話，指令是：

# svn diff -r 16 iLovePerl.php

直接把檔案名帶進出。

有時候你個人的commit周期太慢了(可能因為一個bug一直抓不出來)，
那你還是要在未上傳檔案庫前，經常地(至少是一天一次)觀看遠端檔案庫的版本情況，
像是你的工作複本到遠端檔案庫之間的送交註解，其指令如下：

# svn log -r BASE:HEAD

這樣才不會與其他人的距離差太遠，否則等你要commit時，才來調整你的程式碼，
這又太慢了。

有時候，在svn所控制的專案中，你有不想作版本控制的檔案，那該這麼作呢!

像是資料庫的設定檔，這個東西，每個程設師在開發狀態時，可能用的都是臨時性的資料庫，一個人一種設定，如果每一次commit或update後都把別人用的或是自己用的給重設了，
那是件很麻煩的事，所以呢，我們使用svn:ignore性質來解救我們，方法如下，後來的Config代表的是一個資料夾，是你所想忽略的檔案所在的那一個資料夾，如果你想忽略的檔案是在現在的目錄中，那就把 Config 換成 .

# svn propedit svn:ignore Config

然後它會進入stdin的模式，你直接打檔名進去即可，像是

# svn propedit svn:ignore Config
DB.config

然後按下 Ctrl+D即可。請記住DB.config是在Config資料夾中的檔案喔，而且DB.config檔不應該送進svn add中喔

=== 後記 ===

現在我已經改用 Mercurial/Hg(http://hoamon.blogspot.com/2009/03/from-subversion-to-mercurial.html) 了，最大的優點是可離線操作，不像 svn 如果沒有中央伺服器，有些工作就沒辦法作了。