2009/09/11

利用 Gmail 作好個人版本控制 Personal Revision Control

這一篇文章是我投稿到ZDNet的《用Gmail作個人化版本控制》的原文,再加上我打算回答讀者問題的修正版。

如果你和我一樣:
  1. 是初學的Blog Programmer
  2. 有持續修改小程式(如:Blog Template XML檔)的需要
  3. 習慣使用Gmail

只要你符合以上的條件,那我會建議你看這篇文章。因為,看完這篇文章將有助於你作好個人程式的版本控制。

什麼是軟體「版本控制」?


在Wiki內有針對版本控制的介紹,但我們在這僅介紹軟體的版本控制:
軟體設計師常會利用版本控制來追蹤、維護源碼、文件以及設定檔等等的更動,並且提供控制這些更動控制權的程序。

有時候,一個程式同時存有兩個以上的版本也有其必要性,例如:在一個為了部署的版本中程式錯誤已經被修正、但沒有加入新功能;在另一個開發版本則有新的功能正在開發、也有新的錯誤待解決,這使得同時間需要不同的版本並修改。

此外,為了找出只存在於某一特定版本中(為了修正了某些問題、或新加功能所導致)的程式錯誤、或找出程式錯誤出現的版本,軟體除錯者也必須藉由比對不同版本的程式碼以找出問題的位置。


從上述的敘述中,我們可以歸納出使用版本控制管理程式碼的最主要優點:
  1. 允許多人協作開發、
  2. 允許多種版本同時存在、
  3. 了解各個版本彼此之間的差異。

為什麼我需要「版本控制」來管理程式碼?


從上文看來對單人維護的Blog而言,你或許不需要「同時有多人協作開發」,但你仍會需要版本控制管理程式碼的其他優點:允許多種版本同時存在、了解各個版本彼此之間的差異。

假設,你每次對Blog作的修正都是對的,但如果你永遠只保留一個版本,那你就無法回復到以前的版本。這是「允許多種版本同時存在」的優點。

更何況,你不能保證每次對Blog作的修正都是對的,有時候你根本可能忘記了曾經作過的這些修正、或只是要試一下這次的修正結果如何,因為你沒有保留過去任一版本的檔案,所以你也無從比對新舊版本之間的差異與變化,藉以找出可能修改錯誤的地方。這是「了解各個版本彼此之間的差異」的優點。

儲存證據


是另一個需要版本控制的原因。

網路上喜歡亂貼別人文章的人太多了,所以我每發一篇文章,就會相對應地在 Gmail 內貼上一個文章的文字檔寄給自己,這樣未來如果上了法庭,我就可以主張這篇文章的著作權。

換句話說,亂貼我文章的人請小心了,我是少數有能力提出文章所有人的證據的人。我只是不想提出告訴,但不是提不出證據。

以修改 CSS 為例


Firefox 和 IE 的不同版本,各支援不同的 CSS Filter,例如:Firefox 的3.0.10 版只支援 CSS 2.1,但Firefox的測試版 3.5 Beta4 卻能支援到 CSS 3.0,所以有某些的功能是只能在 3.5 Beta4 上才能看到的;另外,即使是相同的CSS版本,Firefox 和 IE的解釋也不同。

換句話說,即使你的CSS正確,到了不同的瀏覽器中卻很有可能看到不同的樣子。為此,你可能得來回修正多次後,才能決定最後的版本。

以我的經驗為例


為了寫「加速你的Blog」系列的文章,我在文章內所提出的任何一個方法,都是經過自己實際測試的過程。為了測試這些修正,我必須重覆修正程式、上傳程式的動作,以確認這些方法都是有效的。

我之所以能在修改錯了之後,能立即回復到最後一個能正常運作的版本,甚至能比對這次(改壞的)版本與上個正常版本之間的差異,就在於我保留了過去的所有版本。但其實都得歸功於Gmail的特殊功能:「會話群組檢視(Conversation View)」
新的信件呈現方式─「會話群組檢視(Conversation View)」:一來一往間(寄出、回覆、轉寄)的相關信件、相同主題的信件會被群組成同一個「Conversation」,於同一個頁面依時間順序展示,便於相互關照。

善用這個功能,就能把相同主題的信件全歸到一個群組中,再加上每封信的內容都不可以再變更,這個特性幾乎就是版本控制軟體的雛型。

要如何使用 Gmail 作版本控制?


方法其實很簡單。在第一個版本,你只要寫一封信給自己:
  1. 「主旨」是「軟體的名稱」(你可以想像成專案名稱)如:XXXX;
  2. 「內文」可以寫「這是XXXX的第一個版本」
  3. 「附件」上傳這個版本的的檔案
以後的版本,你只要以這個群組/主旨回覆:
  1. 「內文」可以寫XXXX在這個最新版本所作的變動/修正
  2. 「附件」上傳這個檔案的最新版本

另外,我建議還可以在程式內,也加入相對應的記註,如
  1. 在CSS內加入/* 記註內容 */ ,或是
  2. 在JavaScript內每行尾// 記註內容
透過這樣的註記,程式的變動就能呼應內文寫下的修正。

更嚴謹的作法


你得在「內容」填入「發佈(版本)通知(Release Notes)」的內容,但我以「個人觀點」的使用經驗來看,我會建議你至少也得條列出:
  1. 新版功能(What's New in XXX)
  2. 已修正的問題(Bug Fixed)
  3. 已知問題(Known Issues)

這樣你寫的內容,未來才具有參考的價值,尤其是在過了好幾個月之後你還能記得過去的修正記錄。


使用Gmail作版本控制的缺點?


正如wiki 版本控制所言:
軟體設計師可以自己保留一個程式的許多不同版本,並且為它們做適當的編號。這種簡單的方法已被用在很多大型的軟體專案中。這是一個可以達到目的的方法,但不夠有效率。除了得同時維護很多幾乎一樣的程式碼備份外;而且極度依賴軟體設計師的自我修養與開發紀律,但這卻常是導致錯誤發生的原因。
這下子,你知道最需要改變的其實是自己的習慣。

但我保證,一旦你熟悉了版本控制的方式,並享受過這個方式所帶來的便利後,你會對版本控制愛不釋手的。

另外,Gmail的單一檔案上限是25Mb,但對一般的個人使用者而言,這個容量應該已經足夠了。

但我還是要提醒大家,如果你很介意Gmail會不會把你的資料搞丟,那你還是把它放到自己的電腦內,但我個人認為就發生中毒、當機、硬碟故障的機率而言,放在Gmail內遠比放在你的電腦內安全。

Q&A


  • Q:不一定要用Gmail,任何一種信箱(hotmail、Yahoo! mail、甚至公司的mail)皆可,只要每封信的主旨固定為軟體名稱加版本,然後按照主旨排序就好了。
    A: 使用其他的Mail當然也可以,只是少了「會話群組檢視(Conversation View)」功能的信件,會讓你到了進到四、五十版之後,看得頭暈眼花。從上面的圖來看,你真的會頭暈眼花。
  • Q:即然都想做版本控制了,為什麼不把完整的機制建立起來,竟然還用這麼爛的方式?
    A:有人說「何必為了喝牛奶養一頭牛?」是的!為了文章開頭所說的少量修正需求,就大費周張地架了一個SVN、CVS Service,就我來看未免小題大作。而且Gmail是免費的,到那連線都可以用。以這個角度來看,絕對會比我自己架個Server,又得處理連線、防火牆、...之類的鎖事來得省事。
  • Q:這文章是有點牽強,雖然也算是一種版本控管,但是不夠嚴謹。
    A:你如果當過填格子、賣字的作家,你就會知道光是要想出一個夠吸引讀者的題裁,就是很不容易的事了。另外,我的需求是只要我能找到之前儲存的版本就夠了,至於要更嚴謹?我想就我的使用需求、和我要付出的代價相比,我真的不覺得有那個必要。

沒有留言:

張貼留言