linuxsvn刪除文件

① SVN的操作說明以及備份策略

2.1 文件檢出
安裝TortoiseSVN後，SVN會跟Windows的資源管理器完美集成。點擊右鍵，我們可以在菜單欄中選擇「SVN檢出」選項，輸入要檢出代碼的文件庫的URL地址，我們就可以檢出該URL地址下的文件庫的文件。默認情況下是檢出最新版本的代碼，如果需要，我們可以通過瀏覽日誌，根據日誌來找出想要的版本，然後在「版本」選項中指定相應版本就可以檢出相關代碼了 。
之後，對於同一個項目的主幹開發，我們都在這個檢出的代碼文件目錄下操作，而不是每一次提交或更新都重新檢出一次。
2.2 文件添加
我們在本地創建的文件(包括目錄)不會受SVN的控制，為了讓其接受SVN的控制必須將其添加到文件庫中。對於團隊其他成員需要的文件，如代碼文件、某些模塊的.a文件（由於某些需要，該模塊代碼不公開），我們必須讓它們接受SVN的控制，並且保持最新的版本。
2.3 文件刪除
當我們需要刪除無用的文件(包括目錄)時，不能使用Windows的資源管理工具，而必須使用SVN本身的刪除文件功能。這樣該文件被刪除後，其所有修改歷史仍然保存在SVN伺服器中，以後仍然可以獲得該文件的修改歷史。
2.4 文件改名
當我們需要對文件(包括目錄)進行改名的時，不能使用Windows的資源管理工具，而必須使用SVN本身的文件改名功能。這樣該文件被改名後，其改名前的所有修改歷史仍然保存在SVN伺服器中，保持連續的修改信息。
2.5 文件更新
其他團隊成員提交到SVN上的改動不會自動更新到你的本地拷貝中來，我們需要通過更新文件操作來獲取其他成員對項目文件所做的修改。SVN更新文件操作會把文件庫里的文件與本地文件進行合並，從而達到了同時保留其他成員的修改及本地的修改的目的。如果無法自動合並則會發生沖突，需要使用文件比較工具進行手工合並，合並完成後才能提交已解決沖突的文件。沖突的詳細解決方法見第三章——沖突解決。
在團隊開發時，更新是一件很重要的工作，可以保持團隊成員之間的工作內容一致，因此要注意經常更新自己的工作拷貝，以保證自己能夠獲得最新的修改內容。
2.6 改動提交
我們對文件(包括目錄)所做的一切改動，包括添加、刪除、修改文件都必須提交到SVN伺服器文件庫中才能正式生效，之後團隊的其他成員才可以獲取你所作的修改。
提交是很重要的一項操作，要求做到：
 提交代碼之前一定要保證修改後的代碼能編譯通過，不能提交編譯不通過的代碼。
 比較修改前及修改後的代碼，把調試信息或其他不相關的信息去掉，再次確保提交的代碼是正確的並且提交的是需要提交的文件。
 不要等到修改了很多代碼才提交，而是相關小功能完成時就應該提交一次。這樣以後發現問題時就很容易撤銷有問題的代碼——因為撤銷只能針對一次提交，所以在一次提交里涉及過多的功能是不推薦的。
 提交時必須填寫log信息，說明這次提交增加了什麼功能或者修正了什麼bug。這些信息有助於自己和其他團隊成員了解整個項目的歷史。當出現問題時也方便定位到對應的版本代碼，所以log信息必須足夠詳細。
 事務性提交。也就是說提交要麼成功，要麼全部失敗——即提交出現錯誤時會自動回滾，實際上沒有提交任何東西。出現錯誤時，解決錯誤，再次提交上次提交的全部內容即可。
3. 沖突解決
沖突的解決是我們使用SVN過程中的一個棘手問題，所以獨立一節來談論。
3.1 沖突的產生
沖突發生在多個成員同時對同一個文件進行修改的情形下。即當有其他成員已經提交了修改，而自己在本地拷貝中也對該文件進行了修改，而且修改的是同一個地方，那麼在進行本地文件的更新時，SVN會不知道該選擇那個修改（SVN上的修改還是本地的修改）來進行合並，所以沖突就產生了。
舉例說，假如受SVN控制的文件Day.txt在SVN伺服器上的當前內容如下：
圖表 3 Day.txt文件在本地的修改
我們可以看到，在文本的第一行，SVN上及本地都做了修改。這樣當在本地進行更新（提交之前必須先更新），SVN合並時就不知道monday後面到底該是work還是sleep，所以沖突就產生了。
而第三、五行是各自進行了修改，並沒有沖突，所以這兩行可以順利合並，合並後可以看到所有人所做的修改。
3.2 沖突的解決
沖突發生後，SVN會在本地保存該文件的不同修改版本，見下圖藍色圖標：

圖表 4 Day.txt文件的不同版本
 Day.txt.r35是版本35的Day.txt文件（本地拷貝最新版本）
 Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）
 Day.txt.mine的是本地修改後的Day.txt文件
 Day.txt文件中包含了合並後的內容
3.2.1 簡單沖突解決
對於簡單的內容沖突，我們可以直接在合並後的文件上修改。在上例中，我們打開Day.txt文件，可以看到SVN合並後的內容：

圖表 5 Day.txt合並後內容
我們看到沒有沖突的修改：(play basketball)及（meeting）順利地合並了，而沖突的部分出現了一些標記。其中標記
<<<<<<< .mine
=======
之間包含的是本地修改的沖突部分的內容，即monday(work)。而標記
=======
>>>>>>> .r37
之間包含的是版本37（SVN上最新版本）該部分內容，即monday(sleep)。
不失一般性，假如我們現在要保留的內容是monday(work)，那麼我們只要把標記及monday(sleep)部分內容去掉即可：

圖表 6 Day.txt解決沖突後內容
確保修改正確後，把Day.txt文件設置為「已解決的」。

圖表 7 Day.txt標記為已解決
之後，後綴為mine,r35,r37文件全部消失，僅保留已解決沖突的Day.txt文件，提交到SVN即可。
3.2.2 復雜沖突解決
對於文件內容復雜的文件，上述的解決方法容易漏掉一些要修改的部分，解決起來也耗時耗力。這時要通過SVN提供的工具來解決。
選擇SVN功能「編輯沖突」，打開沖突編輯工具:

圖表 8 沖突編輯工具
上半部分的兩個內容欄分別顯示的是版本37的內容及本地修改的內容。
下半部分的內容欄顯示的是合並後的內容。
每個內容欄左邊的標記清楚地標識了該文件做了那些修改。
文件沖突的部分用紅色顯眼地表示了出來。在合並欄，點擊沖突部分，點擊右鍵，我們可以選擇用哪個內容（SVN上最新內容或者本地修改內容）來解決沖突部分，也可以選擇兩個內容都使用，同時選擇它們出現的先後順序。
逐一解決各個沖突。確保所有沖突都解決後，保存文件，並標記為「已解決」的，退出該工具即完成沖突的解決。
4. 加鎖策略
事實上，解決沖突還有一種方法，那就是「嚴格加鎖」。
「嚴格加鎖」要求在編輯文件之前必須先對文件加鎖，然後才能進行編輯。此時團隊其他成員不能對該文件進行編輯，即保證了同一時刻只有一個人在編輯該文件，因此避免了沖突的出現。
那麼，什麼類型的文件我們應該採取「嚴格加鎖」呢？
 Excel、圖片等不可合並的文件，我們必須對其「嚴格加鎖」。「嚴格加鎖」的文件都標記為「可讀」的，即不可編輯。要編輯這些「嚴格加鎖」的文件，必須先對其加鎖，加鎖後文件更改為「可讀可寫」。編輯完這類文件後要第一時間提交。提交完成時，SVN會自動解開任何你擁有的鎖 。
 文本文件，比如程序代碼，SVN通常可以為我們合並改動，無須「嚴格加鎖」。對於一些大家都頻繁改動的重要源代碼文件，可能會引起大量沖突，我們也不推薦「嚴格加鎖」，因為加鎖會導致大家持續得走來走去去詢問加鎖情況。正確做法是把文件分成數個邏輯單元，大家都修改各自的單元，減少合並時的沖突。
5. 標簽&分支
一個項目最初存放的目錄我們稱之為主幹(trunk)。下面我們討論除了主幹之外其他存放項目的目錄——標簽(tag)和分支(branch)。
5.1 標簽（tag）
版本號可以區分多次的代碼修改，我們可以使用版本號來檢出需要的代碼，但對於重要版本的代碼，如第三版發布代碼，我們不希望記住r37這樣的數字。這時，我們就可以通過創建標簽來對SVN中這個發布版本的文件的這個時刻的狀態創建一個「快照」，以後就可以通過這個標簽名字來檢出第三發布版本的代碼。
標簽其實是當前項目文件的簡單拷貝，保存在標簽所在的目錄下。創建標簽也是挺簡單的，不過要注意：
 標簽的名字一定要有描述性，可以僅憑名字就知道為什麼要創建標簽。
 不能過多地使用標簽，只有在重要時刻或者發布版本時才可以創建標簽。
 標簽是項目文件在某個時刻的狀態，不能對其進行修改 。
5.2 分支（branch）
分支跟標簽一樣，也是當前項目文件的簡單拷貝，保存在分支所在的目錄下。
分支跟標簽的根本區別在於，標簽不能對其進行修改，而分支就是為了某種目的的修改而建立的。在檢出代碼時檢出指定分支即可，分支的操作跟主幹上的操作完全相同。
5.2.1 何時創建
遇到下述情況，我們可以通過創建分支來解決問題：
 發布分支
當我們快要發布一個版本了，一個開發小團隊要為這次發布做好准備，比如說修改一些收尾的bug。這時他們需要的是項目的穩定性，而同時我們還有其他團隊要開發預計下次發布才會添加進去的功能，顯然他們不能在同一份代碼上工作，因此我們需要從主幹中建立出一個發布分支，發布團隊都從這個發布分支檢出及提交代碼。當程序被發布之後，這個分支依然是活動的。這樣，如果客戶報告了一些bug，團隊會在這個發布分支中修正它們並視情況合並到主幹中去。
 試驗分支
當我們需要對項目做大范圍的改動，並且這改動對系統的其餘部分有深遠的影響，而我們又不能保證這次改動一定能成功的時候就可以建立試驗分支。如果試驗失敗了，可以廢棄這個分支；成功了我們只要把分支的改動合並到主幹代碼中去就可以了。
其他情況，我們不建議創建分支，更不推薦在分支上創建分支，因為分支過多，合並時的沖突將會是一種難於解決的災難。
5.2.2 合並分支
我們在分支上所修正的bug很可能在主幹上或者其他分支上也存在，因為它們往往來自同一份代碼，所以我們在分支上所做的改動有必要合並到主幹或者其他分支中去。
對於簡單的bug，一次提交就能解決問題的，那麼我們只要記住提交新版本號，然後使用新版本號把改動合並到其他的受影響的主幹及分支中去就可以了。
對於復雜的bug，可能需要多個開發者花幾天的時間提交多次才能修好。這時光用版本號來記住修改的內容就有點勉為其難了。因此，我們可以使用標簽來標記我們修正過程的開始和結束，然後使用這些標簽幫助我們把修正的代碼合並到主幹和其他分支中去。整個過程如下：
① 給分支打個標簽，標記bug修改開始。
② 測試重現bug，修正代碼讓新測試通過。
③ 提交你的改動到SVN上。
④ 重復步驟2、3，直到確定bug已經修正。
⑤ 再給分支打個標簽，標記bug修正結束。
⑥ 使用兩個標簽來把修正的代碼合並到所有其他受影響的主幹和分支上。
6. 注意事項
經常更新
 由於文件可能有多個人修改，應該經常更新你的工作拷貝中的文件，這樣能降低發生沖突的可能性。
測試提交
 提交前先在本地進行測試。不允許將有錯誤的文件提交到SVN伺服器上。
填寫備注
 提交時一定要寫備註：備注有助於其他人（包括三個月後的你自己）理解你對文件所做的修改。
整體提交
 提交文件時注意要提交一項改動所對應的所有文件，不要一次提交一個文件或者一次提交修改了很多功能的一堆文件。
發布標簽
 對於每一個發布的版本都要建立標簽：當用戶告訴你發生某個問題時，你可以迅速地追蹤到問題是在哪個版本引入的 。

附：測試自動化小組SVN使用指導原則
1. Project的構建
Project在SVN伺服器上的目錄架構如下：

SVN上的項目文件：
1. 必須保證Trunk上的代碼是最新的！定期對Trunk上的代碼進行更新，各小組可根據各自實際情況自己把握
2. Tag是根據項目需要所打的標簽，每一個發布的版本都要打Tag，主要是方便有需要時可以直接根據Tag返回到之前的狀態，以便於分析、測試；Tag中必須包含相應的release文件及當時編譯或發布時的源代碼，必須有相關的文檔註明項目背景、發布情況等。
3. Branch文件夾可以用作備份用，可以用個人名字命名文件夾；此外，Branch分支主要用來進行短暫或者探索性的開發使用，最終的軟體版本必須更新、合並到Trunk主幹上。
4. 關於同一項目組開發環境的建議：同一項目組成員的開發環境最好一致，軟體安裝路徑和Project文件存放路徑最好一致。
2. 版本號
關於版本號命名規則：主版本號.子版本號.修正版本號
1. 項目初版本時，版本號為0.1.0；
2. 當項目在進行了局部修改或 bug 修正時，主版本號和子版本號都不變，修正版本號加 1；
3. 當項目在原有的基礎上增加了部分功能時，主版本號不變，子版本號加 1，修正版本號復位為 0；
4. 當項目在進行了重大修改或局部修正累積較多，而導致項目整體發生全局變化時，主版本號加 1，子版本號和修正版本號復位為0；
5. 編譯版本號一般是編譯器在編譯過程中自動生成的，我們只定義其格式，如果編譯器不能自動生成，人手添加，數值代表為當前的系統時間。
例子：V1.0.1 Build090305 Rel111123
其它版本使用規則：
1. α（alphal）內部測試版
此版本表示該軟體僅僅是一個初步完成品，只在組內內部交流，該版本軟體的 bug 較多，限內部測試使用。
例子：V0.1.1 Build090305 alphal1
2. β（beta）外部測試版
該版本相對於α版已有了很大的改進，經過組內的測試，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過大規模測試來進一步消除。
例子：V0.1.2 Build090305 beta1
3. demo 演示版
僅限評審或講解時做介紹使用。
例子：V0.1.3 Build090305 demo1
4. release 最終版
該版本意味「最終釋放版」，在出了一系列的測試版之後，終歸會有一個正式版本，一般情況下，release不會以單詞形式出現在軟體封面上，取而代之的是符號 (Rel) 。release版本發布時，必須將待發布的軟體和相應版本更新記錄打包在一起發出。
例子：V1.0.1 Build090305 Rel111123
3. 許可權限制
如果項目本身需要對項目組成員作不同的許可權控制，可以考慮維護兩個工程：一個工程裡面有相應的源文件，一個則只有編譯後的文件。
4. 模塊的版本維護
1. 文件一般不需要版本，但要有詳細的更新歷史記錄；
2. 模塊可以以版本來維護，具體可以不同的文件夾區分。

② linux刪除文件 空間沒有被釋放

通過你的描述，結合你的問題分析如下：

問題分析：

一般說來不會出現刪除文件後空間不釋放的情況，但是也存在例外，比如文件被進程鎖定，或者有進程一直在給這個文件寫數據等等，此時即使刪除了文件，但是文件的指針還處於被鎖定的狀態，所以空間也就沒能夠被釋放。

查看被刪除的文件列表：

通過 lsof 命令 ，來獲取一個已經被刪除但仍然被相關的應用程序佔用的文件列表。

lsof | grep delete

解決辦法：

方法1、就是關閉或者重啟相關的進程。

方法2、當然也可以重啟操作系統，不過這並不是最好的方法，對於這種進程不停對文件進行寫入的操作，要想釋放文件所佔用的磁碟空間，最好的方法就是在線清空這個文件，這里我就以svn.log 文件為例，可以通過如下命令完成：

[root@SVN~]# echo " " >/tmp/svn.log

通過這種方法，磁碟空間不但可以馬上釋放，也可保障進程繼續向文件寫入日誌。

擴展知識：

我們在文件系統中存儲的文件，主要分為兩個部分：數據部分和指針部分。當我們的數據被刪除後，文件所對應的指針也會被刪除。這樣文件數據部分佔用的空間就會 被新的內容所覆蓋。

溫馨提示：

我們在刪除文件時，一定要備份，尤其是對於生產環境，這種操作一定要慎重，慎重使用 rm 命令，最好使用mv 命令來代替rm 。

以上就是我的建議，不同版本系統，在具體操作時，可能會有出入，如有問題可私信+關注，我會第一時間來進行回復追答，希望我的回答能幫到你。

③ Windows與Linux下SVN怎樣使用

Windows與Linux下SVN怎樣使用?

本文分2個部分(包括Windows與Linux操作系統平台),第1部分:怎樣安裝 第2部分:怎樣使用
-----------------------------------------第1部分:怎樣安裝-----------------------------------------
怎樣安裝分2種情況,第1種:在公司上班 第2種:在宿舍電腦
--------------------第1種:在公司上班--------------------
說明:通常SVN伺服器是安裝在windows上的,安裝好後,客戶端2種平台都能使用
Windows平台下
服務端與客戶端:
通常這種情況,你想安裝,公司都不會讓你安裝,一般是由公司內網管專業人士統一安裝好,並給你分配好賬戶與密碼,以及每個SVN下使用許可權,所以這種情況你可以不用去管怎樣安裝了,只管怎樣使用即可
linux平台下
服務端:即windows上的服務端
客戶端:如果你在本機安裝的Linux虛擬機,通常是自己安裝的,不是公司網管安裝的,安裝辦法如下:
1步即能安裝:在linux下輸入命令 sudo apt-get install subversion
即SVN,安裝後同windows上SVN一樣,只不過這里是輸入命令而已
--------------------第2種:在宿舍電腦--------------------
Windows與Linux平台下
說實在的,宿舍就1台電腦.本來電腦就垃圾.而且還開著虛擬機,在開2個VS2010,就已經卡的要死.在來個SVN,估計會慢如蝸牛,其實大部分程序員也是只有一台電腦,安裝SVN真的沒必要.除非有多台電腦.SVN本質是為方便團隊開發
-----------------------------------------第2部分:怎樣使用-----------------------------------------
怎樣使用要分2種情況,第1種:是Windows平台 第2種:是Linux平台
--------------------第1種:是Windows平台--------------------
1.更新
右鍵->SVN更新
2.提交(也可說成是上傳)
第1步:進入要提交的SVN文件目錄裡面,導入文件
第2步:導入後,返回上一層目錄,即返回到要提交的SVN文件目錄,右鍵點擊此SVN目錄,彈出,提交,進入
第3步:進入提交對話框後,會顯示2個編輯框,上面的編輯框是確認要提交的內容,下面的編輯框是你剛導入的文件內容,
你現在若是想提交剛才導入的內容,就把下面編輯框的內容用滑鼠拖動到上面的編輯框,並按確定
若不想提交剛才導入的內容,直接按取消退出即可
3.導出
即怎樣去掉SVN的專用標志,有的是對勾,有的是?號等等?
方法 1:在文件屬性--->選擇顯示所有文件,這時文件里會出現1個.svn的文件目錄,把它刪掉即可.(文件目錄多時,不推薦)
方法 2:在SVN右鍵--->導出,這時導出的文件不會帶SVN標志了
4.刪除
在SVN右鍵中,刪除之後.要返回上一層目錄,點提交.
刪除信息在變更列表,要拖動到信息欄下,然後點確定
5.保存認證
每當電腦密碼更改時,SVN以前保存的密碼也會要更新,此時會彈出一個認證框,重新輸入賬號與新密碼,在保存認證處打勾即可
--------------------第2種:是Linux平台--------------------
1.更新
命令:svn update
2.提交(也可說成是上傳)
第1步:進入要提交的SVN文件目錄裡面,
第2步:添加要提交的目錄用svn add *----------->注:(*代表添加文件、目錄或符號鏈)
第3步:提交
(1)提交全部
svn ci -m"*"----------->m表示寫注釋,*代表注釋內容
注:在LINUX上同一目錄存在其它文件,svn ci提交時,只會提交SVN伺服器已有的文件.如果想讓同一目錄下的其它文件也提交到SVN伺服器,可以先通過svn add先添加此文件或文件夾等
(2)提交單個
svn ci -m"add select_area packet" Gateway_Handler.cpp
後面一個加上要提交的文件(記的把後綴名寫上去).
提交成功後會提示
Sending Gateway_Handler.cpp
Transmitting file data .
Committed revision 242.
3.保存認證
每當電腦密碼更改時,SVN以前保存的密碼也會要更新,此時會顯示要輸入密碼,重新輸入賬號與新密碼,最後會提示是否要保存密碼(yes/no),選yes即可
4.下載
命令 svn co * (*代表下載地址,例如http://192.168.1.101/project/servers/command)
之後會在當前目錄下,導出一個command文件夾,裡面是SVN伺服器上的文件
5.刪除
svn del *(*為文件名,或文件)
6.查看修改後的操作是哪些
svn diff

---------------------------------------------------以下是摘抄的---------------------------------------------------
1、將文件checkout到本地目錄
svn checkout path（path是伺服器上的目錄）
例如：svn checkout svn://192.168.1.1/pro/domain
簡寫：svn co

1、將文件checkout到本地目錄
svn checkout path（path是伺服器上的目錄）
例如：svn checkout svn://192.168.1.1/pro/domain
簡寫：svn co
2、往版本庫中添加新的文件
svn add file
例如：svn add test.php(添加test.php)
svn add *.php(添加當前目錄下所有的php文件)
3、將改動的文件提交到版本庫
svn commit -m 「LogMessage「 [-N] [--no-unlock] PATH(如果選擇了保持鎖，就使用–no-unlock開關)
例如：svn commit -m 「add test file for my test「 test.php
簡寫：svn ci
4、加鎖/解鎖
svn lock -m 「LockMessage「 [--force] PATH
例如：svn lock -m 「lock test file「 test.php
svn unlock PATH
5、更新到某個版本
svn update -r m path
例如：
svn update如果後面沒有目錄，默認將當前目錄以及子目錄下的所有文件都更新到最新版本。
svn update -r 200 test.php(將版本庫中的文件test.php還原到版本200)
svn update test.php(更新，於版本庫同步。如果在提交的時候提示過期的話，是因為沖突，需要先update，修改文件，然後清除svn resolved，最後再提交commit)
簡寫：svn up
6、查看文件或者目錄狀態
1）svn status path（目錄下的文件和子目錄的狀態，正常狀態不顯示）
【?：不在svn的控制中；M：內容被修改；C：發生沖突；A：預定加入到版本庫；K：被鎖定】
2）svn status -v path(顯示文件和子目錄狀態)
第一列保持相同，第二列顯示工作版本號，第三和第四列顯示最後一次修改的版本號和修改人。
註：svn status、svn diff和 svn revert這三條命令在沒有網路的情況下也可以執行的，原因是svn在本地的.svn中保留了本地版本的原始拷貝。
簡寫：svn st
7、刪除文件
svn delete path -m 「delete test fle「
例如：svn delete svn://192.168.1.1/pro/domain/test.php -m 「delete test file」
或者直接svn delete test.php 然後再svn ci -m 『delete test file『，推薦使用這種
簡寫：svn (del, remove, rm)
8、查看日誌
svn log path
例如：svn log test.php 顯示這個文件的所有修改記錄，及其版本號的變化
9、查看文件詳細信息
svn info path
例如：svn info test.php
10、比較差異
svn diff path(將修改的文件與基礎版本比較)
例如：svn diff test.php
svn diff -r m:n path(對版本m和版本n比較差異)
例如：svn diff -r 200:201 test.php
簡寫：svn di
11、將兩個版本之間的差異合並到當前文件
svn merge -r m:n path
例如：svn merge -r 200:205 test.php（將版本200與205之間的差異合並到當前文件，但是一般都會產生沖突，需要處理一下）
12、SVN 幫助
svn help
svn help ci
——————————————————————————
以上是常用命令，下面寫幾個不經常用的
——————————————————————————
13、版本庫下的文件和目錄列表
svn list path
顯示path目錄下的所有屬於版本庫的文件和目錄
簡寫：svn ls
14、創建納入版本控制下的新目錄
svn mkdir: 創建納入版本控制下的新目錄。
用法: 1、mkdir PATH…
2、mkdir URL…
創建版本控制的目錄。
1、每一個以工作副本 PATH 指定的目錄，都會創建在本地端，並且加入新增
調度，以待下一次的提交。
2、每個以URL指定的目錄，都會透過立即提交於倉庫中創建。
在這兩個情況下，所有的中間目錄都必須事先存在。
15、恢復本地修改
svn revert: 恢復原始未改變的工作副本文件 (恢復大部份的本地修改)。revert:
用法: revert PATH…
注意: 本子命令不會存取網路，並且會解除沖突的狀況。但是它不會恢復
被刪除的目錄
16、代碼庫URL變更
svn switch (sw): 更新工作副本至不同的URL。
用法: 1、switch URL [PATH]
2、switch –relocate FROM TO [PATH...]
1、更新你的工作副本，映射到一個新的URL，其行為跟「svn update」很像，也會將
伺服器上文件與本地文件合並。這是將工作副本對應到同一倉庫中某個分支或者標記的
方法。
2、改寫工作副本的URL元數據，以反映單純的URL上的改變。當倉庫的根URL變動
(比如方案名或是主機名稱變動)，但是工作副本仍舊對映到同一倉庫的同一目錄時使用
這個命令更新工作副本與倉庫的對應關系。
17、解決沖突
svn resolved: 移除工作副本的目錄或文件的「沖突」狀態。
用法: resolved PATH…
注意: 本子命令不會依語法來解決沖突或是移除沖突標記；它只是移除沖突的
相關文件，然後讓 PATH 可以再次提交。
18、輸出指定文件或URL的內容。
svn cat 目標[@版本]…如果指定了版本，將從指定的版本開始查找。
svn cat -r PREV filename > filename (PREV 是上一版本,也可以寫具體版本號,這樣輸出結果是可以提交的)
19、查找工作拷貝中的所有遺留的日誌文件，刪除進程中的鎖。
當Subversion改變你的工作拷貝（或是.svn中的任何信息），它會盡可能的小心，在修改任何事情之前，它把意圖寫到日誌文件中去，然後執行log文件中的命令，然後刪掉日誌文件，這與分類帳的文件系統架構類似。如果Subversion的操作中斷了（舉個例子：進程被殺死了，機器死掉了），日誌文件會保存在硬碟上，通過重新執行日誌文件，Subversion可以完成上一次開始的操作，你的工作拷貝可以回到一致的狀態。
這就是svn cleanup所作的：它查找工作拷貝中的所有遺留的日誌文件，刪除進程中的鎖。如果Subversion告訴你工作拷貝中的一部分已經「鎖定」了，你就需要運行這個命令了。同樣，svn status將會使用L 顯示鎖定的項目：
$ svn status L somedirM somedir/foo.c $ svn cleanup$ svn statusM somedir/foo.c20、拷貝用戶的一個未被版本化的目錄樹到版本庫。svn import命令是拷貝用戶的一個未被版本化的目錄樹到版本庫最快的方法，如果需要，它也要建立一些中介文件。
$ svnadmin create /usr/local/svn/newrepos $ svn import mytree file:///usr/local/svn/newrepos/some/project Adding mytree/foo.c Adding mytree/bar.c Adding mytree/subdir Adding mytree/subdir/quux.h Committed revision 1.
在上一個例子里，將會拷貝目錄mytree到版本庫的some/project下：
$ svn list file:///usr/local/svn/newrepos/some/project bar.c foo.c subdir/
注意，在導入之後，原來的目錄樹並沒有轉化成工作拷貝，為了開始工作，你還是需要運行svn checkout導出一個工作拷貝。
另附：為SVN加入Email通知
可以通過Subversion的Hook腳本的方式為SVN加入郵件列表功能
編譯安裝了Subversion後 在源碼的tools 下有一個comm-email.pl的Perl腳本，在你的檔案目錄下有一個hooks目錄，進入到hooks目錄把post-commit.tmpl 改名為post-commit並給它可執行的許可權。
更改post-commit腳本 把comm-email.pl腳本的決對路徑加上，否則 SVN找不到comm-email.pl
REPOS="$1"
REV="$2"
/usr/local/svn/resp/commit-email.pl "$REPOS" "$REV" [email protected] [email protected]
#log-commit.py --repository "$REPOS" --revision "$REV"
最後一行是用來記日誌的 我不用這個功能 所以注釋掉了.

-------------------------------------------------------------------------------------------------------
注意:為保證代碼安全.最好要備份.每個操作都要謹慎