TortoiseSVN用戶端使用教程

用戶端的使用 

1.Checkout Repository 

首先要Checkout伺服器端的Repository， 

所謂的Checkout就是指獲得伺服器端指定的Repository存儲的所有檔案。 

這個Checkout和Visual Source Safe的Checkout意義完全不一樣， 

VSS的Checkout指的是鎖定某個檔案，如果你以前使用過VSS， 

在學習Subversion時這個問題一定要注意。

Checkout的具體方式是： 

在用戶端建立一個空目錄，比如：F:\Project1 

在該目錄上單擊右鍵，在彈出式菜單中選中SVN Checkout...， 

之後在“URL of Repository”文本框中填入你想要連接配接的Repository的位址， 

這個URL位址可以用浏覽方式加入。 

對于在本教程第二節建立的Repository， 

URL應該是“svn://xxx/project1” 

(xxx可以是伺服器端主機名，也可以是伺服器端的ip位址)。 

然後點OK，會彈出一個認證對話框， 

輸入在教程第三節設定的使用者名和密碼。 

點OK後就完成了對Repository的Checkout。 

比如：在伺服器端Repository中有一個a.txt檔案， 

那麼Checkout之後F:\Project1目錄下也會出現一個a.txt檔案。 

在本例中由于伺服器端的Repository還未添加任何檔案， 

是以在用戶端的F:\Project1下沒有檔案被Checkout。 

執行Checkout除了會在F:\Project1産生Repository存儲的檔案及目錄外， 

還會産生了一個“.svn”的隐含目錄，該目錄是由subversion管理的， 

不要删除或者手工改動其中的檔案和目錄。 

現在F:\Project1中的檔案和目錄就叫做Repository的“Working Copy”簡寫“WC” 

(這個簡寫...汗)。 

以後對Repository中檔案和目錄的修改，添加，删除的操作， 

都是通過對這個“Working Copy”的操作實作的。 

Checkout執行完後， 

會發現F:\Project1目錄的圖示的左下角附着了一個小的狀态圖示 

(當F:\Project1目錄中的檔案改變時，這個狀态圖示也會随之變化)， 

它表示F:\Project1是一個Repository的“Working Copy”， 

F:\Project1内的所有檔案和目錄也會有類似的狀态圖示。 

2.添加檔案 

将要添加的檔案或者目錄拷貝到F:\Project1下， 

然後在該檔案或目錄上單擊右鍵，TortoiseSVN->Add，點OK。 

如果添加了不止一個檔案或目錄， 

則滑鼠不要在F:\Project1中點中任何檔案， 

然後單擊右鍵，TortoiseSVN->Add， 

就可以添加多個檔案或目錄。 

這時檔案的狀态圖示會發生變化。 

Add指令隻是告訴本地的“Working Copy”将該檔案納入版本管理， 

并沒有将這個改變送出到伺服器端， 

如果想要别人也看見你對Repository的修改，你需要 

在F:\Project1下單擊右鍵，SVN Commit...， 

将你所做的修改送出到Repository。 

檔案的狀态圖示也會更新。 

不管你在“Working Copy”内添加、修改、删除檔案後， 

要想其他人也看見你的修改， 

都必須用Commit指令将所做修改遞交到伺服器端的Repository。 

3.修改檔案 

用文本編輯器或IDE對檔案修改後， 

檔案的狀态圖示會變化， 

然後單擊右鍵，SVN Commit... 

送出修改，隻有當執行Commit送出修改後， 

你所作的修改才會反映到伺服器端的Repository中。 

4.删除檔案 

删除檔案時，選中要删除的檔案或目錄， 

單擊右鍵，TortoiseSVN->Delete，送出修改。 

注意千萬不要用“Delete”鍵來删除檔案，否則将無法送出你的修改。 

這一點對目錄的删除來說尤為重要。 

5.放棄修改 

當你添加、修改、删除檔案後，決定放棄修改， 

你可以單擊右鍵，TortoiseSVN->Revert， 

本地的“Working Copy”中的檔案和目錄會恢複到你修改前的狀态。 

6.擷取Repository的最新版本 

當一個團隊合作開發項目時， 

每一個人都在不斷的對Repository進行更新， 

你需要不斷的更新自己的“Working Copy”， 

以擷取項目最新的檔案。 

當第一次獲得最新Repository的檔案時， 

我們用Checkout指令，前面已經介紹了， 

以後再擷取最新檔案時就不用Checkout了。 

而改用Update指令。 

接着前面的例子，這時F:\Project1已經成為一個“Working Copy”了 

(通過執行Checkout指令)，現在其他人已經對Repository進行了修改， 

我想将别人的修改反映到我的“Working Copy”中， 

具體的方法是：在F:\Project1目錄上單擊右鍵， 

SVN Update。這時F:\Project1中的檔案就是最新的版本了。 

注意，如果當你的“Working Copy”中有被修改的檔案， 

或者有被删除的檔案，并且還未送出這些修改時， 

這些檔案在執行Update過程中是不會被更新的。 

比如你修改了F:\Project1下a.txt檔案， 

還未送出修改，那麼， 

當你對F:\Project1進行Update時， 

a.txt檔案是不會更新為Repository上的a.txt檔案的。 

是以如果想放棄目前的所有修改， 

并将F:\Project1下所有檔案及目錄更新到最新版本, 

應該先對F:\Project1執行Revert指令再執行Update指令。 

當你用subversion進行版本控制時， 

Subversion會記錄你對Repository進行的每一次修改(包括添加，修改，删除等等)， 

每修改一次Repository都會産生一個新的Revision(修訂版本号)， 

不同的Revision代表了不同時刻Repository的狀态， 

是以我們可以用這個Revision回朔任意時刻Repository的狀态， 

就像時間機器一樣，也就是說某一Revision 

就是Repository在某一時刻的一個“快照”。 

注意：Revision不是針對某一個檔案或者目錄， 

而是針對整個Repository而言的。 

每修改一次Repository，Revision 都會增加1。 

Subversion的版本控制模型是一種叫做Copy-Modify-Merge 

(拷貝-修改-合并)的模型。 

考慮這種情況： 

張三和李四是公司同一個部門的同僚， 

他們共同維護一個文本檔案a.txt， 

并且對該檔案進行版本控制， 

是以他們把這個檔案放到一個Repository上共同維護該檔案。 

周一上午9點，張三和李四同時想對a.txt檔案進行修改， 

于是他們同時從Repository上取得該檔案的最新版本(Revision 10)， 

然後進行修改。過了三分鐘，張三首先完成了修改， 

他在該檔案的第五行修改了一個單詞的拼寫(将Typo改為Type)， 

于是張三對修改後的檔案執行Commit指令， 

将修改送出到伺服器端的Repository中。 

這時Repository的Revision變為11。 

六分鐘過後，李四也完成了他的修改， 

他修改了該檔案第十行上的一個單詞拼寫(将He改為She)， 

于是他也對修改後的檔案執行Commit指令， 

這時Subversion 在送出修改時會發現， 

李四修改的檔案是Revision10的a.txt檔案， 

而不是最新的Revision 11的a.txt檔案。 

于是，Subversion 提示李四在送出修改前， 

應該先将Working Copy更新到最新版本， 

李四執行Update指令将Working Copy更新到Revision 11， 

這時Subversion會提示已經完成合并， 

李四的a.txt檔案的第五行的“Typo”已經變為了“Type”， 

第十行還是“She”，就是說Subversion已經将張三的修改“合并”到李四的a.txt檔案中了。 

之後，李四再執行Commit指令，就能将他對第十行的修改(将He改為She) 

送出到伺服器端的Repository中了(生成Revision 12)。 

但是這種合并在某些情況下會變得複雜一些， 

比如：李四對a.txt檔案的修改并不是第十行， 

而是與張三同樣修改第五行的單詞， 

李四将“Typo”改為“Typr”，并且送出修改， 

這時Subversion會提示李四在送出修改前， 

這時Subversion将Revision11的a.txt檔案與 

李四修改的a.txt檔案進行合并時發現李四修改的同樣是第五行， 

于是Subversion就無法判斷是李四的修改(“Tpyr”) 

正确還是張三的修改(“Type”)正确， 

因為他們都是在Revision10的a.txt基礎上作的修改。 

這種情況叫做Conflict(沖突)， 

a.txt檔案的圖示會變成一個黃色三角。 

這時，隻能依靠李四自己去判斷到底第三行應該修改為“Typr”還是“Type”。 

當李四确定修改之後，在a.txt檔案上單擊右鍵，TortoiseSVN->Resolved 

告訴Subversion已經解決了Conflict。 

這時再執行Commit指令就能送出修改(生成Revision 12)。 

Subversion 這種控制方式保證了你對檔案所作的修改都是基于檔案的最新版本。 

8.“.svn”目錄 

在用戶端Working Copy的每一層目錄中都會有一個“.svn”目錄， 

該目錄是Subversion進行管理用的目錄。 

不要手動修改其中的檔案。 

該目錄存儲了Working Copy的一個副本 

(實際存儲副本的地方是F:\project1\.svn\text-base目錄)， 

比如：F:\Project1是一個Working Copy， 

該目錄下有兩個檔案a.txt和b.txt還有一個子目錄ccc， 

子目錄ccc中還有一個d.txt檔案。 

“.svn”目錄中存儲的是你最近一次執行完Update或者Commit指令之後目前目錄中檔案的副本， 

比如：F:\project1\.svn\text-base中存儲的a.txt和b.txt 

是最近一次執行完Update或者Commit指令之後F:\project1下的a.txt和b.txt的拷貝。 

也就是說你所作的修改都是基于“.svn”目錄存儲的那些檔案。 

這種機制可以讓我們在不連接配接網絡的情況下， 

将Working Copy中的檔案恢複到修改之前的狀态。 

Subversion的Revert指令就是利用了這種機制來實作的。 

比如你修改了F:\project1\a.txt檔案， 

這時你又改變了主意想放棄對該檔案的修改， 

修改過的F:\project1\a.txt檔案 

就會被F:\project1\.svn\text-base中a.txt檔案的副本所替代， 

使得a.txt恢複到修改前的狀态。 

Working Copy中每一個子目錄下都會有一個“.svn”目錄， 

并不是隻有最上層目錄才有“.svn”目錄。 

是以，F:\project1\ccc下也有一個“.svn”目錄， 

該目錄存儲的是F:\project1\ccc\d.txt的副本 

(d.txt的副本位于F:\project1\ccc\.svn\text-base)。 

也就是說每個“.svn”目錄隻存儲同級目錄中的“檔案”副本， 

而不存儲“目錄”副本。“.svn”目錄存有許多重要的内容， 

是以前面說在删除檔案或目錄時， 

必須用TortoiseSVN->Delete， 

而不能用“Delete”鍵來删除檔案或目錄，尤其是對于目錄的删除。 

9.混合版本 

Subversion的Working Copy被設計成一種能夠包含不同版本的檔案共存的形式。 

比如F:\Project1是一個Working Copy， 

該目錄下有兩個檔案a.txt和b.txt。 

執行Update指令，将Working Copy更新到最新版本（Revision 24）。 

這時，a.txt和b.txt的Revision都是24 

(其實對于單個檔案來說并不存在Revision， 

Revision是對于整個Repository而言的， 

這裡所指的是Repository的Revision24所存儲的a.txt和b.txt， 

但為了友善而采用這種描述方式，請注意，下同）。 

之後，你的同僚修改了a.txt，并且送出了修改， 

這時Repository的Revision就變成25了。 

注意，這時你沒有再次執行Update， 

是以你的Working Copy的Revision還是24。 

這時你修改了b.txt檔案，并送出修改。 

因為Revision25并沒有對b.txt檔案進行修改， 

是以你對b.txt檔案的修改是基于b.txt檔案最新的版本， 

是以不會出現Conflict。 

當你送出b.txt的修改後，産生Revision26。 

這時你會發現你的Working Copy中的a.txt檔案并不是Revision25中的a.txt檔案， 

它還是Revision24的a.txt檔案，而你的b.txt檔案是Revision26的b.txt檔案。 

也就是說當你Commit時，你的Working Copy中隻有你送出的那些檔案是最新版本， 

而其他沒有修改的檔案并不會更新為最新版本。 

這樣就造成了你的Working Copy由不同的Revision檔案所組成 

(Revision24的a.txt檔案和Revision26的b.txt檔案)。 

前面說過在送出修改前必須保證你是在檔案的最新版本基礎上修改， 

如果在這種混合版本的情況下， 

怎樣才能知道目前Working Copy中的檔案是否為最新版本？ 

在前面所說的“.svn”目錄中有一個檔案名為“entries”的檔案， 

該檔案記錄了目前Working Copy中的每一個檔案的Revision， 

是以當你Commit時，Subversion會從該檔案中取得你送出檔案的Revision， 

再與Repository的最新Revision一比較就可以知道你修改的檔案是否基于該檔案的最新版本。 

10.檔案的鎖定 

前面說過Subversion的版本控制模型是一種叫做Copy-Modify-Merge 

（拷貝-修改-合并）的模型。 

該模型在對文本檔案進行版本控制時工作的很好， 

但是有些需要進行版本控制的檔案并不是文本檔案， 

比如說圖像檔案，這種模型在這種情況下就不能正常工作了， 

因為文本檔案可以合并，而二進制檔案則無法合并。 

是以Subversion從1.2開始支援一種叫Lock-Modify-Unlock 

（鎖定-修改-解鎖）的版本控制模型。 

在Windows下最常用的版本控制軟體Visual Source Safe(VSS)就是采用這種模型。 

這種模型要求在對一個檔案修改前首先要鎖定這個檔案， 

然後才能修改，這時，别人将無法對該檔案進行修改， 

當修改完後再釋放鎖，使其他人可以對該檔案進行鎖定，然後修改。 

鎖定檔案的方法是：TortoiseSVN->Get Lock...再點OK按鈕， 

這時就完成了對檔案的鎖定。 

這時，如果其他人想對檔案進行鎖定時， 

Subversion會對他提示該檔案已經被别人鎖定。 

當你修改完檔案後，然後單擊右鍵，SVN Commit...， 

将修改送出，預設情況下，送出的時候就會對該檔案解鎖， 

如果你想仍然鎖定該檔案，請在commit時彈出的對話框中選中keep lock複選框。 

11.檔案的附加屬性 

在Subversion中，每個檔案可以擁有一種叫做附加屬性的東西。 

附加屬性描述了該檔案所擁有的一些特性。 

Subversion已經預定義了一些附加屬性 

（這裡隻是指Subversion已經定義了一些附加屬性的“名稱”， 

并不是指已經将這些屬性附加在檔案上了， 

比如預設情況下文本檔案一開始不含任何屬性， 

直到人為的對該檔案添加附加屬性）， 

并且你可以對檔案添加自定義的屬性。 

Subversion對待附加屬性就像對待檔案内容一樣， 

當修改了一個檔案的附加屬性（添加，改變，删除附加屬性）， 

即使沒有對檔案的内容進行修改， 

同樣可以Commit該檔案，就像更改了檔案内容那樣， 

Repository也會生成新的Revision， 

是以從某種意義上來說， 

Subversion不差別對待檔案的附加屬性的修改和檔案的内容的修改， 

檔案的附加屬性可以看成是一種特殊的檔案内容。 

Subversion預定義了若幹個附加屬性， 

這裡隻讨論“svn:needs-lock”屬性， 

因為它與我們上面的檔案鎖定會産生的一個問題有關。 

其他的屬性可以參考Subversion自帶的幫助文檔。 

考慮這種情況， 

張三和李四同時想對一個圖檔檔案a.jpg作修改， 

張三在修改時先将該檔案鎖定，然後進行修改， 

同時李四也開始對該檔案進行修改， 

但李四忘記了對非文本檔案進行修改時應該先鎖定該檔案。 

張三首先對該檔案修改完畢，于是張三向伺服器送出了他的修改。 

之後，李四也完成了修改，當他送出修改時， 

Subversion提示李四的檔案版本不是最新的， 

在Commit之前應先更新a.jpg到最新版本， 

由于圖檔檔案無法合并， 

這就意味着張三和李四之間必定有一個人的修改會廢棄。 

應用“svn:needs-lock”屬性可以避免這個問題。 

當一個檔案擁有“svn:needs-lock”屬性時， 

該檔案在沒有鎖定時，檔案的圖示是灰色的， 

表示該檔案是一個隻讀檔案（該檔案的Windows隻讀屬性的複選框為選中）， 

這個灰色的圖示就會提醒想對該檔案進行修改的人， 

在修改該檔案之前應該首先鎖定該檔案。 

鎖定該檔案之後，檔案的隻讀屬性就會去掉了， 

一旦釋放掉鎖，檔案的圖示又會變成灰色， 

檔案也會變成隻讀的了。 

李四在這種情況下就會避免在沒有鎖定檔案時對檔案進行修改。 

對非文本檔案添加“svn:needs-lock” 

屬性應該在将該檔案第一次添加到Repository時就設定， 

當然，一個檔案可以在任意時刻添加附加屬性， 

這樣做是為了減少李四所遇到的那個問題發生的幾率。 

具體的方法是： 

首先将a.jpg檔案拷貝到Working Copy中， 

然後在該檔案上單擊右鍵， 

TortoiseSVN->Add，告訴Subversion要将該檔案納入版本控制， 

接着在該檔案上單擊右鍵并選中屬性， 

在彈出的屬性對話框中選中Subversion頁。 

在下拉框中選中“svn:needs-lock”， 

并在下面的文本框中填入“*” 

（其實這裡填什麼都無所謂，隻要檔案有“svn:needs-lock”附加屬性就行）， 

之後點Set按鈕，“svn:needs-lock”附加屬性就設定好了。 

然後執行Commit指令送出修改。 

這時當其他人執行Update時， 

a.jpg就會添加到他們的Working Copy中， 

并且檔案的附加屬性也會随檔案一起被得到。 

可以看到a.jpg此時的圖示就是灰色的， 

檔案的Windows屬性也是隻讀的。 

12.回到以前的版本 

由于Subversion會記錄你對Repository的每一次修改， 

是以能夠很容易的獲得Repository以前某一時刻的狀态。 

比如：現在Repository的最新Revision是56， 

這時我想看看Repository在Revision24時的狀态， 

可以在本地的Working Copy中單擊右鍵， 

TortoiseSVN->Update to Revision...， 

然後輸入你想要回複到的Revision号，點OK按鈕。 

回到以前的版本還有一種情況是我想将Repository的 

最新Revision的狀态與以前某一個Revision的狀态一模一樣， 

上面那種方法就不适合， 

上面的那種方法隻是将本地的Working Copy回複到以前的狀态， 

而伺服器端的Repository并沒有回到以前的狀态。 

将Repository的最新Revison的狀态回複到以前某個Revision的狀态具體的方法是： 

先執行Update指令将Working Copy更新到最新的Revision， 

然後在Working Copy中單擊右鍵， 

TortoiseSVN->Show Log， 

彈出的Log Messages視窗中會顯示該Repository的所有Revision， 

選中最新的Revision，之後按住Shift鍵， 

再單擊你想回複到的Revision+1的那個Revision 

（比如Repository的最新Revision是30， 

你想将Repository的狀态回複到Revision16， 

那麼就選中Revision30，再按住Shift鍵， 

選中Revision17， 

就是說選中Revision17到Revision30之間的所有Revision）。 

然後在選中的Revision上單擊右鍵， 

選中“Revert changes from these revision”。 

再點Yes按鈕，就可以将Working Copy的狀态回複到目标Revision。 

注意，此時隻是Working Copy回複到目标Revision， 

之後應該用Commit送出修改， 

這樣Repository最新狀态就與目标Revision的狀态一樣了。 

這兩種回複到以前版本的方式截然不同， 

第一種方式是将整個Working Copy回複到某個Revision， 

也就是說這種方式Working Copy中的“.svn”目錄所存的檔案副本也與目标Revision的一模一樣， 

如果這時你沒有修改檔案，你将不能執行Commit指令。 

而第二種方式用戶端Working Copy中的 

“.svn”目錄所存的副本始終是最新的Revision的檔案副本 

（這裡我們基于一個假設：在Update之後沒有其他人對Repository做修改）。 

這種方式就像是我們自己手工将Working Copy的檔案狀态修改為目标Revision， 

在修改之後送出修改一樣。 

13.檢視修改 

有時我們對Working Copy的許多檔案進行了修改， 

這些檔案位于不同的子目錄，我們就可以在Working Copy的最上層目錄單擊右鍵， 

TortoiseSVN->Check For Modifications， 

彈出的對話框就會顯示你所做的所有修改明細。 

還有一種情況是我們的Working Copy已經很久沒有執行Update指令， 

我們想看看Working Copy中有哪些檔案已經發生修改了， 

這時就可以在Working Copy的最上層目錄單擊右鍵， 

在彈出的對話框點選Check Repository按鈕後， 

就會顯示伺服器端已經修改了的檔案。 

該方法還有一個用途就是檢視檔案的鎖定， 

當你想鎖定一個檔案時，你想先看看這個檔案有沒有被别人鎖定， 

點選Check Repository按鈕會顯示伺服器端Repository所有被鎖定的檔案， 

如果你想鎖定的檔案不在這裡面，那就說明該檔案目前沒有人鎖定。

文檔引自：http://blog.csdn.net/shilang999/article/details/7724031

      本文轉自MQ_douer 51CTO部落格，原文連結：，http://blog.51cto.com/douer/1914858如需轉載請自行聯系原作者