版本控制簡介
1.1 版本控制[Revision control]，最初來源於工程設計領域，是維護工程藍圖的標准做法，能追蹤工程藍圖從誕生一直到定案的過程。是一種記錄若干文件內容變化，以便將來查閱特定版本修訂情況的系統。
1.2 Subversion就是一款實現版本控制的工具軟件，通常也稱為版本控制器，簡稱SVN。Subversion是Apache軟件基金會組織下的一個項目。
1.3 Subversion的優良特性
①目錄版本控制
CVS只能追蹤單個文件的歷史，但是Subversion實現了一個“虛擬”文件系統，可以追蹤整個目錄樹的修改，文件和目錄都是版本控制的，結果就是可以在客戶端對文件和目錄執行移動和復制命令。
②原子提交
提交要么完全進入版本庫，要么一點都沒有，這允許開發者以一個邏輯塊提交修改。
③版本控制的元數據
每個文件和目錄都有一組附加的“屬性”，你可以發明和保存任意的鍵/值對，屬性也會像文件內容一樣被納入版本控制。
④可選的網絡層
Subversion在版本庫訪問方面有一個抽象概念，利於人們去實現新的網絡機制，Subversion的“高級”服務器是 Apache 網絡服務器的一個模塊，使用 HTTP 的變種協議 WebDAV/DeltaV 通訊，這給了 Subversion 在穩定性和交互性方面很大的好處，可以直接使用服務器的特性，例如認證、授權、傳輸壓縮和版本庫瀏覽等等。也有一個輕型的，單獨運行的 Subversion 服務器，這個服務器使用自己的協議，可以輕松的用 SSH 封裝。
⑤一致的數據處理
Subversion使用二進制文件差異算法展現文件的區別，對於文本(人類可讀)和二進制(人類不可讀)文件具備一致的操作方式，兩種類型的文件都壓縮存放在版本庫中，差異在網絡上雙向傳遞。
⑥高效的分支和標簽
分支與標簽的代價不與工程的大小成比例，Subversion建立分支與標簽時只是復制項目，使用了一種類似於硬鏈接的機制，因而這類操作通常只會花費很少並且相對固定的時間，以及很小的版本庫空間。
SVN的工作原理：
采取客戶端/服務器模式——在服務器的版本庫中保存項目文件的各個版本，所有參與協同開發的程序員在自己本地電腦上保存一個工作副本。SVN支持程序員將本地副本更新到服務器端的最新版本，也支持將本地副本的最新改變更新到服務器端，而且后面的更新不會覆蓋前面的更新，而是作為一個新的版本被保存下來——SVN甚至支持將本地工作副本恢復為服務器端保存的某一個歷史版本。
1.1 SVN基本操作
①檢出（checkout）：將一個服務器端創建好的項目整個下載到本地，這是到項目組后參與開發的第一步，只需執行一次。
②更新（update）：將本地文件更新為服務器端的最新版本，通常為每天上班時或修改公共文件之前執行一次。
③提交（commit）：將本地修改提交到服務器端。通常每天下班前或每實現一個功能、完成一個模塊時執行一次。
2 Subversion安裝與配置
2.1 安裝服務器端程序
①服務器端程序版本
目前Subversion的最新版本是 1.9.0-alpha2，這是一個測試版。官方網站推薦使用的版本是1.8.9，原話是：The best available version of Apache Subversion is: 1.8.9
②下載源碼包
Apache組織自己維護更新的只是Subversion的源碼，各個版本的源碼包的下載地址是：http://subversion.apache.org/download/
Subversion源碼是使用C語言開發的。
③下載二進制安裝包
Subversion在不同平台下的二進制包是由不同組織構建實現的，Windows平台下的二進制包實現情況如下：
所以，服務器端程序的下載地址可以使用：
http://sourceforge.net/projects/win32svn/files/latest/download
下載到的文件是：Setup-Subversion-1.8.9-1.msi
④雙擊運行Setup-Subversion-1.8.9-1.msi
不整合Apache服務器可以忽略此選項
⑤安裝程序會自動配置Path環境變量
D:\DevInstall\Subversion\bin
所以bin目錄下的可執行文件可以在任意目錄下運行。
⑥驗證是否安裝成功
在命令行輸入：svn --version
看到如下信息就表示服務器端程序安裝成功
2.2 配置版本庫
①為什么要配置版本庫？
Subversion是將文件數據信息保存到版本庫中進行管理的，為了滿足用戶的不同需求，Subversion允許用戶對版本庫目錄進行定制。
②在一個非中文無空格目錄下創建一個文件夾，作為版本庫的根目錄。
例如：D:\DevRepository\Subversion
③在版本庫根目錄下創建與具體項目對應的子目錄——這樣做的目的是使一個SVN服務器能夠同時管理多個項目，而不是為每一個項目搭建一個SVN服務器——這顯然太浪費資源了。
例如：D:\DevRepository\Subversion\CRM
D:\DevRepository\Subversion\ERP
D:\DevRepository\Subversion\OA
④創建版本庫
命令格式
| 主命令 |
子命令 |
參數1 |
| svnadmin |
create |
倉庫路徑 |
| 舉例 |
svnadmin create D:\DevRepository\Subversion\StuSys |
|
⑤版本庫目錄結構
版本庫創建成功后會在指定目錄下產生如下的目錄結構
2.3 啟動服務器端程序
①SVN服務器必須處於運行狀態才能響應客戶端請求，幫助我們管理項目文件。所以我們必須將SVN服務器啟動起來。啟動SVN
服務器有兩種方法，一個是命令行方式，一個是注冊Windows服務。
②命令行方式
[1]命令格式
| 主命令 |
參數1 |
參數2 |
參數3 |
| svnserve |
-d表示后台執行 |
-r表示版本庫根目錄 |
D:\DevRepository\Subversion |
| 舉例 |
svnserve -d -r D:\DevRepository\Subversion |
||
[2]驗證服務是否啟動
SVN服務監聽3690端口，打開一個新的cmd窗口，使用netstat -an 命令查看3690端口是否被監聽
[3]命令行方式的缺陷是：只要運行服務器端程序的命令行窗口一關閉，服務就停止了，很不方便，而且每次開機都需要手動啟動。
③注冊Windows服務
[1]將SVN服務端程序注冊為Windows服務，就可以讓SVN服務隨系統一起啟動，克服了命令行方式的不足。
[2]注冊Windows服務需要利用XP、2000以上系統自帶工具Service Control，執行文件是sc.exe，注意這個命令不是SVN的命令。
[3]命令格式
| 主命令 |
子命令 |
參數1 |
參數2 |
參數3 |
參數4 |
| sc |
create |
服務名 |
binpath= “運行服務所需要的二進制文件路徑以及運行該二進制文件的命令行參數” |
start= auto 表示自動啟動 |
depend= Tcpip 表示依賴Tcpip協議 |
| [注意：在這個命令中，等號左邊都沒有空格，右邊都有一個空格！] |
|||||
[4]binpath組成結構說明
| svnserve.exe路徑 |
svnserve命令參數1 |
svnserve命令參數2 |
svnserve命令參數3 |
| SVN安裝目錄\bin\svnserve.exe |
--service 表示以服務方式啟動Subversion |
-r 表示版本庫根目錄 |
版本庫目錄 |
[5]關於“版本庫目錄”
| 單倉庫 |
指定與具體項目對應的倉庫目錄 |
例如：D:\DevRepository\Subversion\CRM |
只能為一個項目服務 |
| 多倉庫 |
指定版本庫的根目錄 |
例如：D:\DevRepository\Subversion |
可以為多個項目服務 |
[6]最終命令舉例
| sc create MySVNService binpath= "D:\DevInstall\Subversion\bin\svnserve.exe --service -r D:\DevRepository\Subversion" start= auto depend= Tcpip |
-
- ●在Win7及以上系統中，運行該命令需要管理員權限，否則會得到如下錯誤提示
-
- ●解決的辦法是以管理員身份運行cmd命令行窗口即可
-
- ●在防火牆或電腦衛士提示阻止時，選擇允許
-
- ●此時查看當前系統中的服務，可以看到我們剛剛創建的服務，但此時它還沒有啟動，如果創建失敗，需檢查sc命令是否正確
-
- ●啟動此服務
啟動服務的命令格式如下：
| 格式 |
sc start 服務名 |
| 舉例 |
sc start MySVNService |
-
- ●打開命令行窗口運行netstat –an查看3690端口是否被監聽
- ●如果啟動失敗，那很有可能是binpath中的內容有錯誤，此時只能將已經創建的服務刪除，重新創建。
- ●刪除服務之前，最好先停止服務。停止服務的命令格式如下：
| 格式 |
sc stop 服務名 |
| 舉例 |
sc stop MySVNService |
-
- ●刪除服務的命令格式如下：
| 格式 |
sc delete 服務名 |
| 舉例 |
sc delete MySVNService |
-
- ●刪除、啟動、停止服務同樣需要管理員權限
3 使用命令行模式訪問SVN服務器
3.1 檢出
①首先進入自己的工作目錄，例如：D:\DevWorkSpace\SVNSpace
②運行svn checkout命令，命令格式如下
| 格式 |
svn checkout svn://SVN服務器主機地址/具體倉庫目錄 保存檢出內容的目錄 |
| 舉例 |
svn checkout svn://localhost/ERP MyERP |
| 運行結果 |
取出版本 0。 |
③工作副本
運行checkout命令后進入MyERP目錄，看到里面什么都沒有。真的什么都沒有嗎？不是的。檢出命令會在這一目錄下創建一個隱藏目錄.svn，用來保存與服務器交互的重要信息，其中包括從服務器端取回的最新版本信息、文件狀態、更新時間等。SVN正是以此為依據判斷當前目錄中文件的狀態。所以這個隱藏目錄千萬不要刪除或修改其中的內容——完全無視它的存在吧。如果服務器端保存的文件可以視為一個“正本”，那么每個開發人員檢出到本地目錄的文件可以視為“副本”，通常稱為工作副本。
3.2 提交
①進入D:\DevWorkSpace\SVNSpace\MyERP目錄
②創建一個文件test.txt
③執行svn commit命令，運行結果是
| D:\DevWorkSpace\SVNSpace\MyERP>svn commit test.txt svn: E200009: 提交失敗(細節如下): svn: E200009: “D:\DevWorkSpace\SVNSpace\MyERP\test.txt” 尚未納入版本控制 |
說明一個文件必須納入版本控制才可以提交到服務器端。
④執行svn add命令，將test.txt納入版本控制
| D:\DevWorkSpace\SVNSpace\MyERP>svn add test.txt A test.txt |
⑤再次執行svn commit命令
| D:\DevWorkSpace\SVNSpace\MyERP>svn commit test.txt svn: E205007: 提交失敗(細節如下): svn: E205007: 無法使用外部編輯器獲得日志信息；考慮設置環境變量 $SVN_EDITOR，或者使用 --message (-m) 或 --file (-F) 選項 svn: E205007: 沒有設置 SVN_EDITOR，VISUAL 或 EDITOR 環境變量，運行時的配置參數中也沒有 “editor-cmd” 選項 |
此時要求附加日志信息
⑥使用-m參數附加日志信息
| D:\DevWorkSpace\SVNSpace\MyERP>svn commit -m "My first commit" test.txt svn: E170001: 提交失敗(細節如下): svn: E170001: 認證失敗 |
原因是沒有權限
⑦暫時先開啟匿名訪問權限
[1]進入對應的版本庫目錄下的conf目錄：D:\DevRepository\Subversion\ERP\conf
[2]打開svnserve.conf
[3]將第19行的# anon-access = read改為anon-access = write，也就是去掉“# ”，將read改為write。注意前面不要留空格，一定要頂格寫。
[4]不需要重啟SVN服務，甚至命令行窗口都不需要重新打開。
⑧重新執行提交命令
| D:\DevWorkSpace\SVNSpace\MyERP>svn commit -m "My first commit" test.txt 正在增加 test.txt 傳輸文件數據. 提交后的版本為 1。 |
說明提交成功了。
⑨其實svn commit命令最后可以不指定具體文件，此時表示提交當前工作副本中的所有修改。
3.3 更新
①將服務器端文件檢出到一個新的目錄，模擬另外一個終端
| D:\DevWorkSpace\SVNSpace>svn checkout svn://localhost/ERP TomERP A TomERP\test.txt 取出版本 1。 |
②回到MyERP目錄，對test.txt文件修改后提交。
③進入TomERP目錄
④執行svn update命令
| D:\DevWorkSpace\SVNSpace\TomERP>svn update 正在升級 '.': U test.txt 更新到版本 2。 |
這樣我們就可以在TomERP目錄下看到MyERP目錄下提交的修改。
⑤思考：更新和檢出的相同點和不同點分別是什么？
|
|
檢出 |
更新 |
| 相同點 |
從服務器端下載最新內容 |
|
| 不同點1 |
下載整個項目 |
下載與本地工作副本不同的內容 |
| 不同點2 |
創建.svn目錄，使檢出目錄成為工作副本 |
依賴.svn目錄 |
| 不同點3 |
只能操作1次 |
可以操作多次 |
3.4 工作副本中文件的幾種狀態
①沒有修改，現行版本
本檔案在工作目錄中沒有被修改，而且自當前版本之后，其他終端也沒有任何該文件的修改被提交到服務器，即當前工作副本的版本和服務器端最新版本是一致的。對它執行svn commit和svn update都不會發生任何事。
②本地修改, 現行版本
這個文件被修改過，但這個修改還沒有提交到服務器，而且自當前版本之后，其他終端也沒有任何該文件的修改被提交到服務器，所以當前工作副本的版本和服務器端最新版本仍然是一致的。由於有尚未送交回去的本地修改，所以對它的 svn commit會成功提交你的修改，而 svn update 則不會作任何事。
③沒有修改，過時版本
這個文件沒有修改，但是版本庫中有其他終端提交的修改。此時當前工作副本的版本比服務器端的版本落后了，我們稱之為“過時”。對當前文件的 svn commit 不會發生任何事，而 svn update 會讓工作目錄中的文件更新至最新版本。
④本地修改，過時版本
服務器端存在沒有更新到本地的修改，導致當前版本過時。如果這個文件在本地有未提交的修改，則無法提交，對它執行svn commit 會產生“out-of-date”錯誤。
此時應該先嘗試更新本地文件。更新時SVN會嘗試將服務器端的更新與本地文件進行合並，合並的結果有兩種可能：一個是服務器端和本地修改位於文件的不同位置，合並成功；另一個是服務器端的修改正好和本地修改位於同一個位置，發生沖突。
3.5 將工作副本整體回復到某一個歷史版本
①假設當前版本為12，想要取回版本9
②執行svn update命令
| 格式 |
svn update --revision 想要取回的版本號 |
| 舉例 |
svn update --revision 1 |
| 運行結果 |
正在升級 '.': D pp.txt U test.txt 更新到版本 1。 |
③這里需要注意的是，SVN版本號並不是對某一個文件進行編號，而是對應整個版本庫總體狀態的一個“快照”，取回某個版本不是取回版本號對應的某個文件，而是整個項目的一個快照。
3.6 將某個文件恢復到某個版本中的狀態，同時不涉及其他文件
①假設想要取回pp.txt在版本10時的狀態
②執行svn update命令
| 格式 |
svn update 文件名 --revision 想要取回的版本號 |
| 舉例 |
svn update pp.txt –revision 10 |
| 運行結果 |
正在升級 'pp.txt': U pp.txt 更新到版本 10。 |
③綜合這兩個例子，我們可以認為版本號和文件名構成了一個橫縱坐標系，通過文件路徑和版本號定位其在某一個時刻的狀態。
4 單一版本庫權限配置
4.1 匿名訪問：前已述及。
4.2 授權訪問
①要設置授權訪問就需要創建用戶，並為用戶設定權限
②打開授權訪問的配置
[1]打開D:\DevRepository\Subversion\ERP\conf\svnserve.conf
[2]將第19行anon-access = write注釋掉：# anon-access = write
表明該版本庫不接受匿名訪問
[3]將第20行# auth-access = write注釋打開：auth-access = write
表明該版本庫使用授權訪問
[4]將第27行注釋打開：password-db = passwd
表明使用同目錄下的passwd文件保存用戶信息
[5]將第36行注釋打開：authz-db = authz
表明使用同目錄下的authz文件保存權限信息
[6]打開passwd文件創建用戶
| userWrite01 = 123456 userWrite02 = 123456 userRead = 123456 userOther = 123456 |
[7]打開authz文件：#后面注釋的是例子
<1>創建用戶組
| [groups] # harry_and_sally = harry,sally # harry_sally_and_joe = harry,sally,&joe canWrite = userWrite01,userWrite02 |
<2>指定路徑，給用戶和用戶組授權
| # [/foo/bar] # harry = rw # &joe = r # * =屏蔽那些未設定的用戶，讓它們沒有任何權限 [/] @canWrite = rw userRead = r * = |
<3>權限的繼承性：父目錄設置的權限，對子目錄同樣有效——除非子目錄進行了更為具體的設定
| [/subDir] userOther = rw * = |
這個例子表示當前版本庫下的subDir目錄只有userOther有讀寫權限，其它用戶無任何權限
5 多版本庫共享配置
5.1 在版本庫根目錄D:\DevRepository\Subversion下創建commConf目錄
5.2 將未修改的authz和passwd文件拷貝到commConf目錄下
5.3 修改需要設置權限的版本庫的svnserve.conf文件
①password-db = ../../commConf/passwd
②authz-db = ../../commConf/authz
5.4 在password中創建用戶
| [users] # harry = harryssecret # sally = sallyssecret
userERP = 123456 userOA = 123456 userCRM = 123456 |
5.5 在authz中針對不同版本庫為不同用戶授予權限
| # [repository:/baz/fuz] # @harry_and_sally = rw # * = r
[ERP:/] userERP = rw * =
[OA:/] userOA = rw * =
[CRM:/] userCRM = rw * = |
6 查看工作副本信息
①使用svn info命令
②執行效果如下
| D:\DevWorkSpace\SVNSpace\MyCRM>svn info 路徑: . 工作副本根目錄: D:\DevWorkSpace\SVNSpace\MyCRM URL: svn://localhost/CRM 正確的相對 URL: ^/ 版本庫根: svn://localhost/CRM 版本庫 UUID: d5768329-0587-f54a-b44e-72a9a02ddf1b 版本: 12 節點種類: 目錄 調度: 正常 最后修改的作者: userCRM 最后修改的版本: 12 最后修改的時間: 2014-08-08 00:30:38 +0800 (周五, 2014-08-08) |
③對某一個文件使用svn info命令
| D:\DevWorkSpace\SVNSpace\MyCRM\src\com\crm>svn info MyCRM.java 路徑: MyCRM.java 名稱: MyCRM.java 工作副本根目錄: D:\DevWorkSpace\SVNSpace\MyCRM URL: svn://localhost/CRM/src/com/crm/MyCRM.java 正確的相對 URL: ^/src/com/crm/MyCRM.java 版本庫根: svn://localhost/CRM 版本庫 UUID: d5768329-0587-f54a-b44e-72a9a02ddf1b 版本: 14 節點種類: 文件 調度: 正常 最后修改的作者: userCRM 最后修改的版本: 14 最后修改的時間: 2014-08-08 00:36:06 +0800 (周五, 2014-08-08) 文本最后更新: 2014-08-08 00:35:59 +0800 (周五, 2014-08-08) 校驗和: dbea85a617fb59cb739c3d18968a941d32858372 |
7 查看目錄或文件日志信息
①使用svn log命令
[注意：使用這個命令的前提是設置匿名訪問為none，即：anon-access = none，否則會出現“svn: E220001: 條目不可讀”錯誤]
②執行效果如下
| D:\DevWorkSpace\SVNSpace\MyCRM\src\com\crm>svn log MyCRM.java ------------------------------------------------------------------------ r18 | userCRM | 2014-08-08 09:43:00 +0800 (周五, 2014-08-08) | 4 行
aaa bbb ccc ddd ------------------------------------------------------------------------ r17 | userCRM | 2014-08-08 09:36:46 +0800 (周五, 2014-08-08) | 1 行
aaaa\nbbb\ntt ------------------------------------------------------------------------ r16 | userCRM | 2014-08-08 09:30:26 +0800 (周五, 2014-08-08) | 1 行
------------------------------------------------------------------------ r15 | userCRM | 2014-08-08 00:58:30 +0800 (周五, 2014-08-08) | 1 行
------------------------------------------------------------------------ r14 | userCRM | 2014-08-08 00:36:06 +0800 (周五, 2014-08-08) | 1 行
tt ------------------------------------------------------------------------ r13 | userCRM | 2014-08-08 00:33:12 +0800 (周五, 2014-08-08) | 1 行
tt ------------------------------------------------------------------------ r4 | userCRM | 2014-08-07 22:19:16 +0800 (周四, 2014-08-07) | 1 行
------------------------------------------------------------------------ r2 | (沒有作者信息) | 2014-08-05 11:37:29 +0800 (周二, 2014-08-05) | 1 行
tt ------------------------------------------------------------------------ r1 | (沒有作者信息) | 2014-08-05 11:34:40 +0800 (周二, 2014-08-05) | 1 行
tt ------------------------------------------------------------------------ |
8 在Eclipse中安裝SVN客戶端插件
8.1 Eclipse插件應用市場
在Eclipse中訪問Eclipse Marketplace Client可以搜索Subversion，下載插件，按提示安裝即可。
8.2 使用壓縮包
如果不能聯網可以使用下載好的插件壓縮包eclipse_svn_site-1.10.5.zip，這個壓縮包是從http://subclipse.tigris.org/網站（subclipse是這款Eclipse插件的名稱）上下載的。安裝方法是：
①解壓eclipse_svn_site-1.10.5.zip中的features和plugins這兩個目錄
②將features和plugins復制到Eclipse安裝目錄/dropins/eclipse_svn_site-1.10.5下
③重啟Eclipse
④進入Eclipse依次打開Window→Preferences→Team→SVN，看到如下界面即說明SVN插件安裝成功
8.3 創建資源庫位置
①切換到透視圖SVN資源庫研究
②創建資源庫位置
此時可以查看版本庫中的文件及目錄結構
8.4 檢出
①檢出分兩種情況
<1>從服務器端獲取到的是一些零散的文件，不能作為項目檢出
此時會彈出一個新建項目向導，之所以會這樣是因為我們需要創建一個項目來保存從服務器端取回的文件
<2>從服務器端獲取到的是一個完整的項目，例如
此時必須作為項目檢出
項目從服務器檢出后，會成為一個工作副本，根目錄下會自動創建.svn隱藏目錄
8.5 提交
①新創建文件后，文件圖標上會以“?”標識，表示該文件尚未納入版本控制
②在新創建的文件上點右鍵→Team→添加至版本控制，這樣文件圖標上會顯示“+”，表示當前文件已納入版本控制，但還未提交至服務器。
③在要提交的文件上點右鍵→Team→提交...會提交文件，在彈出的對話框中可以不填寫日志。文件提交后，圖標會變為“金色的圓柱體”表示當前文件的版本和服務器端一致。
④文件修改后圖標會變為“*”，表示當前文件或目錄包含未提交的修改。
8.6 更新
①更新整個項目時可以在項目上點右鍵→Team→更新
②更新某個具體的文件時，可以在文件上點右鍵→Team→更新
8.7 共享項目
①在Eclipse中創建的新項目想要發布到SVN服務器端，可以通過“共享”項目實現
②在項目上點右鍵→Team→Share Project...→選擇一種版本控制工具
選擇一個資源庫位置
切換到Team Synchronizing透視圖，選擇項目中要提交的內容，通常是項目中的全部內容
8.8 回復歷史版本
①在需要回復的文件上點右鍵→Team→顯示資源歷史記錄→得到如下界面
②選擇某一個歷史記錄點右鍵→獲取內容。文件就會恢復到指定版本的狀態，同時圖標變為“*”。
③獲取歷史記錄時，如果出現如下錯誤提示
可以通過將對應版本庫中的svnserve.conf文件中的anon-access設置為none解決。
8.9 解決沖突
①什么情況下會發生沖突
<1>兩個開發人員，Harry和Sally，分別從服務器端下載了文件A。
<2>Harry修改之后，A變成了A’，Sally修改之后，A變成了A’’。
<3>Harry先一步提交，使服務器端文件的版本也變成了A’
<4>Sally本地的文件A’’已經過時了，此時她已無法提交文件，服務器會要求她先進行一次更新操作。
<5>此時Sally的更新操作有兩種可能
(1)Sally所做的修改與Harry不是同一個位置，更新操作嘗試合並文件成功。
(2)Sally所做的修改與Harry恰好是同一個位置，更新操作嘗試合並文件失敗，發生沖突。
<6>發生沖突后，本地工作副本會發生如下變化
(1)文件A中的內容發生如下改變
| public static void main(String[] args) { System.out.println("Edit By Command!"); System.out.println("Edit By Command!"); <<<<<<< .mine System.out.println("Edit By Eclipse!"); ======= System.out.println("Edit By Command!New Edit"); >>>>>>> .r14 System.out.println("Edit By Command!"); System.out.println("Edit By Command!"); } |
其中，從<<<<<<< .mine到=======之間是發生沖突時本地副本的內容。從=======到>>>>>>> .r14是發生沖突時服務器端的最新內容。注意這里r后面的數字是發生沖突時服務器端的版本號，有可能是任何整數值，r14只是一個例子。
同時文件圖標變成一個“黃色的！”。
(2)與沖突文件同目錄下新增文件，擴展名為.mine，其內容是發生沖突時本地副本的文件內容。
(3)與沖突文件同目錄下新增文件，擴展名為.r小版本號，例如MyCRM.java.r13，其內容是沖突發生之前，服務器端的文件內容，可以作為解決沖突的參照。
(4)與沖突文件同目錄下新增文件，擴展名為.r大版本號，例如MyCRM.java.r14，其內容是沖突發生時，服務器端的文件內容。
②解決沖突
(1)在沖突文件上點右鍵→Team→編輯沖突...→出現如下界面
以對比的方式將本地內容與沖突內容顯示出來，其中左側為本地內容，右側為沖突內容。其中本地內容是可以修改的。
(2)根據需要和實際情況將本地內容更正——這個過程很可能需要牽涉沖突的兩位開發人員進行必要的溝通——機器與程序目前還不能完全取代人工智能。更正后文件圖標會變成一個“四角形”，同時沖突文件內的<<<<<<< .mine、=======以及>>>>>>> .r14等標記都會被去掉。
(3)在沖突文件上點右鍵→Team→標記為解決
此時.mine文件和.r版本號文件都會被自動刪除，沖突文件的圖標變為“*”，表示可以提交。
(4)提交文件，文件圖標變為“金色圓柱體”。
9 使用SVN獨立客戶端：TortoiseSVN
9.1 TortoiseSVN簡介
TortoiseSVN是一個Windows下的版本控制系統Apache™ Subversion®的客戶端工具。
9.2 TortoiseSVN的優良特性
①外殼集成
TortoiseSVN 無縫地整合進 Windows 的外殼(例如資源管理器)。
②重載圖標
每個版本控制的文件和目錄的狀態使用小的重載圖標表示，可以讓你立刻看出工作副本的狀態。
③圖形用戶界面
當你列出文件或文件夾的更改時，你可以點擊任意版本查看提交注釋。也可以看到更改過的文件列表 - 只要雙擊文件就可以查看更改內容。
提交對話框列出了本次提交將要包括的條目，每一個條目有一個復選框，所以你可以選擇包括哪些條目。未版本控制的文件也會被列出，以防你忘記添加新文件。
④Subversion 命令的簡便訪問
所有的 Subversion 命令存在於資源管理器的右鍵菜單，TortoiseSVN 在那里添加子菜單。
9.3 TortoiseSVN 的歷史
2002年，Tim Kemp 發現 Subversion 是一個非常好的版本管理系統，但是缺乏一個好的圖形界面客戶端程序。做一個與 Windows 外殼整合的 Subversion 客戶端程序的想法是受一個叫 TortoiseCVS 的 CVS客戶端程序所啟發的。Tim 研究了 TortoiseCVS 的源碼並以此為 TortoiseSVN 的基礎。他開始運作這個項目，注冊了域名 tortoisesvn.org 並且將源碼放在了網上。
就在同時， Stefan Küng 正在尋找一個好用的並且免費的版本控制系統。他找到了 Subversion 和TortoiseSVN 的源碼。因為 TortoiseSVN 還不能使用，他加入了項目並開始編碼。很快，他就重寫了現有的大部分代碼並開始添加命令和功能，到了某個時段，最初的代碼已經都被改寫了。
由於 Subversion 變得越來越穩定，它吸引了越來越多用戶，他們同時也開始使用 TortoiseSVN 作為Subversion 的客戶端程序。用戶數量快速增長(並且每天還在增長)。這時候，Lübbe Onken 提出幫助項目提供精美的圖標和 TortoiseSVN 的標志。現在他負責照看網站和管理多語言翻譯。
9.4 TortoiseSVN安裝
①下載安裝程序：http://tortoisesvn.net/downloads.html
②以Win32位為例
9.5 中文語言包安裝
在任意目錄下點右鍵→TortoiseSVN→settings
9.6 檢出
①創建一個目錄用來存放檢出得到的文件，例如MyCRM
②進入目錄MyCRM，點右鍵
③可以看到檢出得到的文件
此時文件圖標上沒有任何標識。可能你會想到通過重啟電腦的方式解決這一問題——其實不用這么麻煩。文件圖標是受外殼程序控制的，我們只需要重啟外殼程序——explorer.exe就可以了。打開任務管理器，選中explorer.exe進程，結束進程，然后新建進程explorer.exe就可以了。
如果一切順利的話，你會看到文件圖標變成了這樣：
④TortoiseSVN圖標含義
-
- ●圖標1： 一個新檢出的工作副本使用綠色的對勾做重載。表示Subversion狀態正常。
- ●圖標2： 在你開始編輯一個文件后，狀態就變成了已修改，而圖標重載變成了紅色感嘆號。通過這種方式，你可以很容易地看出哪些文件從你上次更新工作副本后被修改過，需要被提交。
- ●圖標3： 如果在更新的過程中出現了沖突，圖標會變成黃色感嘆號。
- ●圖標4： 如果你給一個文件設置了svn:needs-lock屬性，Subversion會讓此文件只讀，直到你獲得文件鎖。具有這個重載圖標的文件來表示你必須在編輯之前先得到鎖。
- ●圖標5： 如果你擁有了一個文件的鎖，並且Subversion狀態是正常，這個重載圖標就提醒你如果不使用該文件的話應該釋放鎖，允許別人提交對該文件的修改。
- ●圖標6： 這個圖標表示當前文件夾下的某些文件或文件夾已經被調度從版本控制中刪除，或是該文件夾下某個受版本控制的文件丟失了。
- ●圖標7： 加號告訴你有一個文件或目錄已經被調度加入版本控制。
- ●圖標8： 橫條告訴你有一個文件或目錄被版本控制系統所忽略。這個圖標重載是可選的。
- ●圖標9： 這個圖標說明文件和目錄未被版本控制，但是也沒有被忽略。這個圖標重載是可選的。
9.7 納入版本控制
①新建文件abc.txt
②在文件上點右鍵
③添加后文件圖標發生變化
9.8 提交
①使用TortoiseSVN可以提交具體某一個文件，或某一個目錄下的所有改變。方法就是在想要提交的項目下點右鍵，然后SVN Commit...，就可以看到如下界面
②日志內容如果不填，TortoiseSVN會提交一個空字符串作為日志信息。
③提交后顯示信息如下
④沒有納入版本控制的文件默認是不在提交范圍內的，直接在新創建的文件上點右鍵只能看到add操作的選項，如前所述。但在新創建的文件所在目錄點右鍵選擇SVN commit...，可以看到如下界面
將文件newFile.txt選中
同樣可以提交文件，TortoiseSVN會幫我們自動將newFile.txt納入版本控制
9.9 更新
在要更新的文件或目錄上點右鍵→SVN Update
9.10 回復歷史版本
①查看歷史版本內容
[1]首先需要把對應版本庫的匿名訪問權限設置為none：anon-access = none
[2]在要查看歷史版本的文件上點右鍵→TortoiseSVN→Show log
[3]在感興趣的歷史版本上點右鍵，可以與當前工作副本進行比較，或直接打開。
②在要回復歷史版本的文件上點右鍵→Update to revision
填上想要回到的版本即可
9.11 解決沖突
①文件發生沖突時的狀態和在Eclipse中一樣，這里就不贅述了。
②在沖突的文件上點右鍵→Edit Conflicts
③有“嘆號”的行是發生沖突的行
④在沖突行點右鍵
可以選擇四種操作：
[1]使用我的
[2]使用他們的
[3]把我的放在他們的前面
[4]把他們的放在我的前面
⑤在沖突解決后，直接保存——這時TortoiseSVN自動彈出如下確認界面
⑥文件變為紅色嘆號標志，自動生成的三個文件被刪除。提交修改即可。