一個版本控制系統最基本的功能就是記錄每次修改的地方，並且可以讓使用者方便地存取各個版本、比較版本差異。更進一步的，是建立一個多人開發的環境，可以
計錄每個人的修改，解決版本衝突的問題。版本衝突問題是指兩個人同時對一個檔案作修改的動作，舉個例子說，現在資料庫裡的版本是A，甲和乙分別把這兩個檔
案拿出來（這個動作通常叫 checkout），在做了一番修改之後，甲先把改變的資料存回去（這個動作通常叫
checkin），這時問題還沒有發生，資料庫的板本被更新成B，但是當乙 checkin 的時候，問題就來了，乙的版本也是從 A
修改而來的，到底該用甲的修改版還是乙的呢？如果硬把甲的修改用乙的版本蓋過去，那甲所花的工夫就全部白費了。最常用的解決辦法是用檔按鎖定的功能，就是
當甲在修改某個檔案的時候，會把檔案加個 lock 的 flag 讓大家知道，這個檔案正在被修改，不要去動它。不過像
CVS等進階的版本控制系統，就算沒有做檔案鎖定的動作，發生版本衝突時，也提功了方便的功能可以把兩個版本 merge起來。
目前有許多商業與開放源碼的版本控制系統. 在開放源碼界, 最早出現的, 大概就是 SCCS, 其後演變成為 RCS.
這兩個都是以個別檔案為基礎來進行版本控制. 後來就有了 CVS 的出現, 它架構在 RCS 之上, 並且可以處理多個檔案的送交
(也就是跟版本控制軟體說, 我有這些檔案更動過了, 請記住這些更動).
RCS（Revision Control System）
這是一個相當相當古老的工具了，雖然現在大家都是用 CVS 來做版本控制的工具但是如果沒有可以使用的 CVS server 那就沒有辦法使用了，RCS
主要是偏個人使用的，沒有像 CVS 有許多強大的功能，也不支援遠端檔案系統的存取。
但是在只需要單純的版本管理功能時，就相當的有用了。建議大家如果在工作站上寫程式，或是寫文件的時後，可以試著用 RCS 來做版本管理的工作，一開始可能會覺得綁手綁腳的，但是用久了，你一定會發現使用版本控制系統真是好處多多！
使用 RCS 相當簡單，只有幾個指令而已，大部份系統都有包含。
簡單的使用方法就是這樣：
建立 RCS 資料庫
先在想要保存的程式碼下的目錄下建立一個叫 RCS 的目錄
mkdir RCS
將檔案登入到RCS 資料庫
ci filename
這時，RCS 會要你輸入 log，就是記錄你對這個版本有什麼說名的地方，簡單說幾句就可以了，當然也可以不打，然後會給你一個初始的版本編號，應該是1.1。你會發現到，原來的檔案不見了，而在
RCS 目錄下多了一個叫做 filename,v 的檔案，那個檔案就是用來記錄 filename 的版本演進史的。
把檔案取出來
檔案不見了，那還有什麼戲唱，能夠放進去的，當然就一定可以拿出來：
最基本的用法是這樣，會取出 filename 的最新版本。
co filename
但是，注意它的屬性，是唯讀的喔，要加上 -l 的參數表示要 lock 才可以做修改的動作，修改完了，再把檔案 checkin 回去就完成了版本更新的動作了，這時的版本編號應該是1.2。
另外，co -r filename可以取出指定的版本，但是其屬性一定是唯讀的。
把修改的檔案存回RCS 資料庫
還是一樣，ci filename，不過可以加上 –u 的參數順便 unlock，如果要繼續編輯的話，要加上 –l ，不然會自動把原來目錄下的檔案刪除。
觀看一個檔案的修改記錄
rlog filename
比較版本的差異
rcsdiff -r[version] filename
大概的使用方法就是這麼簡單，有了基本版本控制系統的概念之後，要使用 CVS、Subversion 等進階的版本控制系統，就相當容易了。
RCS 官方網站
http://www.cs.purdue.edu/homes/trinkle/RCS/
簡介
http://atm.ee.nsysu.edu.tw/~fgtseng/system/rcs.html
The RCS MINI-HOWTO 中譯版
http://olympus.het.brown.edu/doc/HOWTO/zh-html/mini/RCS.html
OHaHa 的 RCS 教學
http://ohaha.ks.edu.tw/rcs_part1.htmCVS（Concurrent Versions System）
CVS是繼RCS等傳統的維護工具之後，新一代的程式開發與維護系統，現在網路上許許多多的 Open Source Project，幾乎都是使用
CVS 來做版本控制的工具，它擁有以下的特色：
?程式碼版本的儲存與維護
?程式碼版本的追蹤回溯
?程式碼版本的分合控制
?支援多人合作開發專案
?程式碼遠端管理維護
?程式碼匿名截取
另外，CVSup 和 CVS 是兩個不一樣的東西，前者大都是方便使用者可以取得與開發者同步程式碼所的工具，它是透過比對 server/client
之間的 source code cvs id table 來判斷那些檔案需要修改，在速度上有很大的優勢。另外還有一項使用 CVSup 的優點是它可以在你的本地機器上複製整個
CVS repository，允許快速的本地使用 cvs 操作，像 log 和 diff。
CVS 是給開發人員用的。不過許多 Open Source Project 都會提供 anonymous CVS，通常只有 read
的權限。給其他使用者取得他們所想要的版本，主要的作用就是把最新開發的程式碼給喜歡新鮮貨的人，讓大家一起來測試，對一個 project
的開發，相當有幫助。
CVS 也不支援檔案更名. 也就是說, 如果我們想要變更某個檔案的名稱, 那麼它以前所累樍的更動與註解就得丟棄. 它也不支援以目錄為單位的變動, 所以要想回復某個時間的目錄內容是不可能的.
CVS 官方網站
CVS 入門 by 臥龍小三
http://linux.tnc.edu.tw/techdoc/cvs/book1.html
CVSup 官方網站
另外，介紹一些好用的GUI的CVS界面
WinCVS：win32環境下的，不過筆者覺得相當難用。
Cervisia：KDE的CVS GUI界面，可以和Konqueror整合，使用上感覺相當親切。
Subversion
一套更好的 CVS! 它同樣也是開放源碼, 而且架構, 命令列程式界面等, 都刻意模仿 CVS, 為的就是要讓習於 CVS 的使用者能夠快速上手.
目錄版本控制
在 CVS 中, 一個目錄是沒有版本歷程的. 假如原本一個名為 doc/ 的目錄, 在經過一段時間之後, 發現它應該要稱為
manual/ 比較恰當, 此時我們只能建立一個新 manual/, 把 doc/ 目錄下的檔案複製過去, 把 manual/ 下的檔案新增至
CVS 系統中, 再把 doc/ 刪除. 而且必須注意的是, 在檔案的複製與刪除的過程當中, 我們也同樣地遺失了這些檔案的歷史歷程.
版本控制最主要的資料就這麼丟掉了!
但是在 Subversion 中, 目錄跟檔案同樣都是納入版本控制之中. 也就是說, 我們可以隨時要求 Subversion 將某個檔案回復到某個時間點的狀態, 也可以對目錄進行更名的動作.
不可分割的送交
在 CVS 中, 雖然我們可同時對複數檔案進行送交, 但是 CVS 並不保證一次的送交是不可分割的. 也就是說,
如果我們同時對三個檔案進行送交, 但是在第二個檔案時發生意外狀況 (例如檔案有衝突, 或是網路斷線), 此時 CVS
系統中會有送來的第一個檔案的更動, 但是沒有第二個與第三個的. CVS 系統裡的檔案就變成一個與我們預期不一致的狀況!
Subversion 的送交就沒有上述的問題. 也就是說, 送交的結果, 不是全都進系統, 就是全都沒有進系統, 不會只有一部份進系統的狀況.
更佳的二進制資料處理
CVS 雖然號稱可以處理二進制的資料 (例如圖形檔, Microsoft Word 檔案), 但是需要使用者特別設定, 而使用者 常常
忘記. 再加上 CVS 會主動更動檔案內容, 如列尾符號與關鍵字展開的功能, 以至於常常在需要將檔案回復至過去的狀況時,
才發現檔案變得無法讀取了. 再者, CVS 的檔案內容差異演算法幾乎無法處理二進制檔案, 以致於在儲存檔案上, 需要耗費大量的空間.
Subversion 對上述問題的處理方法有二. 首先, 它不主動更動檔案內容, 除非使用者加上這樣的設定. 再者,
它使用可適用於文字與二進制資料的內容差異演算法, 在檔案儲存上, 文字與二進制資料都具有相同的優勢. 現在,
不只是文字資料適合置於版本控制系統中, 連二進制資料也可以很方便地放進來.
高效率的分支與標記
我們可以對已納入版本控制系統的檔案進行標記, 也就是賦與它們一個易記的文字, 日後便可以利用這個易記的文字, 將這些檔案回復到某個特定的狀態. 但是 CVS 必須對每一個檔案加上這樣的標記, 檔案愈多, 耗時愈久.
在 Subversion 系統, 標記是以目錄的副本的方式建立的, 而副本是以類似鏈結的方式來建立. 也就是說, 不管牽涉的目錄與檔案有多少, 它所花費的時間都是固定的, 不會因為檔案愈多而耗時愈久.
CVS 最為人所垢病的缺點, 就是它的分支功能相當難以使用. 但是在實際上運用時, 分支功能可以為使用人員增加不少便利.
像是可以藉由使用分支, 將程式碼隔離開來, 讓發展人員可以進行大規模更動的同時, 還能讓維護人員進行維護. 而 Subversion 的分支,
亦是以目錄的副本來實作的, 在觀念上更容易學習, 使用起來也更方便.
Subversion 的缺點
但是 Subversion 亦不全然沒有缺點, 它畢章還是一個剛開始發展的系統, 仍然存在一些不易使用的地方.
檔案保留
我們無法取得 Subversion 檔案的獨佔編輯權. 這是因為 Subversion 的工作模式, 是讓各個工作的人取得工作複本,
各自編輯後, 再於送交時進行合併. 不過有的時候, 我們還是得要先取得檔案的獨佔編輯權, 像是在編輯圖形檔. 此時,
由一個人統一對某個檔案進行編輯, 要比事後合併要簡單地多了.
合併點
當一個專案開始產生分支時, 常常我們得先將目前分支的更動合併至主發展線, 這些被合併的更動, 就稱為合併點. Subversion
並不會記住分支已經採用了哪些合併點, 也就是說, 如果在合併更動之後, 在合併的地方又有了更動, 日後當分支發展完畢,
整個分支的更動需要合併至主發展線時, 由於系統不會記得已採用了哪些更動, 而已合併的地方又更動過, 就會造成同一個更動被合併兩次,
此時後來的更動幾乎可以肯定會造成檔案的衝突, 必須由使用者進行排解. 如果系統能夠記得合併點的話, 已採用的合併點就毋需再採用,
也就可以減少使用者必須手動進行衝突排解的次數.
檔案版本
在 Subversion 中, 版本號碼是整個系統共用的. 這個意思就是說, 如果一個專案的檔案因修改而有版號的更動, 那麼所有檔案的版號都會跟著更動. 這對由 CVS 移轉過來的使用者是最難以接受的, 需要花一點時間習慣.
但是, 在這種全域版號下, 我們無法很簡單地回答這樣的問題: 某個檔案的第一個版本長什麼樣? 在目前最新版的前兩個版本作了什麼更動? 你知道, 有些時候, 我們就是需要像這樣的功能.
I18N, L10N
雖然 Subversion 本身架構支援 Unicode, 不過使用者界面還是使用純英文的環境. 對於多國語言的支援仍有一段路途要走.
結語
以上簡單介紹了 Subversion 與 CVS 的優缺點評比. 雖然 Subversion 才開始發展三年, 直到今年才進入 1.0
版, 但是它所提供的便利性與功能性, 已經凌駕於 CVS 之上. 目前尚有不足的功能, 在活躍的開發團隊的手中, 必定能很快地加上去.
有興趣的讀者現在就趕快加入使用 Subversion 的行列吧!
一個全新的版本控制系統，企圖取代 CVS，提供了比 CVS 更佳的版本管理功能。
Subversion 官方網站
Version Control with Subversion（SvnBook）
中譯版
http://freebsd.sinica.edu.tw/~plasma/svnbook/
http://www.cyberpunk.cn/trans.aspx?id=131
《使用 Subversion 进行版本控制》
http://www.cyberpunk.cn/n123c40.aspx
