版本控制

工作之前
程式的檔案就是放在一個資料夾
自己修修改改
有時發現這樣的思考架構不對
想要回到前前前一次的版本
只能靠文字編輯器的還原功能來達成

工作之後
一分程式每個人都可能會改到
所以你會想把程式移到大家都可以存取的地方
可能是一台與網路連接且獨立機器
然後大家連到那台機器上存取程式碼

接著你想到要回復程式版本
還要慢慢還原
真是太蠢的方法
如果那台獨立的機器
可以提供記錄版本的功能
以供我們隨時存取各版本
那就是太美妙了

所以版本控制的概念就由此而生
我自己以為他出生的原因
是因為以下兩個需求
1.程式放在大家都可以存取的地方
2.能夠記錄程式的版本, 以備還原或查閱需要

之前公司用Rational ClearCase
現在用Subversion(前身為CVS)
這兩套在操作上與指令意義上略有不同
例如
ClearCase:
執行"Update"下載檔案到本機,  以後要更新本機檔案也是執行"Update". 下載後, 檔案是上鎖住狀態, 且本機的檔案在下載後都是唯讀, 必須再執行"Check-Out"才能將該程式解鎖, 並且將本機檔案變成可讀寫狀態, 進行編寫. 編寫完檔案後, 再將檔案做"Check-In"將檔案上傳到版本控制的Server, 並且上鎖, 從而將本機檔案又恢復成唯讀. 版本控制的Server裡的檔案, 一開始時先上鎖, 且本機的複本檔案是唯讀. 使用者要編寫時, 再執行Check-Out, 可以同時做解鎖與恢復讀寫. 編寫完成後, 再執行Check-In. 同時做上鎖與恢復唯讀.
Subversion:
執行"Check-Out"下載檔案到本機, 以後要更新本機檔案變成執行"Update". 下載後, 檔案是未鎖住狀態, 且本機的檔案在下載後都是可讀寫狀態. 使用者可以直接編寫檔案. 編寫完檔案後, 再將檔案做"Update"將檔案上傳到版本控制的Server. 版本控制的Server裡的檔案從未上鎖, 而本機的複本檔案也從未變成唯讀.

個人認為ClearCase的運作模式較佳
因為一開始強制上鎖
待有修改需要才由個人去解鎖以"借出"做修改
可以確保同一時間, 只有將程式借走的人可以修改該程式
而Subversion沒有強制上鎖
可能會發生你改我也改同一版本的程式
造成後來上程式的人, 會把前一個人修改地方蓋掉的風險.

阿~沒想到題外話說了這麼多
其實我是想要說
最近電腦換成64位元,
很多本來在32位元作業系統上, 安裝與操作都很順利的應用程式,
卻變成坎坷難行....要一直去找他64位元的版本.

阿然後我在eclipse裡用的svn client是Subclipse(有另一個相似的叫Subversive)
在64位元電腦上一直使用失敗
出現"unable to load default svn client"的訊息
Google了一下
應該是出在Subclipse所使用的svn client有問題
推估也是不支援x64吧
這個解決方法是
1.安裝64位元的JavaHL
2.安裝SVNKit

我採用2.去解決
結果沒反應
改採1.去解決
去下載安裝Silk SVN
(我猜他底層也是用JavaHL, 且提供的是64位元版本)
然後把eclipse關掉重開
結果就成功不會有錯誤訊息啦~哈哈

我逛了一下Silk SVN網站
發現他是一家提供SVN Repository的廠商
免費的使用者可以有100MB的空間來放你的程式
如果想要1000MB, 就要付出一個月4.95歐元(約台幣205元)的代價
最大的是10000MB, 一個月足足要19.95歐元(約台幣825元)呢!!