subversion

Subversion(簡稱SVN)是近年來崛起的版本管理軟件系統，是CVS的接班人。目前，絕大多數開源軟件都使用SVN作為代碼版本管理軟件。

Subversion是一個版本控制系統，相對於的RCS、CVS，採用了分支管理系統，它的設計目標就是取代CVS。互聯網上免費的版本控制服務多基於Subversion。 ^[1] 

Subversion的版本庫可以通過網絡訪問，從而使用户可以在不同的電腦上進行操作。從某種程度上來説，允許用户在各自的空間裏修改和管理同一組數據可以促進團隊協作。因為修改不再是單線進行（單線進行也就是必須一個一個進行），開發進度會進展迅速。此外，由於所有的工作都已版本化，也就不必擔心由於錯誤的更改而影響軟件質量—如果出現不正確的更改，只要撤銷那一次更改操作即可。某些版本控制系統本身也是軟件配置管理系統（SCM），這種系統經過精巧的設計，專門用來管理源代碼樹，並且具備許多與軟件開發有關的特性——比如對編程語言的支持或者提供程序構建工具。不過Subversion並不是這樣的系統，它是一個通用系統，可以管理任何類型的文件集。

早在2000年，CollabNet就開始尋找CVS替代產品的開發人員。CollabNet提供了一個名為CollabNet企業版（CEE）的協作軟件套件。這個軟件套件的一個組成部分就是版本控制系統。儘管CEE在最初採用了CVS作為其版本控制系統，但是CVS的侷限性從一開始就很明顯，CollabNet知道遲早要找到一個更好的替代品。遺憾的是，CVS已經成為開源世界事實上的標準，很大程度上是因為沒有更好的替代品，至少是沒有可以自由使用的替代品，所以CollabNet決定從頭編寫一個新的版本控制系統，這個系統保留CVS的基本思想，但是要修正其中錯誤和不合理的特性。

2000年2月，他們聯繫到OpenSource Development with CVS(Coriolis,1999)的作者Karl Fogel，並且詢問他是否希望為這個新項目工作。巧合的是，當時Karl正在與朋友Jim Blandy討論設計一個新的版本控制系統，1995年時，他們兩人曾經開辦了一個提供CVS支持的公司CyclicSoftware，儘管他們最終賣掉了公司，但還是天天使用CVS進行日常工作。使用CVS時的挫折促使Jim認真的思考如何管理版本化的數據，並且他當時不僅使用了“Subversion”這個名字，並且已經完成了Subversion版本庫的最初設計，所以當CollabNet提出邀請的時候，Karl馬上同意為這個項目工作，同時Jim也找到了他的僱主（RedHat軟件公司）允許他到這個項目工作，並且沒有限定最終的期限。CollabNet僱傭了Karl和BenCollinsSussman，詳細設計工作從三月開始，在Behlendorf、CollabNet、JasonRobbins和GregStein（當時是一個獨立開發者，活躍在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或其他人的授權。

2023年1月24日消息，微軟 GitHub 近日發佈博客稱，將於 2024 年 1 月 8 日停止支持版本控制系統 Subversion。 ^[6] 

CVS是最基本的版本控制系統。Subversion包含了CVS的大部分功能，並且針對有些功能還稍加改進。

Subversion將目錄名以版本號的形式體現。

無論複製、刪除還是重命名，都會被打上版本號，儘管這聽上去有些奇怪。

Subversion允許任何元數據附加在文件或目錄中。這些屬性是鍵/值對，並且被版本化。Subversion也提供對修訂版附加任何鍵/值屬性的方法，這些屬性不會被版本化，因為他們會自動將元數據附加到版本空間中，但他們可以隨時被更改。

Subversion 1.5開始加入了混合追蹤功能。

支持文件鎖定，當多個用户試圖編輯同一個文件時會收到警告。

·Apache網絡服務的支持，基於WebDAV/DeltaV協議

使用基於HTTP的WebDAV/DeltaV協議進行網絡通信，而Apache網絡服務器提供網絡存儲的站點服務。

當一個文件是可執行的時候，Subversion會提示，並且當這個可執行的文件被放在版本控制中時，Subversion會防止該程序檢查其他目錄。

Subversion可以運行在獨立模式下

Subversion提供一個工具，SVNsync， 用於同步主服務器上的 文件到一個子存儲服務器上，並且標為只讀的屬性

雖然在 2006年 時 Subversion 的使用族羣仍然遠少於傳統的 CVS，但已經有許多開放源碼團體決定將 CVS 轉換為 Subversion。已經轉換使用 Subversion 的包括了 FreeBSD、Apache Software Foundation、KDE、GNOME、GCC、Python、Samba、Mono 以及許多團體。許多開發團隊換用 Subversion 是因為 Trac、SourceForge、CollabNet、CodeBeamer等專案協同作業軟件以及Eclipse、NetBeans等IDE提供 Subversion的資源整合。 除此之外，一些自由軟件開發的協作網如SourceForge.net除了提供 CVS 外，現在也提供專案開發者使用 Subversion 作為源碼管理系統， JavaForge、Google Code以及 BountySource則以 Subversion 作為官方的源碼管理系統。 ^[1] 

2009年，絕大多數CVS服務已經改用SVN。CVS已經停止維護。

Subversion的客户端有兩類，一類是WebSVN等基於Web的，一種是以TortoiseSVN為代表的客户端軟件。前者需要Web服務器的支持，後者需要用户在本地安裝客户端，兩種都有免費開源軟件供使用。

Subversion支持Linux和Windows，更多是安裝在Linux下。

SVN服務器有2種運行方式：獨立服務器和藉助Apache。2種方式各有利弊。

SVN存儲版本數據也有2種方式：Berkeley DB和FSFS。因為Berkeley DB方式在服務器中斷時，有可能鎖住數據，所以還是FSFS方式更安全一點。

在SVN之前，CVS（Concurrent Version System：協同版本控制系統）是使用最廣泛的版本管理軟件，服務器上保存所有的開發項目，開發者們通過服務器上的共享目錄，共同開發同一個項目，達到追蹤所有的工作進度，而服務器上也會保存歷史版本信息，以方便開發者排錯。

SVN與CVS對比的優點如下：

* 統一的版本號。CVS是對每個文件順序編排版本號，在某一時間各文件的版

本號各不相同。而Subversion下，任何一次提交都會對所有文件增加到同一個新版本號，即使是提交併不涉及的文件。所以，各文件在某任意時間的版本號是相同的。版本號相同的文件構成軟件的一個版本。

* 原子提交。一次提交不管是單個還是多個文件，都是作為一個整體提交的。在這當中發生的意外例如傳輸中斷，不會引起數據庫的不完整和數據損壞。

* 重命名、複製、刪除文件等動作都保存在版本歷史記錄當中。

* 對於二進制文件，使用了節省空間的保存方法（簡單的理解，就是隻保存和上一版本不同之處）。

* 目錄也有版本歷史。整個目錄樹可以被移動或者複製，操作很簡單，而且能夠保留全部版本記錄。

* 分支的開銷非常小。

* 優化過的數據庫訪問，使得一些操作不必訪問數據庫就可以做到，這樣減少了很多不必要的和數據庫主機之間的網絡流量。 ^[1] 

只能設置目錄的訪問權限，無法設置單個文件的訪問權限。

若用户有設置單個文件的訪問權限的需求，國內有單位可提供基於開源Subversion的擴展版本，見參考資料。

另外，Subversion的官方版本不支持NTFS文件系統的擴展屬性，NTFS的擴充屬性(安全屬性、附加數據流(可選數據流)、加密數據流等)在提交、檢出、導入、導出等操作過程中會丟失。

現在國內有提供支持NTFS擴展屬性的擴充版Subversion、tSVN， 即NTFS的擴充屬性(安全屬性、附加數據流(可選數據流)、加密數據流等)可和文件一起被提交、檢出、導入、導出。見參考資料。

Subversion Multisite

對於企業級應用，Subversion還有其先天不足，比如對於多個地點的並行開發。目前Subversion multisite，實現異地對等服務器自動同步，支持並行開發以及異地備份。

基於Subversion的ALM平台——UberSVN

ALM(Application Lifecycle Management)是軟件配置管理的未來趨勢，各種軟件版本工具包括Subversion都要集成到其中。目前UberSVN是唯一的以Subversion為基礎構建的ALM平台，並實現了協同開發以及社交化編碼。

是客户端還是服務器

Subversion代表的是代碼版本管理的一種標準，沒有嚴格區分其到底是服務器還是客户端，同樣提供二者的功能。

Subversion支持：

版本化的目錄

CVS只能跟蹤單個文件的變更歷史，但是Subversion實現的“虛擬”版本化文件系統則可以跟蹤目錄樹的變更。在Subversion中，文件和目錄都是版本化的。

真實的版本歷史

由於只能跟蹤單個文件的變更，CVS無法支持如文件拷貝和改名這些常見的操作——這些操作改變了目錄的內容。同樣，在CVS中，一個目錄下的文件只要名字相同即擁有相同的歷史，即使這些同名文件在歷史上毫無關係。而在Subversion中，可以對文件或目錄進行增加、拷貝和改名操作，也解決了同名而無關的文件之間的歷史聯繫問題。

原子提交

一系列相關的更改，要麼全部提交到版本庫，要麼一個也不提交。這樣用户就可以將相關的更改組成一個邏輯整體，防止出現只有部分修改提交到版本庫的情況。

版本化的元數據

每一個文件和目錄都有自己的一組屬性——鍵和值，可以根據需要建立並存儲任何鍵/值對。與文件本身的內容一樣，屬性也在版本控制之下。

可選的網絡層

Subversion在版本庫訪問的實現上具有較高的抽象程度，利於人們實現新的網絡訪問機制。Subversion可以作為一個擴展模塊嵌入到Apache之中，這種方式在穩定性和交互性方面有很大的優勢，可以直接使用服務器的成熟技術——認證、授權和傳輸壓縮等。此外，Subversion自身也實現了一個輕型的、可獨立運行的服務器軟件，這個服務器使用了一個自定義協議，可以輕鬆地使用SSH封裝。

一致的數據操作

Subversion用一個二進制差異算法描述文件的變化，對於文本（可讀）和二進制（不可讀）文件其操作方式是一致的，兩種類型的文件壓縮存儲在版本庫中，而差異信息則在網絡上雙向傳遞。

高效的分支和標籤操作

在Subversion中，分支與標籤操作的開銷與工程的大小無關。Subversion的分支和標籤操作只是一種類似於硬鏈接的機制拷貝整個工程，因而這些操作通常只會花費很少且相對固定的時間。

可修改性

Subversion沒有歷史負擔，它以一系列優質的共享C程序庫的方式實現，具有定義良好的API，這使得Subversion非常容易維護，和其它語言的互操作性很強。

Subversion設計總體上的“俯視圖”。圖中的一端是保存所有版本數據的Subversion版本庫，另一端是Subvesion的客户程序，管理着所有版本數據的本地映射（稱為“工作拷貝”），在這兩極之間是各種各樣的版本庫訪問（RA）層，某些使用電腦網絡通過網絡服務器訪問版本庫，某些則繞過網絡服務器直接訪問版本庫。

安裝好的Subversion由幾個部分組成，下面將簡單的介紹一下這些組件。下文的描述或許過於簡略，不易理解，但不用擔心，本書後面的章節中會用更多的內容來詳細闡述這些組件。

命令行客户端程序。

SVNversion

此工具用來顯示工作拷貝的狀態（用術語來説，就是當前項目的修訂版本）。

SVNlook

直接查看Subversion版本庫的工具。

SVNadmin

建立、調整和修復Subversion版本庫的工具。

SVNdumpfilter

過濾Subversion版本庫轉儲數據流的工具。

mod_dav_SVN

ApacheHTTP服務器的一個插件，使版本庫可以通過網絡訪問。

SVNserve

一個單獨運行的服務器程序，可以作為守護進程或由SSH調用，這是另一種使版本庫，可以通過網絡訪問的方式。

SVNsync

一個通過網絡增加鏡像版本庫的程序。

先為那些不熟悉版本控制技術的入門者提供一個簡單扼要、非系統的介紹，這裏將從版本控制的基本概念開始，隨後闡述Subversion的獨特理念，並演示一些使用Subversion的例子。

下面以分享程序源代碼作為例子，但是記住Subversion可以管理任何類型的文件集——它並非是程序員專用的。

一個典型的客户/服務器系統

Subversion是一個“集中式”的信息共享系統。版本庫是Subversion的核心部分，是數據的中央倉庫。版本庫以典型的文件和目錄結構形式的文件系統樹來保存信息。任意數量的客户端連接到Subversion版本庫，讀取、修改這些文件。客户端通過寫數據將信息分享給其他人，通過讀取數據獲取別人共享的信息。圖“一個典型的客户/服務器系統”展示了這種系統：

Subversion聽起來跟一般的文件服務器沒什麼不同。事實上，Subversion的版本庫的確是一種文件服務器，但不是“一般”的文件服務器。Subversion版本庫的特別之處在於，它會記錄每一次改變：每個文件的改變，甚至是目錄樹本身的改變，例如文件和目錄的添加、刪除和重新組織。

一般情況下，客户端從版本庫中獲取的數據是文件系統樹中的最新數據，但是客户端也具備查看文件系統樹以前任何一個狀態的能力。舉個例子，客户端有時會對一些歷史性問題感興趣，比如“上星期三時的目錄結構是什麼樣的？”或者“誰最後一個修改了這個文件，都修改了什麼？”這些都是版本控制系統的核心問題（設計用來記錄和跟蹤數據變化的系統）。

版本控制系統的核心任務是實現協作編輯和數據共享。但是不同的系統使用不同的策略實現這個目的。有理由去理解這些策略的區別，首先，如果遇到了其他類似Subversion的系統，可以幫助比較現有的版本控制系統；此外，可以幫助更有效的使用Subversion，因為Subversion本身支持不同的工作方式。

所有的版本控制系統都需要解決這樣一個基礎問題：怎樣讓系統允許用户共享信息，而不會讓他們因意外而互相干擾？在版本庫裏意外覆蓋別人的更改非常容易。

考慮“需要避免的問題”的情景，有兩個共同工作者，Harry和Sally，他們想同時編輯版本庫裏的同一個文件，如果首先Harry保存它的修改，過了一會，Sally可能湊巧用自己的版本覆蓋了這些文件，Harry的更改不會永遠消失（因為系統記錄了每次修改），但Harry所有的修改不會出現在Sally新版本的文件中，所以Harry的工作還是丟失了，至少是從最新的版本中丟失了，而且可能是意外的，這是要明確避免的情況！

許多版本控制系統使用鎖定-修改-解鎖機制解決這種問題，在這樣的模型裏，在一個時間段裏版本庫的一個文件只允許被一個人修改。首先在修改之前，Harry要“鎖定”

住這個文件，鎖定很像是從圖書館借一本書，如果Harry鎖住這個文件，Sally不能做任何修改，如果Sally想請求得到一個鎖，版本庫會拒絕這個請求。在Harry結束編輯並且放開這個鎖之前，她只可以閲讀文件。Harry解鎖後，就要換班了，Sally得到自己的輪換位置，鎖定並且開始編輯這個文件。圖1.3“鎖定-修改-解鎖方案”描述了這樣的解決方案。

鎖定-修改-解鎖模型有一點問題就是限制太多，經常會成為用户的障礙：

1.鎖定可能導致管理問題。有時候Harry會鎖住文件然後忘了此事，這就是説Sally一直等待解鎖來編輯這些文件，她在這裏僵住了。然後Harry去旅行了，現在Sally只好去找管理員放開鎖，這種情況會導致不必要的耽擱和時間浪費。

2.鎖定可能導致不必要的線性化開發。如果Harry編輯一個文件的開始，Sally想編輯同一個文件的結尾，這種修改不會衝突，設想修改可以正確的合併到一起，他們可以輕鬆的並行工作而沒有太多的壞處，沒有必要讓他們輪流工作。

3.鎖定可能導致錯誤的安全狀態。假設Harry鎖定和編輯一個文件A，同時Sally鎖定並編輯文件B，如果A和B互相依賴，這種變化是必須同時作的，這樣A和B不能正確的工作了，鎖定機制對防止此類問題將無能為力—從而產生了一種處於安全狀態的假相。很容易想象Harry和Sally都以為自己鎖住了文件，而且從一個安全，孤立的情況開始工作，因而沒有儘早發現他們不匹配的修改。鎖定經常成為真正交流的替代品

Subversion、CVS和一些版本控制系統使用拷貝-修改-合併模型，在這種模型裏，每一個客户聯繫項目版本庫建立一個個人工作拷貝—版本庫中文件和目錄的本地映射。用户並行工作，修改各自的工作拷貝，最終，各個私有的拷貝合併在一起，成為最終的版本，這種系統通常可以輔助合併操作，但是最終要靠人工去確定正誤。

下面是一個例子，Harry和Sally為同一個項目各自建立了一個工作拷貝，工作是並行的，修改了同一個文件A，Sally首先保存修改到版本庫，當Harry想去提交修改的時候，版本庫提示文件A已經過期，換句話説，A在他上次更新之後已經更改了，所以當他通過客户端請求合併版本庫和他的工作拷貝之後，碰巧Sally的修改和他的不衝突，所以一旦他把所有的修改集成到一起，他可以將工作拷貝保存到版本庫。

但是如果Sally和Harry的修改交疊了怎麼辦？這種情況叫做衝突，這通常不是個大問題，當Harry告訴他的客户端去合併版本庫的最新修改到自己的工作拷貝時，他的文件A就會處於衝突狀態，他可以看到一對沖突的修改集，並手工的選擇保留一組修改。需要注意的是軟件不能自動的解決衝突，只有人可以理解並作出智能的選擇，一旦Harry手工地解決了衝突——也許需要與Sally討論，它可以安全地把合併的文件保存到版本庫。

拷貝-修改-合併模型感覺有一點混亂，但在實踐中，通常運行的很平穩，用户可以並行的工作，不必等待別人，當工作在同一個文件上時，也很少會有交疊發生，衝突並不頻繁，處理衝突的時間遠比等待解鎖花費的時間少。

最後，一切都要歸結到一條重要的因素：用户交流。當用户交流貧乏，語法和語義的衝突就會增加，沒有系統可以強制用户進行完美的交流，沒有系統可以檢測語義上的衝突，所以沒有任何證據能夠承諾鎖定系統就可以防止衝突，實踐中，鎖定除了約束了生產力，並沒有做什麼事。

鎖定-修改-解鎖模型被認為不利於協作，但有時候鎖定會更好。

拷貝-修改-合併模型假定文件是可以根據上下文合併的，就是版本庫的文件主要是以行為基礎的文本文件（例如程序源代碼）。但對於二進制格式，例如藝術品或聲音，在這種情況下，十分有必要讓用户輪流修改文件，如果沒有線性的訪問，有些人的許多工作就最終要被放棄。

儘管Subversion一直主要是一個拷貝-修改-合併系統，但是它也意識到了需要鎖定一些文件，並且提供這種鎖定機制，這個特性的討論可以見“鎖定”一節。

一兩年前，我工作生涯的一個重要方面發生了變化，那之前我一直只在一台電腦上工作（更確切地説是隻用一塊硬盤），所有工作文件都保存在我的筆記本硬盤裏。如果我要用另外一台桌面電腦，就通過文件共享操作那些文件。

自從去年我買了PowerBook事情就變了，現在我經常轉戰於三台機器：MacPowerBook、Windows筆記本、Ubuntu桌面。這就意味着我得保持多台機器上的東西都是最新的——至少我的工作文件都要保持最新。有了多台桌面電腦，我主要的Email服務從POP轉到了IMAP，這給我帶來巨大的便利——儘管它有時“打打隔”，但我敢説IMAP在我的多台機器上跑得很好（我用Thunderbird做客户端）。

我大部分工作文件都被Subversion管理起來了，每當切換機器時我就提交（commit）工作目錄，再到新機器上更新（update）。一切都同步得好好的，還全面享受了版本管理服務。

不過，也有一些東西同步起來沒我想要的那麼方便。地址簿就很難直接同步，Thunderbird總固執地把它們放到一個特定的地方，Subversion檢查不到。更倒黴的是，地址簿是二進制文件，難以合併（merge），這很煩人，但Thunderbird用文本文件來處理Email，這一點兒挺招人喜歡的，當IMAP打嗝時我也不難處理。另外，與PDA同步也很難纏，最後我還是找到個不賴的辦法把所有聯繫人和日程表信息在三台機器上都同步好了。再者就是news聚合工具，它們之間可以通過OPML共享feeds（至少理論上如此），但不能記錄下哪些我讀過了哪些還沒讀。

文件儘量採用文本格式，這樣做好處很多。我所有寫作都是用XML，要同步寫的東西只需要一個文本編輯器。但圖表就成問題了，我還沒找到一個在所有平台上都能用的東西，不過，搭起多台桌面有一個好處，所有專用於一個系統的軟件我也能用了。

2012年02月21日，Subversion Access control 4.1 引入更為敏捷靈活的授權方式。 ^[2] 

2012年03月09日，Apache Subversion 1.7.4 發佈。 ^[3] 

2012年05月19日，Apache Subversion 1.7.5 發佈。 ^[4] 

2012年08月16日，Apache Subversion 1.7.6 發佈。 ^[5] 

2012年10月09日，Apache Subversion 1.7.7 發佈。 ^[5]