Subversion是什么？

Subversion 是一個自由/開源版本控制系統(tǒng)，它管理文件和目錄可以超越時間。一組文件存放在中心版本庫，這個版本庫很像一個普通的文件服務器，只是它可以記錄每一次文件和目錄的修改，這便使你可以取得數據以前的版本，從而可以檢查所作的更改。從這個方面看，許多人把版本控制系統(tǒng)當作一種“時間機器”。

Subversion 可以通過網絡訪問它的版本庫，從而使用戶可以在不同的電腦上使用。一定程度上可以說，允許用戶在各自的地方修改同一份數據是促進協(xié)作。由于所有的工作都有歷史版本，你不必擔心由于失去某個通道而影響質量，如果存在不正確的改變，只要取消改變。
Subversion的歷史

早在2000 年，CollabNet， Inc. (http://www.collab.net) 開始尋找CVS 替代產品的開發(fā)人員，CollabNet 提供了一個協(xié)作軟件套件CEE (CollabNet Enterprise Edition)，它的一個組件是版本控制系統(tǒng)。盡管CEE 在初始時使用CVS 作為其版本控制系統(tǒng)，但是CVS 的局限性在一開始很明顯，CollabNet 知道遲早要找到一個更好的替代品。遺憾的是，CVS成為了開源世界事實上的標準，因為沒有更好的產品，至少是沒有可以自由使用的。所以CollabNet 決定寫一個新的版本控制系統(tǒng)，建立在CVS 思想之上的，但是修正其錯誤和不合理的特性。

2000 年2 月，他們聯(lián)系Open Source Development with CVS(Coriolis， 1999)的作者Karl Fogel，并且詢問他是否希望為這個新項目工作，巧合的是，當時Karl 正在與朋友Jim Blandy 討論設計一個新的版本控制系統(tǒng)。在1995 年，他們兩個曾經開辦一個提供CVS支持的公司Cyclic Software，盡管他們終賣掉了公司，但還是天天使用CVS 進行日常工作，在使用CVS 時的挫折終促使他們認真地去考慮如何管理標記版本的數據，而且他們當時不僅僅提出了“Subversion”這個名字，并且做出了Subversion 版本庫的基礎設計。所以當CollabNet 提出邀請的時候，Karl 馬上同意為這個項目工作，同時Jim 也得到了他的雇主，RedHat 軟件贊助他到這個項目并提供了一個寬松的時間。CollabNet 雇傭了Karl 和Ben Collins Sussman，詳細的設計從三月開始，在Behlendorf 、CollabNet、Jason Robbins 和 Greg Stein（當時是一個獨立開發(fā)者，活躍在WebDAV/DeltaV 系統(tǒng)規(guī)范階段）的恰當激勵的幫助下，Subversion 很快吸引了許多活躍的開發(fā)者，結果是許多有CVS 經驗的人們很樂于有機會為這個項目做些事情。

初的設計小組固定在簡單的目標上，他們不想在版本控制方法學中開墾處女地，他們只是希望修正CVS，他們決定Subversion 匹配CVS 的特性，保留相同的開發(fā)模型，但不復制CVS 明顯的缺陷。盡管它不需要成為CVS 的繼任者，它也應該與CVS 保持足夠的相似性，使得CVS 用戶可以輕松的做出轉換。經過14 個月的編碼，2001 年8 月31 日，Subversion 自己能夠“成為服務”了，開發(fā)者停止使用CVS 保存Subversion 的代碼，而使用Subversion 本身。

當CollabNet 開始這個項目的時候，曾經資助了大量的工作（它為全職的Subversion 開發(fā)者提供薪水），Subversion 像許多開源項目一樣，被一些激勵知識界精英的寬松透明的規(guī)則支配著。CollabNet 的版權許可證完全符合Debian 的自由軟件方針，也是說，任何人可以自由的下載，修改和重新發(fā)布，不需要經過CollabNet 或其他人的允許。
功能性對比

一、Subversion包含絕大部分CVS功能

Subversion 作為CVS 的重寫版和改進版，其目標是作為一個更好的版本控制軟件，取代目前流行的CVS。Subversion 的主要開發(fā)人員都是業(yè)界知名的CVS 專家。Subversion支持絕大部分的CVS 功能/命令；Subversion 的命令風格和界面也與CVS 非常接近。當然，不同的地方正是對CVS 的改進。

二、全局性的版本編號

一個新的版本，并得到一個自增量的版本號N+1，該版本號并不針對某個特定的文件，而是全局性的、針對整個版本庫的。因此，我們可以將Subversion 的版本庫看作是一個文件系統(tǒng)或文件目錄樹的數組。

從技術的角度來說，在Subversion 中，“文件foo.c 的第5 版本”這個說法是錯誤的；正確的說法應該是：”文件foo.c 在版本庫被修改了5 次，即執(zhí)行5 次commit 后是什么樣子？”。顯然，在Subversion 中，版本庫被修改5 次后foo.c 的內容，和被修改了6 次后foo.c 的內容很可能完全一樣，因為版本庫的第6 次修改很可能只修改了版本庫的其他部分，而并沒有對foo.c 的進行修改。相反，在CVS 中，文件foo.c 的第1.1 版本和第1.2 版本總是不同的。

Subversion 的全局性版本編號為Subversion 帶來了諸多的優(yōu)勢：如對目錄或文件執(zhí)行拷貝，無論涉及多少文件，Subversion 不需要對單個文件依次執(zhí)行拷貝命令，僅僅需要建立一個指向相應的全局版本號的一個指針即可。

三、目錄的版本控制

CVS 只能對文件進行版本控制，不能對目錄進行版本控制，因此CVS 沒有任何關于文件“移動”（move） 操作的概念。當人為進行文件移動操作時，CVS 只能注意到，一個文件在一個位置被刪除了，而在一個新位置創(chuàng)建了另外一個文件。由于它不會連接兩個操作，因此也很容易使文件歷史軌跡丟失。設置 CVS 存儲庫時，必須非常謹慎地為每個文件選擇準確的位置，因為在設置之后，幾乎要一直使用這個位置了。

同樣由于CVS 不記錄目錄的版本歷史，CVS 不支持對文件的“重命名”（rename），人為的對文件進行重命名會使得命名前后的文件失去歷史聯(lián)系，而記錄歷史本來是版本管理的主要目的。

還有，CVS 不支持對文件的“拷貝”（copy），人為的拷貝對CVS 而言，只能看到新的文件的增加，而不能記錄拷貝源文件和目標文件之間的聯(lián)系。

綜上所述，缺乏對文件“移動”、“重命名”、“拷貝”的支持的根源在于CVS 不能記錄目錄的版本歷史，而這些操作在當前的軟件開發(fā)過程中經常發(fā)生，這正是Subversion被開發(fā)并取代CVS 的主要原因之一。

Subversion 將目錄作為一類特殊的文件來處理（事實上，從文件系統(tǒng)的角度來看，目錄確實是一類特殊的文件，當目錄中的子目錄/文件被刪除、重命名、或新的子目錄/文件被創(chuàng)建時，目錄的內容將發(fā)生改變）。因此，Subversion 象記錄普通文件的修改歷史一樣記錄對目錄的修改歷史，當發(fā)生文件/目錄的移動、重命名或拷貝操作時，Subversion 能夠準確記錄操作前后的歷史聯(lián)系。同樣，象對文件的不同歷史版本進行比較一樣，Subversion支持對目錄的不同歷史版本的比較，清晰展現目錄的變化歷史。

四、原子性提交

從使用者的角度來看，CVS 和Subversion 都支持對多個文件修改的批量提交，但二者在實現方式上存在本質的區(qū)別。

CVS 采用線性、串行的批量提交，即依次地，一個接一個地執(zhí)行提交，每成功提交一個文件，該文件的一個新的版本即被記錄到版本庫中，提交時用戶提供的日志信息被重復地存儲到每一個被修改的文件的版本歷史中。

CVS 串行批量提交模式的弊端在于 － 當任何原因造成批量操作的中斷時（典型原因包括：網絡中斷、客戶端死機等），版本庫往往處于一個不一致的狀態(tài)：原本應該全部入庫的文件只有一部分入庫，很有可能版本庫中的新版本不能順利編譯，更為嚴重的是，隨著其他的用戶執(zhí)行cvs update 操作，該不一致性將迅速在開發(fā)團隊中擴散，從而嚴重影響團隊的開發(fā)效率，并存在質量隱患。另外，假如該批量提交的中斷沒有被及時發(fā)現，開發(fā)團隊往往要花更多的時間進行軟件調試和排錯。

CVS 即使在批量提交不發(fā)生中斷時也會造成不一致：假設用戶A 啟動一個需要較長時間才能完成的批量提交；與此同時，用戶B 執(zhí)行cvs update 操作。此時，用戶B 很有可能得到一個不一致的更新，即用戶B 通過“更新”操作，得到用戶A 的部分修改文件。