Subversion是一個自由/開源的版本控制系統。也就是說，在Subversion管理下，文件和目錄可以超越時空。也就是Subversion允許你資料恢復到早期版本，或者是檢查資料修改的歷史。正因為如此，許多人將版本控制系統當作一種神奇的「時間機器」。
Subversion的版本庫可以通過網路訪問，從而使用戶可以在不同的電腦上進行操作。從某種程度上來說，允許用戶在各自的空間裡修改和管理同一組資料可以促進團隊協作。因為修改不再是單線進行，開發速度會更快。此外，由於所有的工作都已版本化，也就不必擔心由於錯誤的更改而影響軟體質量—如果出現不正確的更改，只要撤銷那一次更改操作即可。
某些版本控制系統本身也是軟體設定管理(SCM)系統，這種系統經過精巧的設計，專門用來管理原始碼樹，並且具備許多與軟體開發有關的特性—比如，對編程語言的支持，或者提供程序構建工具。不過Subversion並不是這樣的系統。它是一個通用系統，可以管理任何類型的文件集。對你來說，這些文件這可能是原始碼程式—而對別人，則可能是一個貨物清單或者是數字電影。
早在2000年，CollabNet, Inc. (http://www.collab.net)就開始尋找CVS替代產品的開發人員。CollabNet提供了一個名為CollabNet企業版(CEE)的協作軟體套件。這個軟體套件的一個組成部分就是版本控制系統。儘管CEE在最初採用了CVS作為其版本控制系統，但是CVS的局限性從一開始就很明顯，CollabNet知道，遲早要找到一個更好的替代品。遺憾的是，CVS已經成為開源世界事實上的標準，很大程度上是因為沒有更好的替代品，至少是沒有可以自由使用的替代品。所以CollabNet決定從頭編寫一個新的版本控制系統，這個系統保留CVS的基本思想，但是要修正其中錯誤和不合理的特性。
2000年2月，他們聯繫到Open Source Development with CVS(Coriolis, 1999)的作者Karl Fogel，並且詢問他是否希望為這個新項目工作。巧合的是，當時Karl正在與朋友Jim Blandy討論設計一個新的版本控制系統。1995年時，他們兩人曾經開辦了一個提供CVS支持的公司Cyclic Software，儘管他們最終賣掉了公司，但還是天天使用CVS進行日常工作。使用CVS時的挫折促使Jim認真的思考如何管理版本化的資料，並且他當時不僅使用了「Subversion」這個名字，並且已經完成了Subversion版本庫的最初設計。所以當CollabNet提出邀請的時候，Karl馬上同意為這個項目工作，同時Jim也找到了他的僱主—Red Hat軟體公司—允許他到這個項目工作，並且沒有限定最終的期限。CollabNet僱傭了Karl和Ben Collins Sussman，詳細設計工作從三月開始，在Behlendorf 、CollabNet、Jason Robbins和Greg Stein(當時是一個獨立開發者，活躍在WebDAV/DeltaV系統規範制訂工作中)恰到好處的激勵下，Subversion很快吸引了許多活躍的開發者，結果是許多對CVS有過失望經歷的人很樂於為這個項目做些事情。
最初的設計小組設定了簡單的開發目標。他們不想在版本控制方法學中開墾處女地，他們只是希望修正CVS。他們決定Subversion應符合CVS的特性，並保留相同的開發模型，但不再重複CVS的一些顯著缺陷。儘管Subversion並不需要成為CVS的完全替代品，但它應該與CVS保持足夠的相似性，以使CVS用戶可以輕鬆的轉移到Subversion上。
經過14個月的編碼，2001年8月31日，Subversion能夠「自己管理自己」了，開發者停止使用CVS保存Subversion的代碼，而使用Subversion本身。
雖然CollabNet啟動了這個項目，並且一直提供了大量的工作支持(它為一些全職的Subversion開發者提供薪水)，但Subversion像其它許多開放原始碼專案一樣，被鬆散的、透明的規則管理著，這樣的規則激勵著知識界的精英們。CollabNet的版權許可證完全符合Debian的自由軟體方針。也就是說，任何人都可以根據自己的意願自由的下載、修改和重新發佈Subversion，不需要CollabNet或其他人的授權。
在講解Subversion為版本控制領域帶來的特性時，我們會經常通過Subversion對CVS的改進進行說明。如果不熟悉CVS，瞭解所有Subversion的特性會有一定的困難。而如果根本就不熟悉版本控制，你就只有乾瞪眼的份兒了。因此，最好首先閱讀一下第 1 章 基本概念，這一章簡單介紹了一些版本控制的基本思想和概念。
Subversion支持：
- 版本化的目錄
-
CVS只能追蹤單個文件的變更歷史，但是Subversion實現的「虛擬」版本化文件系統則可以追蹤目錄樹的變更。在Subversion中，文件和目錄都是版本化的。
- 真實的版本歷史
-
由於只能追蹤單個文件的變更，CVS無法支持如文件拷貝和改名這些常見的操作—這些操作改變了目錄的內容。同樣，在CVS中，一個目錄下的文件只要名字相同即擁有相同的歷史，即使這些同名文件在歷史上毫無關係。而在Subversion中，可以對文件或目錄進行增加、拷貝和改名操作，也解決了同名而無關的文件之間的歷史聯繫問題。
- 原子提交
-
一系列相關的更改，要麼全部提交到版本庫，要麼一個也不提交。這樣用戶就可以將相關的更改組成一個邏輯整體，防止出現只有部分修改提交到版本庫的情況。
- 版本化的Meta資料
-
每一個文件和目錄都有自己的一組屬性—鍵和它們的值。可以根據需要建立並儲存任何鍵/值對。和文件本身的內容一樣，屬性也在版本控制之下。
- 可選的網路層
-
Subversion在版本庫訪問的實現上具有較高的抽像程度，利於人們實現新的網路訪問機制。Subversion可以作為一個擴展模塊嵌入到Apache之中。這種方式在穩定性和交互性方面有很大的優勢，可以直接使用伺服器的成熟技術—認證、授權和傳輸壓縮等。此外，Subversion自身也實現了一個輕型的，可獨立運行的伺服器軟體。這個伺服器使用了一個自行定義協議，可以輕鬆的用SSH封裝。
- 一致的資料操作
-
Subversion用一個二進制差異算法描述文件的變化，對於文字(可讀)和二進制(不可讀)文件其操作方式是一致的。這兩種類型的文件壓縮儲存在版本庫中，而差異訊息則在網路上雙向傳遞。
- 高效的分支和標籤操作
-
在Subversion中，分支與標籤操作的開銷與工程的大小無關。Subversion的分支和標籤操作用只是一種類似於硬鏈接的機制拷貝整個工程。因而這些操作通常只會花費很少且相對固定的時間。
- 可修改性
-
Subversion沒有歷史負擔，它以一系列優質的共享C程序庫的方式實現，具有定義良好的API。這使得Subversion非常容易維護，和其它語言的互操作性很強。
圖 1 「Subversion 的架構」給出了Subversion設計總體上的「俯視圖」。
圖中的一端是保存所有版本資料的Subversion版本庫，另一端是Subvesion的客戶程序，管理著所有版本資料的本地影射(稱為「工作副本」)，在這兩極之間是各種各樣的版本庫訪問(RA)層，某些使用電腦網路通過網路伺服器訪問版本庫，某些則繞過網路伺服器直接訪問版本庫。
安裝好的Subversion由幾個部分組成，下面將簡單的介紹一下這些組件。下文的描述或許過於簡略，不易理解，但不用擔心—本書後面的章節中會用更多的內容來詳細闡述這些組件。
- svn
-
指令列客戶端程序。
- svnversion
-
此工具用來顯示工作副本的狀態(用術語來說，就是當前項目的修訂版本)。
- svnlook
-
直接查看Subversion版本庫的工具。
- svnadmin
-
建立、調整和修復Subversion版本庫的工具。
- svndumpfilter
-
過濾Subversion版本庫轉儲串流(Streaming)的工具。
- mod_dav_svn
-
Apache HTTP伺服器的一個外掛，使版本庫可以通過網路訪問。
- svnserve
-
一個單獨運行的伺服器程序，可以作為系統服務(daemon)或由SSH調用。這是另一種使版本庫可以通過網路訪問的方式。
- svnsync
-
一個通過網路增量鏡像版本庫的程序。
如果已經正確完成了Subversion的安裝，我們就可以開始我們的學習之旅了。在後面的兩章中，我們將講解如何使用Subversion的客戶端程序svn。