TortoiseSVN使用教程

TortoiseSVN是一個SVN的客戶端

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命令。

7.subversion的版本控制模型
       當你用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會提示李四在提交修改前，應該先將Working Copy更新到最新版本，李四執行Update命令將Working Copy更新到Revision 11，這時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文件，這時你又改變了主意想放棄對該文件的修改，你能夠 單擊右鍵，TortoiseSVN->Revert，修改過的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的最上層目錄單擊右鍵，TortoiseSVN->Check For Modifications，在彈出的對話框點擊Check Repository按鈕後，就會顯示服務器端已經修改了的文件。該方法還有一個用途就是查看文件的鎖定，當你想鎖定一個文件時，你想先看看這個文件有沒 有被別人鎖定，點擊Check Repository按鈕會顯示服務器端Repository全部被鎖定的文件，若是你想鎖定的文件不在這裏面，那就說明該文件目前沒有人鎖定。