Subversion是什么？

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

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

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

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

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

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

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

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

二、全局性的版本編號

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

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

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

三、目錄的版本控制

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

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

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

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

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

四、原子性提交

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

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

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

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