❶ 怎麼使用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所有被鎖定的文件，
如果你想鎖定的文件不在這裡面，那就說明該文件目前沒有人鎖定。
❷ 請教TortoiseSVN怎麼用
1.首先，假設你的電腦是win7 64位的，你要准備的東西：VisualSVN-Server-3.0.1-x64.msi和TortoiseSVN-1.8.8.25755-x64-svn-1.8.10.msi
2.安裝完之後
3.打開VisualSVN Server Manager，直接右鍵Repositories，Create New Repository,輸入Repository Name，假設輸入的是testsvn,OK
4.那麼現在在Repositories下就會有一個資源名稱叫testsvn
5.那麼我們現在右鍵Users，Create User，輸入名稱密碼都是testsvn，OK，我們這就創建了一個叫testsvn的用戶了，以後可以用它檢入檢出數據了
6.現在我們要檢出這個資源的東西，右鍵Repositories下的testsvn，Copy Url to ClipBoard，這樣就選中了它的url了
7.我們在C盤右鍵，選擇SVN Checkout，在URL of repository粘貼，OK
8.經過以上步驟之後，你可以檢出你的項目了，請嘗試在裡面新建修改文件提交就行了
9.如果你要在eclipse裡面使用也可以，因為你已經有了url和用戶名密碼
10.如果我重裝系統之後，資源是不是消失了？沒關系，在菜單欄的操作(A)-Properties裡面設置你的Repositories Root，這樣，無論你怎麼重裝，都沒有關系了，自己的svn，區域網的svn就這么配置好了。
❸ 如何用TortoiseSVN管理本地文檔
TortoiseSVN是windows下其中一個非常優秀的SVN客戶端工具。通過使用它，我們可以可視化的管理我們的版本庫。不過由於它只是一個客戶端，所以它不能對版本庫進行許可權管理。
TortoiseSVN不是一個獨立的窗口程序，而是集成在windows右鍵菜單中，使用起來比較方便。
TortoiseSVN每個菜單項都表示什麼意思
01、SVN Checkout(SVN取出)
點擊SVN Checkout，彈出檢出提示框，在URL of repository輸入框中輸入伺服器倉庫地址，在Checkout directory輸入框中輸入本地工作拷貝的路徑，點擊確定，即可檢出伺服器上的配置庫。
02、SVN Update(SVN更新)
如果配置庫在本地已有工作拷貝，則取得最新版本只是執行SVN Update即可，點擊SVN Update，系統彈出更新提示框，點擊確定，則把伺服器是最新版本更新下來
03、Import（導入）
選擇要提交到伺服器的目錄，右鍵選擇TortoiseSVN----Import，系統彈出導入提示框，在URL of repository輸入框中輸入伺服器倉庫地址，在Import Message輸入框中輸入導入日誌信息，點擊確定，則文件導入到伺服器倉庫中。
04、Add(加入)
如果有多個文件及文件夾要提交到伺服器，我們可以先把這些要提交的文件加入到提交列表中，要執行提交操作，一次性把所有文件提交，如圖，可以選擇要提交的文件，然後點擊執行提交（SVN Commit）,即可把所有文件一次性提交到伺服器上
05、Resolving Conflicts(解決沖突)
有時你從檔案庫更新文件會有沖突。沖突產生於兩人都修改文件的某一部分。解決沖突只能靠人而不是機器。當產生沖突時，你應該打開沖突的文件，查找以<<<<<<<開始的行。沖突部分被標記：
<<<<<<< filename
your changes
=======
code merged from repository
>>>>>>> revision
Subversion為每個沖突文件產生三個附加文件：
filename.ext.mine
更新前的本地文件。
filename.ext.rOLDREV
你作改動的基礎版本。
filename.ext.rNEWREV
更新時從檔案庫得到的最新版本。
使用快捷菜單的編輯沖突Edit Conflict命令來解決沖突。然後從快捷菜單中執行已解決Resolved命令，將改動送交到檔案庫。請注意，解決命令並不解決沖突，而僅僅是刪除 filename.ext.mineandfilename.ext.r*文件並允許你送交。
06、Check for Modifications（檢查更新）
點擊Check for Modifications,系統列表所以待更新的文件及文件夾的狀態.
07、Revision Graph(版本分支圖)
查看文件的分支,版本結構,可以點擊Revision Graph,系統以圖形化形式顯示版本分支.
08、Rename(改名)
SVN支持文件改名,點擊Rename,彈出文件名稱輸入框,輸入新的文件名稱,點擊確定,再把修改提交,即可完成文件改名
09、Delete(刪除)
SVN支持文件刪除,而且操作簡單,方便,選擇要刪除的文件,點擊Delete,再把刪除操作提交到伺服器
10、Moving(移動)
選擇待移動的文件和文件夾；按住右鍵拖動right-drag文件（夾）到跟蹤拷貝內的新地方；松開左鍵；在彈出菜單中選擇move files in Subversion to here
11、Revert(還原)
還原操作,如剛才對文件做了刪除操作,現在把它還原回來,點擊刪除後,再點擊提交,會出現如上的提示框,點擊刪除後,再點擊Revert,即已撤銷刪除操作,如果這時候點擊提交,則系統彈出提示框:沒有文件被修改或增加,不能提交
12、Branch/Tag(分支/標記)
當需要創建分支，點擊Branch/Tag，在彈出的提示框中，輸入分支文件名，輸入日誌信息，點擊確定，分支創建成功，然後可查看文件的版本分支情況
13、Switch(切換)
文件創建分支後，你可以選擇在主幹工作，還是在分支工作，這時候你可以通過Switch來切換。
14、Merge(合並)
主幹和分支的版本進行合並，在源和目的各輸入文件的路徑，版本號，點擊確定。系統即對文件進行合並，如果存在沖突，請參考沖突解決。
15、Export(導出)
把整個工作拷貝導出到本地目錄下,導出的文件將不帶svn文件標志,文件及文件夾沒有綠色的」√」符號標志。
16、Relocate(重新定位)
當伺服器上的文件庫目錄已經改變，我們可以把工作拷貝重新定位，在To URL輸入框中輸入新的地址
17、Add to Ignore List(添加到忽略列表)
大多數項目會有一些文件（夾）不需要版本控制，如編譯產生的*.obj, *.lst,等。每次送交，TortoiseSVN提示那些文件不需要控制，挺煩的。這時候可以把這些文件加入忽略列表。
❹ 詳細使用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所有被鎖定的文件，
如果你想鎖定的文件不在這裡面，那就說明該文件目前沒有人鎖定。
❺ tortoisesvn安裝之後怎樣使用
去TortoiseSVN官網下載中文簡體版語言包，然後安裝，在TortoiseSVN的Setting設置里選擇簡體中文，點擊【應用】，【確定】後重新打開TortoiseSVN就可以使用中文版的了。
❻ tortoisesvn怎麼配置使用
安裝過程：
1、下載軟體後，雙擊程序進行安裝，點擊「Next」；
2、在許可證協議頁面，選擇「I Accept the terms in the License Agreement」，點擊「Next」；
3、在自定義選項頁面，可以選擇安裝目錄，也可以直接點擊「Next」進行安裝；
4、點擊「Install」開始安裝；
5、安裝完成後，點擊「Finsh」；
建立庫：
1、新建文件夾，目錄和文件夾名稱最好都用英文，不要使用中文；
2、打開文件夾，在空白處按下「shift鍵+滑鼠右鍵」；
3、在彈出的菜單中選擇「TortoiseSVN - Create repository here」；
4、彈出對話框，提示創建成功，並自動在文件夾中創建了目錄結構；
導入項目：
1、打開已有的項目文件夾，在空白處按下「shift鍵+滑鼠右鍵」；
2、在彈出的菜單中選擇「TortoiseSVN - Import」；
3、選擇導入路徑，填寫備注信息，點擊「OK」開始導入；
4、導入完成後會彈出提示，可以拖動滾動條查看導入的文件，點擊「OK」，完成導入；
建立工作目錄（檢出）：
1、新建工作目錄文件夾，在空白處按下「shift鍵+滑鼠右鍵」；
2、在彈出的菜單中選擇「SVN Checkout...」；
3、在彈出的對話框中選擇庫目錄、工作目錄，點擊「OK」開始檢出；
4、彈出詳細信息對話框，導出完成後，點擊「OK」；
可以看到工作目錄中多出了庫中的文件，這些文件就是有版本控制的，對這些文件的修改可以保存到庫，也可以從庫里恢復舊版本的文件。
更新工作目錄：
1、通常在你對工作目錄進行修改前，為保證你的文件是最新的，需要進行更新操作；
2、在工作目錄空白處點擊滑鼠右鍵，選擇「SVN Update」；
3、會彈出對話框開始更新，並顯示更新了哪些內容，庫版本是多少；
提交工作目錄：
1、在做了修改，需要保存到庫中時，用到提交操作；
2、在工作目錄空白處點擊滑鼠右鍵，選擇「SVN Commit」；
3、會彈出對話框，可以輸入備注信息，顯示將要提交哪些文件，點擊「OK」開始提交；
4、彈出對話框顯示提交進度，完成後點擊「OK」完成提交；