一、開發中的實際問題

1.1 備份
1.2 代碼還原
1.3 協同修改
1.4 多版本項目文件管理
1.5 追溯問題代碼的編寫人員及編寫時間
1.6 權限控制

二、簡介

2.1 版本控制

版本控制 [Revision control]，最初來源于工程設計領域，是維護工程藍圖的標準做法，能追蹤工程藍圖從誕生一直到定案的過程。是一種記錄若干文件內容變化，以便將來查閱特定版本修訂情況的系統。

2.2 Subversion

Subversion就是一款實現版本控制的工具軟件，通常也稱作是版本控制器，簡稱SVN。
Subversion是Apache軟件基金會組織下的一個項目。

2.3 Subversion的優良特性

1. 目錄版本控制

   CVS 只能追蹤單個文件的歷史，但是 Subversion 實現了一個“虛擬”文件系統，可以追蹤整個目錄樹的修改，文件和目錄都是版本控制的，結果就是可以在 客戶端對文件和目錄執行移動和復制命令。

2. 原子提交

   提交要么完全進入版本庫，要么一點都沒有，這允許開發者以一個邏輯塊提 交修改。

3. 版本控制的元數據

   每個文件和目錄都有一組附加的“屬性”，你可以發明和保存任意的鍵/值對， 屬性也會像文件內容一樣被納入版本控制。

4. 可選的網絡層

   Subversion 在版本庫訪問方面有一個抽象概念，利于人們去實現新的網絡機 制，Subversion 的“高級”服務器是 Apache網絡服務器的一個模塊，使用 HTTP 的變種協議 WebDAV/DeltaV 通訊，這給了 Subversion 在穩定性和交互性方面很大的好處，可以直接使用服務器的特性，例如認證、授權、傳輸壓縮和版本庫瀏 覽等等。也有一個輕型的，單獨運行的 Subversion服務器，這個服務器使用自 己的協議，可以輕松的用 SSH 封裝。

5. 一致的數據處理

   Subversion 使用二進制文件差異算法展現文件的區別，對于文本(人類可讀)和二進制(人類不可讀)文件具備一致的操作方式，兩種類型的文件都壓縮存放在 版本庫中，差異在網絡上雙向傳遞。

6. 高效的分支和標簽

   分支與標簽的代價不與工程的大小成比例，Subversion 建立分支與標簽時只是復制項目，使用了一種類似于硬鏈接的機制，因而這類操作通常只會花費很少 并且相對固定的時間，以及很小的版本庫空間。

2.4 工作原理

采取客戶端/服務器模式——在服務器的版本庫中保存項目文 件的各個版本，所有參與協同開發的程序員在自己本地電腦上保存一個工作副本。

SVN支持程序員將本地副本更新到服務器端的最新版本，也支持將本地副本的最新改變更新到服務器端，而且后面的更新不會覆蓋前面的更新，而是作為一個新的版本被保存下來——SVN甚至支持將本地工作副本恢復為服務器端保存的某一個歷史版本。

2.5 SVN基本操作

1. 檢出（checkout）：將一個服務器創建好的項目下載到本地。
2. 更新（update）：將本地文件更新為服務器端的最新版本
3. 提交（commit）：將本地修改提交到服務器端。

三、Subversion的安裝與配置

1. 服務器端程序版本

目前Subversion的最新版本是1.14（筆者現在的時間為2020年9月17日13:54:46）。
我這里使用的是1.8.9版本，大同小異。

2. 下載源碼包

Apache 組織自己維護更新的只是 Subversion的源碼，各個版本的源碼包的下載地址是：http://subversion.apache.org/download/
Subversion源碼是用C語言開發的。

3. 下載二進制安裝包

Subversion在不同平臺下的二進制包是由不同組織構建實現的，Windows平臺下的二進制包實現情況在這個網頁： http://subversion.apache.org/packages.html

4. 安裝

找到安裝文件：

我們雙擊這個文件：







它會在環境變量里面自動創建path：

命令控制臺輸入svn --version查看到信息表示服務端安裝成功了。

5. 配置版本庫

① 為什么要配置版本庫？

Subversion 是將文件數據信息保存到版本庫中進行管理的，為了滿足用戶的不同需求，Subversion 允許用戶對版本庫目錄進行定制。

② 創建目錄

在一個非中文無空格目錄下創建一個文件夾，作為版本庫的根目錄： 例如：E:\Subversion\VersionRepository

③ 創建對應的子目錄

在版本庫根目錄下創建與具體項目對應的子目錄——這樣做的目的是使一個 SVN 服務器能夠同時管理多個項目，而不是為每一個項目搭建一個 SVN服務器——這顯然太浪費資源了。
例如：
E:\Subversion\VersionRepository\AAA
E:\Subversion\VersionRepository\BBB
E:\Subversion\VersionRepository\CCC

④創建版本庫

命令格式：

主命令         子命令        參數1
svnadmin      create       倉庫路徑

例如：svnadmin create E:\Subversion\VersionRepository\LearningSystem

⑤ 版本庫目錄結構

版本庫創建成功后會在指定目錄下產生如下的目錄結構：

其中的conf是存放 版本庫所使用的的配置文件的目錄。
db是存放存儲版本數據的數據庫文件的目錄。
hooks是存放版本庫鉤子程序的目錄。
locks是存儲庫鎖目錄，用來跟蹤庫的訪問者。
format是存儲了一個整數的文件，這個整數代表庫層次結構版本。
README.txt是版本庫自述文件。

6. 啟動服務端程序

SVN 服務器必須處于運行狀態才能響應客戶端請求，幫助我們管理項目文件。 所以我們必須將 SVN 服務器啟動起來。啟動 SVN 服務器有兩種方法，一個是命令 行方式，一個是注冊 Windows 服務。

① 命令行

命令格式：

svnserver -d -r E:\Subversion\VersionRepository

其中-d表示后臺執行，-r表示版本庫根目錄，最后一個表示倉庫的目錄。

驗證服務是否啟動成功：
我們看一下現在的端口：

3690被監聽的時候，就表示服務啟動了。

命令行的缺陷是：只要運行服務器端程序的命令行窗口一關，服務就停止了，很不方便，而且每次開機都要手動啟動。

② 注冊windows服務

將SVN服務端程序注冊為Windows服務，就可以讓SVN服務隨系統一起啟動，克服了命令行方式的不足。

注冊服務用的是windows的sc命令，這個是windows的命令，不是SVN的命令。

命令格式：

sc create 服務名 binpath= "***" start= auto depend= Tcpip
注意：等號的左邊都沒有空格，右邊都有一個空格。

binpath是運行服務所需要的二進制文件路徑以及運行該二進制文件的命令行參數。
start= auto表示自動啟動。
depend= Tcpip表示依賴TCP/IP協議。

binpath：
其中的binpath的組成結構為：

svnserve.exe路徑 參數1 參數2 參數3

---

svnserve.exe路徑：SVN安裝目錄\bin\svnserve.exe
參數1 --service ：表示以服務方式啟動Subversion
參數2 -r：表示版本庫根目錄
參數3 版本庫目錄

關于版本庫的目錄：
單倉庫：指定與具體項目對應的倉庫目錄，例如E:\Subversion\VersionRepository，這樣只能為一個項目服務；
多倉庫：指定版本庫的根目錄，例如E:\Subversion\VersionRepository\LearningSystem，這樣可以為了多個項目服務。

最終命令舉例：

sc create MySVNService binpath= "E:\Subversion\bin\svnserve.exe --service -r E:\Subversion\VersionRepository" start= auto depend= Tcpip

注意：如果提示拒絕訪問，請以管理員身份運行命令控制臺：

運行結果：

我們可以在windows的服務里面看到這項了：

7. 客戶端的使用

① 檢出checkout

• 首先進入自己的工作目錄，例如，E:\Workspaces

• 運行svn checkout命令，命令格式如下：

  svn checkout svn://SVN服務器地址/具體倉庫目錄 保存檢出內容的目錄
  

  例如：svn checkout svn://localhost/LearningSystem Learn
  結果：

• 工作副本

  運行 checkout 命令后進入 MyERP 目錄，看到里面什么都沒有。真的什么都沒有嗎？不是的。檢出命令會在這一目錄下創建一個隱藏目錄.svn，用來保存與服務器交互的重要信息，其中包括從服務器端取回的最新版本信息、文件狀態、更新時間等。SVN正是以此為依據判斷當前目錄中文件的狀態。
  
  所以這個隱藏目錄千 萬不要刪除或修改其中的內容——完全無視它的存在吧。如果服務器端保存的文件可以視為一個“正本”，那么每個開發人員檢出到本地目錄的文件可以視為“副 本”，通常稱為工作副本。

② 提交

• 進入我們的工作空間，并進入我們拷貝下來的目錄：
  

• 我們新建一個文件，比如：test.txt
  

• 我們執行提交命令(在本目錄下)試一下：
  
  說明，一個文件，必須納入版本控制才能可以提交到服務器端！

• 執行svn add命令，將test.txt納入版本控制。
  

• 再次執行svn commit 命令：
  
  這是因為我們沒有這次提交附加任何日志信息，這在團隊開發中是極為不好的習慣！

• 使用-m 參數附加日志信息：
  
  這是因為我們沒有開啟權限。

• 暫時開啟匿名權限
  1.進入對應的版本庫目錄下的conf目錄下
  2.打開svnserve.conf文件
  3.將其中的# anon-access = read改為anno-access = write，也就是去掉#，并且將read改為write。注意一定要頂格寫，不要留空格。
  
  不需要重啟 SVN服務，甚至不需要重新打開命令行窗口。

• 重新執行提交命令
  
  這樣我們就提交成功了。

  其實我們在提交的時候不需要指定具體的文件，這樣就表示提交當前工作副本中。

③ 更新

• 將服務器端的文件檢出到一個新的目錄Learn2，模擬另一個終端：
  

• 我們回到Learn，我們對test.txt做一些修改后提交。
  
  

• 我們進入Learn目錄，執行update命令：
  
  這樣我們就可以在“新的目錄”下看到“舊的目錄”下做的更改了。

• 思考：更新和檢出的相同點和不同點分別是什么？

  相同點： 從服務器端下載最新的內容
  不同點：
  檢出：下載整個項目；
  更新：下載與本地工作副本不同的內容
  檢出：創建.svn目錄，使檢出目錄成為工作副本
  更新：依賴.svn目錄
  檢出：只能操作1次
  更新：可以操作多次

④ 工作副本的幾種狀態

1. 沒有修改，現行版本

   本檔案在工作目錄中沒有被修改，而且自當前版本之后，其他終端也沒有任何該文件的修改被提交到服務器，即當前工作副本的版本和服務器端最新版本是一致 的。對它執行 svn commit 和 svn update都不會發生任何事。

2. 本地修改，現行版本

   這個文件被修改過，但這個修改還沒有提交到服務器，而且自當前版本之后，其 他終端也沒有任何該文件的修改被提交到服務器，所以當前工作副本的版本和服 務器端最新版本仍然是一致的。由于有尚未送交回去的本地修改，所以對它的 svn commit 會成功提交你的修改，而 svn update 則不會作任何事。

3. 沒有修改，倉庫版本

   這個文件沒有修改，但是版本庫中有其他終端提交的修改。此時當前工作副本的 版本比服務器端的版本落后了，我們稱之為“過時”。對當前文件的 svn commit 不 會發生任何事，而 svn update 會讓工作目錄中的文件更新至最新版本。

4. 本地修改，過時版本

   服務器端存在沒有更新到本地的修改，導致當前版本過時。如果這個文件在 本地有未提交的修改，則無法提交，對它執行 svn commit 會產生“out-of-date” 錯誤。 此時應該先嘗試更新本地文件。更新時 SVN 會嘗試將服務器端的更新與本地 文件進行合并，合并的結果有兩種可能：一個是服務器端和本地修改位于文件的 不同位置，合并成功；另一個是服務器端的修改正好和本地修改位于同一個位置， 發生沖突。

⑤ 將工作副本整體回復到某一個歷史版本

• 假設當前版本為12，想要取回版本9
• 執行svn update命令
  格式：svn update --revision 想要取出的版本號
  例如：svn update --revision 1
  運行：
  
• 這里需要注意的是，SVN 版本號并不是對某一個文件進行編號，而是對應整個版本庫總體狀態的一個“快照”，取回某個版本不是取回版本號對應的某個文件， 而是整個項目的一個快照。
  

⑥ 回復某個文件的歷史狀態，同時不涉及其他文件

• 假設想取回test.txt在版本2時的狀態
• 執行svn update 命令