svn常見問題

svn常見問題

svn 2011-04-18 00:09:59 閱讀123 評論0   字號：大中小 訂閱

1. SVN 疑難解答

 

1.1. 剛剛在本目錄下執行一個提交，而後執行 "svn log"，怎麼看不到最新的提交？

「明明是剛在本目錄下執行了一次提交，爲何 "svn log"，看不到呢？」

若是您是使用分佈式版本控制工具（如 git, hg, bzr），或者使用 CVS 的用戶，會對此現象感到很是奇怪。

緣由分析:

問題的實質是 SVN 的混雜版本號。

 執行 "svn status -v" 命令能夠看到當前目錄處於混雜版本狀態。

不一樣的版本控制工具使用不一樣的方法記錄本地工做目錄下文件的狀態

分佈式版本控制工具在工做區的最頂級目錄包含惟一一個控制目錄（如 .git, .hg, .bzr ── 實際爲版本庫自己）

Subversion在每個工做目錄下都包含一個名爲 .svn 的控制目錄，記錄着每個文件以及當前目錄的版本號

相比之下，Subversion雖然採用了全局版本號，但本地記錄目錄和文件的版本散佈在各個 .svn 目錄中

當剛剛完成一次提交，僅僅該次提交涉及的文件在 .svn 控制目錄中記錄的版本號是最新的，其它的文件包括目錄自己的版本號仍是舊的。

「難道提交不該該自動更新全部文件和目錄狀態麼？」

但這是不合理的，可能因爲他人的修改破壞當前工做區，所以只有主動執行 "svn update" 命令，才進行更新。

解決辦法:

在目錄下執行一次 "svn update"，以後再執行 "svn log"，就在日誌中可以看到剛剛的提交。或者使用命令 "svn log -rHEAD:1" 也能夠看到最新提交實踐出如今 log 中。

1.2. 修改目錄屬性提交報錯：「目錄 「XXX」 已通過時」！而這個目錄當前只有我一我的在改動，沒有其餘人修改。

問題重現:

修改當前目錄下的文件，以後提交。提交完畢後，不要執行 "svn update"，直接修改當前目錄的屬性，當再次提交時報錯：

正在發送 XXX svn: 提交失敗(細節以下): svn: 目錄 「/trunk/XXX」 已通過時

緣由分析:

問題的實質仍然是 SVN 的混雜版本號。  執行 "svn status -v" 命令能夠看到當前目錄處於混雜版本狀態。

前一次的提交，並未更新當前目錄的版本號，從而致使當前目錄的版本號不是最新。當修改目錄屬性並提交時，引起 「目錄已通過時」 的錯誤。

解決方案：

在當前目錄下執行 "svn update"，以後再執行提交。

1.3. 爲何提交後，在日誌中看不到提交者 ID？提交者爲空！

若是在提交日誌中的提交者爲空，說明 Subversion 配置了容許匿名用戶提交，在正式的部署中，是不該該出現的。

解決方案：

登陸 Subversion 管理後臺，如地址： http://dev.moon.ossxp.com/pysvnmanager

檢查權限設置

刪除容許匿名用戶登陸的策略

確認在缺省版本庫([/]) 的根模組（/）中存在一條 「*=r」 或者 「*=」 的策略。

1.4. 如何更改個人口令？

進入單點登陸頁面，登陸後，訪問帳號管理界面，修改口令。如圖：

1.5. 忘記口令怎麼辦？

進入單點登陸頁面，點擊頁面中的「忘記口令」的連接。如圖：

1.6. Subversion 錯誤信息一覽表

 注意：

不一樣的客戶端（命令行，TortoiseSVN, AnkhSVN, Subclipse等）的出錯信息可能稍有不一樣。

下面表格中的出錯信息以 http://svn.moon.ossxp.com/svn/test 版本庫作示例，僅供參考。

編號	出錯信息	問題剖析	解決方案
1.	svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'http://svn.moon.ossxp.com/svn/test'	錯誤的用戶名	檢查登陸的用戶名是否輸入錯誤
	svn: 服務器發送了意外的返回值(500 Internal Server Error)，在響應 「OPTIONS」 的請求 「http://svn.moon.ossxp.com/svn/test」 中
2.	svn: OPTIONS of 'http://svn.moon.ossxp.com/svn/test': authorization failed: Could not authenticate to server: rejected Basic challenge (http://svn.moon.ossxp.com)	錯誤的口令	用正確的用戶名/口令登陸
	svn: 方法 OPTIONS 失敗於 「http://svn.moon.ossxp.com/svn/test」: 認證失敗: Could not authenticate to server: rejected Basic challenge (http://svn.moon.ossxp.com)
3.	svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'http://svn.moon.ossxp.com/svn/test'	用戶無權限	聯繫管理員，爲用戶分配權限
	svn: 服務器發送了意外的返回值(403 Forbidden)，在響應 「OPTIONS」 的請求 「http://svn.moon.ossxp.com/svn/test」 中
4.	svn: OPTIONS of 'http://www.moon.ossxp.com/svn/test': 200 OK (http://www.moon.ossxp.com)	服務器地址錯誤，是普通Web頁面，不支持SVN的 WebDAV 協議	確認輸入正確的 SVN 服務地址。能夠在瀏覽器中輸入該地址進行確認
	svn: 方法 OPTIONS 失敗於 「http://www.moon.ossxp.com/svn/test」: 200 OK (http://www.moon.ossxp.com)
5.	The version of your subversion (client) is below 1.5.0, upgrade to 1.5.0 or above. SVN below 1.5.0 can not handle mergeinfo properly. It can mess up our automated merge tracking!	是因爲客戶端的軟件版本低於1.5.0形成的。服務器端對客戶端軟件版本進行了限制，以避免對合並跟蹤破壞。	升級本地的Subversion客戶端軟件到1.5.0或以上版本。
6.	svn: This client is too old to work with working copy '.'. You need to get a newer Subversion client, or to downgrade this working copy. See http://subversion.tigris.org/faq.html#working-copy-format-change for details.	安裝了多個版本的SVN客戶端(TSVN,Subclipse,...)，且各個客戶端的版本不一致。高版本的SVN客戶端會自動更新本地工做目錄中的 .svn 目錄下的文件格式，致使舊版本的SVN客戶端不能繼續訪問該本地工做目錄	將本機安裝的全部的SVN客戶端都更新到同一個大版本，以免本地工做目錄的格式不一致
	svn: 此客戶端對於工做副本 「.」 太舊。你須要取得更新的 Subversion 客戶端，或者降級工做副本。 參見 http://subversion.tigris.org/faq.html#working-copy-format-change 以得到更詳細的信息。
7.	svn: Working copy 'trunk/src' locked svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)	異常操做致使目錄沒有解鎖。  一個簡單的重現方法：在 .svn 目錄下建立空的名爲 lock 的文件	使用命令行 "svn cleanup" 或者相似的「清理」動做刪除鎖定
	svn: 工做副本「trunk/src」已經鎖定 svn: 運行「svn cleanup」刪除鎖定 (輸入「svn help cleanup」獲得用法)
8.	日誌中沒有做者信息： ------------------------------------ r9 | (沒有做者信息) | … ossxp.com anonymous commit test	匿名提交致使沒有做者信息	檢查版本庫權限控制,禁止匿名提交
9.	正在發送 ... 傳輸文件數據.svn: 提交失敗(細節以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: 提交說明至少應包含 4 個字符, 或者太簡單了。	這是因爲用戶提交的提交說明(commit log)，太過簡單了。在提交時須要輸入有意義的 commit log。	寫有意義的提交說明，或者請求管理員更改版本庫插件
10.	增長 Logger.c 傳輸文件數據.svn: 提交失敗(細節以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: Wide character in print at /opt/svn/svnroot/myrepos/hooks/scripts/check-case-insensitive.pl line 259. 發現文件名大小寫衝突: trunk/src/Logger.c 已經存在於 logger.c	管理員設置了對新增文件是否重名（只有大小寫不一樣）的文件進行檢查。文件名只有大小寫不一樣，在Windows上進行檢出會形成麻煩	不要添加劇名（僅大小寫不一樣）文件
	增長 src/文件aBc.txt 傳輸文件數據.svn: 提交失敗(細節以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: Clash: '/trunk/src/文件aBc.txt' '/trunk/src/文件abc.txt'
11.	svn: While preparing '/home/jiangxin/tmp/svn.test/trunk/src/README.txt' for commit svn: Inconsistent line ending style	提交的文件已經設置了 svn:eol-style 屬性，可是該文本內的換行符有DOS的換行符CRLF，也有Unix換行符LF，不一致！	統一該文本文件內的換行符。Linux 下能夠用dos2unix, unix2dos, sed等命令。Windows下可用 UltraEdit 進行轉換。
	svn: 當爲提交操做準備「/home/jiangxin/tmp/svn.test/trunk/src/README.txt」時 svn: 不一致的行結束樣式
12.	svn: Failed to add file 'Makefile': an unversioned file of the same name already exists	執行更新(svn up)時報錯。由於其餘人新增一個文件到服務器，而本地卻存在一個同名文件（未版本控制）	先將本地重名文件更名，再執行 "svn up"，以後再比較、合併文件。或者執行 "svn up --force"
	svn: 增長文件 'Makefile' 失敗: 同名未版本控制的文件已存在
13.	Adding src/Makefile svn: Commit failed (details follow): svn: File '/svn/test/trunk/src/Makefile' already exists	添加新文件，提交時報錯。由於其餘人已經先於我增長了該文件。	先執行更新操做（"svn up"），再根據提示進行操做：合併/提交...
	增長 src/Makefile svn: 提交失敗(細節以下): svn: 文件「/svn/test/trunk/src/Makefile」已存在
14.	$ svn up Conflict discovered in 'Makefile'. Select: (p) postpone, (df) diff-full, (e) edit, (mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p C Makefile Updated to revision 5. Summary of conflicts: Text conflicts: 1	多人同時編輯同一個文件時，可能會遇到衝突。別人先於我提交，則當我提交時要先更新。更新可能遇到不能自動解決的衝突	使用工具進行衝突解決
	$ svn up 在 「Makefile」 中發現衝突。 選擇: (p) 推遲，(df) 顯示所有差別，(e) 編輯, (mc) 個人版本, (tc) 他人的版本, (s) 顯示所有選項: p C Makefile 更新到版本 5。 衝突概要： 正文衝突：1
15.	svn: Commit failed (details follow): svn: File 'Makefile' is out of date svn: File not found: transaction '6-d', path '/trunk/src/Makefile'	提交的文件已被他人刪除	先執行更新操做（"svn up"），再根據提示解決該樹衝突：刪除文件或繼續添加...
	svn: 提交失敗(細節以下): svn: 文件 「Makefile」 已通過時 svn: File not found: transaction '6-c', path '/trunk/src/Makefile'
16.	svn: Commit failed (details follow): svn: File or directory '/trunk/XXX' is out of date; try updating svn: resource out of date; try updating	基於舊版本修改是不容許的	先更新（"svn update"），再提交
	svn: 提交失敗(細節以下): svn: 文件或目錄 「/trunk/XXX」 已通過時；請先更新 svn: resource out of date; try updating
17.	svn: DAV request failed; it's possible that the repository's pre-revprop-change hook either failed or is non-existent svn: At least one property change failed; repository is unchanged svn: Error setting property 'log': Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook	修改提交說明等操做屬於高風險操做，由於該操做沒有被版本控制，屬於不可恢復的操做。缺省禁止。	請聯繫管理員，啓用該版本的相關鉤子，容許修改「版本屬性」。參見 管理員鉤子設置
	svn: DAV 請求失敗；多是版本庫的 pre-revprop-change 鉤子執行失敗或者不存在 svn: 至少有一個屬性變動失敗；版本庫未改變 svn: 設置屬性 「log」 出錯: Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook
18.	傳輸文件數據.svn: 提交失敗(細節以下): svn: Commit blocked by pre-commit hook (exit code 1) with output: ==================== trunk/src/File.c : 屬性 svn:mime-type 或者 svn:eol-style 沒有設置 ==================== 管理員已經啓用換行符屬性檢查。每個新添加的文件必須 指定換行符。若是 svn:mime-type 屬性爲文本文件，則 必須設置 svn:eol-style 屬性。 對於二進制文件，執行以下命令： svn propset svn:mime-type application/octet-stream path/of/file 對於文本文件，能夠執行以下命令： svn propset svn:mime-type text/plain path/of/file svn propset svn:eol-style native path/of/file 爲了不每次添加文件手動設置，能夠啓用自動屬性設置 ...	管理員啓用了檢查新文件換行符的擴展	爲新增文件設置正確的 svn:mime-type 和/或 svn:eol-style 屬性

2. TortoiseSVN 疑難解答

 

2.1. TortoiseSVN 不能安裝？全部 MSI 格式的軟件包都不能安裝了！

問題描述: 在部署 Subversion 本地環境時，有位同事的機器始終沒法安裝 TortoiseSVN 安裝包！ 據其本人講，很早就已經發現不能安裝 *.msi 格式軟件包了，但是重裝 Windows 損失太大。

解決方案: 最終發現是因爲目錄受權的問題：系統 system 帳號不能對目錄進行寫操做，當從新爲目錄設置安全權限後，解決該問題。

問題的解決過程以下：

經過 Windows 事件管理器查看到下面相關事件：

正在開始 Windows Installer 事務: E:安裝工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi。客戶端進程 ID: 4488。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Error 1305. Error reading from file E:安裝工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi. System error 1008. Verify that the file exists and that you can access it. 正在開始 Windows Installer 事務: E:安裝工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi。客戶端進程 ID: 4488。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Error 1305. Error reading from file E:安裝工具版本控制TortoiseSVN-1.5.5.14361-win32-svn-1.5.4.msi. System error 1008. Verify that the file exists and that you can access it. Windows Installer 已安裝產品。產品名稱: TortoiseSVN 1.5.5.14361 (32 bit)。產品版本: 1.5.14361。產品語言: 1033。安裝成功或錯誤狀態: 1603。 Product: TortoiseSVN 1.5.5.14361 (32 bit) -- Installation failed.

爲了查看 System error 1008 的錯誤含義，運行 net helpmsg 1008

C:> net helpmsg 1008 錯誤的引用令牌...

鼠標右鍵點擊要安裝的 *.msi 軟件包所在的目錄（本例爲： E:安裝工具版本控制），查看權限，發現：

除了管理員賬號外，還有兩個未知的用戶賬號；

未知的用戶賬號，多是因爲Windows從新安裝後，以前的Windows用戶賬號 Everyone 和 Administrators。

從新設置該目錄的權限，爲 Everyone 用戶賦予 Full 權限；

從新運行 *.msi 安裝包，成功安裝。

參考連接:

http://www.appdeploy.com/msierrors/detail.asp?id=66

http://msdn.microsoft.com/en-us/library/cc185688(VS.85).aspx

http://www.microsoft.com/downloads/details.aspx?displaylang=zh-cn&FamilyID=889482fc-5f56-4a38-b838-de776fd4138c

2.2. 爲何提交者不是我？如何修改 TortoiseSVN 的提交用戶的身份？

TortoiseSVN 緩存了認證信息，即缺省使用上一次認證成功的用戶名和口令進行提交。 若是其餘人在本身的機器上進行提交（以對方的身份認證），則本機提交都使用其餘人的用戶帳號。 這除了形成提交者信息發生錯誤外，還會形成安全問題──帳號權限可能被濫用。

解決辦法：

打開相關對話框：TortoiseSVN -> 設置 -> 已保存數據

清除認證數據

2.3. 爲何我不能像在培訓中老師操做的那樣反刪除？個人菜單中甚至沒有相關的菜單選項？

培訓中演示了反刪除，其中一種方法爲：

在工做目錄中，右鍵單擊鼠標，選擇查看日誌

在日誌中選擇要恢復的相關歷史操做，右鍵單擊，選擇「復原此版本中的變動」

自動經過一個反向合併操做完成文件的反刪除

在本地目錄中執行提交操做，才最終完成反刪除

然而，有的學員在實際操做中，第二步操做中的日誌對話框的菜單中出現不了「復原此版本中的變動」！

原來問題出在第一步。

正確的操做是：右鍵點擊工做區目錄，在彈出的菜單中選擇「查看日誌」

錯誤的操做是：右鍵點擊工做區目錄，在彈出的菜單中選擇「版本庫瀏覽器」。而後在彈出的「版本庫瀏覽器」對話框中，再點擊對應目錄，選擇「查看日誌」。

這就難怪了。反刪除或者合併操做，是在本地工做目錄完成的。而「版本庫瀏覽器」是直接操做服務器，沒有一個本地目錄相對應，所以菜單中不會出現只有對應本地目錄才能出現的命令。

2.4. 哪一個代碼比較工具好用？而且能夠進行圖形化的衝突解決？

Kdiff3 是一個很是好的選擇。Kdiff3 本來是 Linux 的 KDE 圖形環境下的一個文件比較和衝突解決工具， 支持三向文件比較，已經被移植到了 Windows 平臺。在 Windows 中安裝，會自動設置 TortoiseSVN 的相關命令行參數。

下面是 Kdiff3 的一個文件合併的界面：

 可是 Kdiff3 對中文支持存在必定的問題，中文的顯示會重疊在一塊兒，形成識別上的困難。能夠經過設置字體（Marlett, 微軟雅黑等），使得中文可以顯示徹底，可是英文則按照全角顯示。

還有其餘的比較/衝突解決工具能夠選擇：

TortoiseMerge: TSVN 自帶的缺省衝突解決工具。

Araxis Merge: Windows 平臺上的商業軟件，支持目錄和文件的比較。

Meld： Linux 上的文件比較工具

2.5. 沒法用 VS.net 2003 打開用 Subversion 檢出的項目？

這是 VS.Net 2003 的一個Bug。即只要項目下存在以 點開頭的文件或文件夾，使用了 FrontPage 擴展的 VS.NET 2003 項目就在打開項目的界面發生死鎖，致使項目沒法打開。

若是項目自己不存在兼容性問題，儘可能將 VisualStdio .Net 升級爲高版本，如 VS.NET 2005,2008 或更高。

若是因爲兼容性問題，或者因爲客戶的平臺不能輕易升級等緣由，須要使用 VS.NET 2003 的開發環境。Subversion 提供了一個解決方案。

Subversion 提供的解決方案就是，使用 _svn （如下劃線開頭的目錄而非點開頭的目錄）做爲工做區的控制目錄，取代 .svn

在 TSVN 中經過下面的對話框進行設置

注意：在設置了 Subversion 使用 _svn 做爲控制目錄後，以前以 .svn 做爲控制目錄檢出的工做區將再也不有效！反之亦然。

3. 其餘IDE 整合疑難解答

 

3.1. 報錯： 工做區版本太新

這是因爲安裝了多個 Subversion 客戶端，然而各個 Subversion 客戶端軟件的版本不一樣（大版本不一樣）。

若是同時安裝了 TortoiseSVN 和 Subclipse，若是工做區被高版本的 TSVN 訪問，工做區格式則自動更新爲最新的格式， 會致使低版本的客戶端，如 Subclipse 沒法訪問。

解決辦法：

將全部的 Subversion 客戶端版本都升級到同一個大的版本，這樣就不會形成工做區版本衝突了。

或者，若是有的客戶端還沒有推出新版本，則只能在多個客戶端選擇一個最經常使用的，其餘不經常使用的卸載。

 

3.2. 沒法安裝 AnknSVN 的 MSI 格式安裝包?

參見： TortoiseSVN 不能安裝？全部 MSI 格式的軟件包都不能安裝了！

3.3. 個人機器同時部署了 VS.NET 2003 和 VS.NET 2008，可以安裝 AnkhSVN 麼？

能夠在一臺機器中同時安裝多個版本的 AnkhSVN。

AnknSVN 事先將 Subversion 整合在 VS.NET 中。對於不一樣的版本的 VS.NET，須要安裝不一樣版本庫的 AnkhSVN。

對於 VS.NET 2003，須要安裝 AnkhSVN 1.0.x 版本

對於 VS.NET 2005,2008 以上版本，須要安裝 AnkhSVN 2.0 以上版本

4. SVN統計疑難解答

 

4.1. 爲何 Subversion 代碼分析工具得出的代碼行統計和開發工具統計出來的相差不少？

有的同事發現用開發工具統計出來的代碼行統計值比較低，而 Subversion 代碼分析工具得出的代碼行統計卻高的離譜。針對這個問題，用下列工具作了測試。

代碼行統計工具一覽：

在對代碼行工具進行覈實的過程當中，參考了下列工具：

cloc.pl: 參見 http://cloc.sourceforge.net/

wc : Unix 命令。

sloccount: 支持的語言有限。

最終得出的結論是： 在 Statsvn 提供的 Subversion 代碼統計頁面中，會出現兩個不一樣的代碼行概念：一個是歷史代碼行，一個是實際代碼行。實際代碼行和用戶開發工具統計值基本相符，歷史代碼行是一個動態的概念，可能要遠遠高出實際代碼行。

歷史代碼行

包含了對刪除文件的統計，還包含了對代碼中刪除/修改的行的統計。是版本庫特有的代碼行統計量。由於當前最新代碼的實際代碼行，並不能表明實際工做量，而整個的代碼變動歷史（包含代碼刪除和代碼修改）才能真正的反映工做量。

實際代碼行

就是咱們常說的代碼行數統計量，是當前版本庫中最新代碼的代碼量。不包含歷史更改。

測試數據略...

5. 管理員疑難解答

 

5.1. 如何建立一個新的版本庫？

建立版本庫

用超級用戶帳號，登陸 Subversion 管理後臺，在菜單中選擇 「版本管理」

點擊連接 「添加版本庫」

輸入版本庫名稱，完成建立

 對於新建立的版本庫（即沒有任何代碼提交），能夠經過管理員界面刪除新建的版本庫

爲版本庫指定管理員（版本庫管理員只有對本版本庫進行權限設置/版本庫管理等功能）

在菜單中選擇 「權限管理」

在下拉菜單選擇新建立的版本庫

在管理員文本框，輸入用逗號分隔的管理員ID列表

後續步驟

通知項目經理，版本庫已經完成建立

項目經理或者由項目經理指派管理員完成版本庫的受權

參見 權限分配

還有版本庫的插件配置也應該由項目經理配置完成

參見 版本庫功能擴展

5.2. 如何爲版本庫添加功能擴展？

Subversion 經過鉤子腳本實現功能擴展。管理員能夠經過圖形界面爲版本庫設置功能擴展。

如何訪問 Subversion 插件管理界面？

在瀏覽器中輸入 Subversion 後臺管理 URL，如： http://dev.moon.ossxp.com/pysvnmanager/

輸入管理員的用戶名和口令

從功能菜單中選擇 「版本庫管理」

選擇相應的版本庫

如圖所示：

如何添加功能擴展？

在還沒有安裝的插件列表中，選擇要安裝的插件

填寫必要的參數後，點擊按鈕 「安裝此插件」

如何刪除功能擴展？

選擇功能擴展前的選擇框

點擊頁面下方的 「刪除選擇的插件」 按鈕

如何修改/從新配置功能擴展？

在當前插件配置列表中，每一個差價的 ID 均可以點擊，點擊對應插件的英文 ID

該插件的配置界面出如今頁面的上方

修改完成後，點擊按鈕 「安裝此插件」

5.2.1. AllowRevpropChange: 容許修改版本屬性

版本屬性

版本屬性是附着於版本提交的屬性，即提交事件自己的屬性，如：提交說明、提交者ID等等。和 Subversion 通常的屬性概念不一樣，「版本屬性」沒有版本控制，一但修改不可恢復，不像 Subversion 的通常屬性每次修改都要提交，於是通常屬性被版本控制，修改不會破壞歷史。

修改版本屬性屬於不可恢復動做，所以默認是禁用的。本插件能夠開放對版本屬性的修改。 若是經過本插件啓用，最好啓用 變動郵件通知 插件，使得版本屬性的修改可以經過郵件發送出來，起到對原有版本屬性存檔以及通知的做用。

可選參數:

無

5.2.2. CapCheckMergeInfo: 禁止低版本的 SVN 客戶端訪問

Subversion 1.5 提供了合併追蹤功能，若是用舊的 SVN 客戶端( < 1.5.0 )訪問，會形成對 Subversion 合併追蹤的破壞。

啓用此插件，會禁止低版本的 SVN 客戶端提交。

可選參數:

無

5.2.3. CaseInsensitive: 檢查大小寫引發的文件名衝突

Subversion 自己對版本控制的文件、目錄等是大小寫區分的，這對於像 Windows 那樣的對文件/目錄名大小寫不區分的文件系統來講，會出現混亂的狀況。

若是在同一個目錄下提交了兩個同名文件（僅僅大小寫不一樣）

在文件系統大小寫不敏感的操做系統（如 Windows上），會形成文件的相互覆蓋等各類古怪的現象

該插件經過在提交時，檢查版本庫中現有的文件，若是發現同名（僅大小寫不一樣）文件，則終止提交，報錯。

可選參數:

無

5.2.4. CommitLogCheck: 檢查提交說明

缺省 Subversion 自己不進行提交說明檢查，用戶能夠不寫提交說明（commit log）提交。不寫提交說明是很是很差的習慣。

怎樣纔是好的提交說明（Commit Log）？

不要寫冗餘的信息。提交事件自己會包含：提交者ID，提交時間，提交的文件名稱，代碼的 differ 等。下列的提交說明包含冗餘信息，不是合格的提交說明：

"本代碼由 jiangxin 提交" （提交者ID是冗餘信息）

"今天 2009-01-01 提交" （提交時間是冗餘信息）

"添加文件 hello.cpp " （提交的文件名也是冗餘信息）

提交說明能夠包含：爲什麼作出更改 ── 實現了哪一個功能需求，改正了哪一個 Bug？

提交說明能夠包含：爲什麼如此更改 ── 實現中用到的技巧

提交說明有可能要比代碼更改量還要多

可選參數:

啓用或關閉插件

爲了不經過刪除插件禁用而形成的配置信息丟失，該插件能夠經過設置啓用/中止按鈕來啓用和關閉插件。

提交說明的最小長度

輸入大於 0 的整數。若是提交說明的字符數小於該值，則禁止提交。

匹配的模板

提交說明中必須包含的字符，如： (bug|issue)。缺省爲空。

不能出現的內容

禁止在提交說明中出現的內容，缺省爲空。

5.2.5. EmailNotify: 針對代碼變動發出郵件通知

版本庫中的數據變動（文件修改或者屬性修改），發出通知郵件。缺省爲空。

若要啓用該插件，須要爲郵件通知設置參數： 一個由多個命令行參數組成的一行文本做爲該插件的參數。格式爲

[options] email_addr [email_addr ...]

或者基於正則表達式，提供一個基於路徑的代碼變動的郵件通知。

[-m regex1] [options] [email_addr ...] [-m regex2] [options] [email_addr ...] ...

參數：

-m regex

和提交路徑相匹配的正則表達式。一個點 "." 匹配全部路徑

--from email_address

發信人地址

-r email_address

回覆郵件地址

-s subject_prefix

標題的前綴，如 [Prefix]

--diff n

不包含代碼差別（缺省包含）

示例:

全部代碼變動發送一個只讀的郵件列表： project1-commit@list.moon.ossxp.com， 回覆地址設置爲另一個可寫（容許討論）的郵件列表： project1-discuss@list.moon.ossxp.com

--from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] project1-commit@list.moon.ossxp.com

不包含代碼差別的郵件發送到一個郵件列表，包含代碼差別的郵件發送到另外的一個郵件列表

-m . --from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] --diff n project1-commit@list.moon.ossxp.com -m . --from noreply@moon.ossxp.com -r project1-discuss@list.moon.ossxp.com -s [DEV] --diff y project1-commit-with-diff@list.moon.ossxp.com

5.2.6. EolStyleCheck: 文件類型和換行符設置檢查

若是啓用該插件，則新增的文件，必須設置 svn:mime-type 和/或 svn:eol-style 屬性。

當新增長的文件的 svn:mime-type 屬性以 "text/" 開頭，或者沒有設置，則該文件必須設置 svn:eol-style 屬性，以標識該文本文件的換行符屬性。

爲什麼要設置文本文件的換行符屬性？

爲了更好的跨平臺開發，須要設置文本文件的換行符屬性。有如下幾種狀況：

若是當前的項目正在跨平臺開發（Windows 和 Linux），有的員工工做在一個平臺上，有的工做在另外的操做系統上

或者當前項目的開發語言支持跨平臺開發（如： Java, Python, PHP, C, ...）

或者當前項目是在 Linux 下開發而有的開發人員喜歡在 Windows下編輯（反之亦然）

對提交文件進行換行符檢查，避免出現混雜的換行符出現

可選參數:

無

5.2.7. ReadonlySvnMirror: SVN 工做在只讀鏡像模式，禁止用戶寫入

該擴展是爲 Subversion 分佈式部署而存在的。當 Subversion 主服務器位於遠程網絡，本地能夠創建本地鏡像而提供本地般的訪問速度。 但要限制用戶對該鏡像服務器的訪問，只有負責鏡像的專用帳號，纔可以在鏡像服務器中提交。

可選參數:

啓用或關閉插件。爲了不經過刪除插件禁用而形成的配置信息丟失，該插件能夠經過設置啓用/中止按鈕來啓用和關閉插件。

Svnsync 管理員: 僅該帳號能夠提交到該只讀 Subversion 鏡像庫。

5.2.8. TracPostCommit: Trac 與 SVN 整合

整合 SVN 與 trac（需求和缺陷跟蹤系統）。若是 subversion 的提交說明包含 ticket id，則更新對應 trac 實例的 ticket 狀態，將提交說明附加到 ticket 後。

可選參數:

啓用或關閉插件

爲了不經過刪除插件禁用而形成的配置信息丟失，該插件能夠經過設置啓用/中止按鈕來啓用和關閉插件。

Trac 環境路徑

根據 trac 實例的部署，如實填寫

此版本庫 trac 中的名稱（缺省爲空）

若是對應的 Trac 實例配置了多個版本庫，則需提供對應的版本庫別名。缺省爲空。

標記爲修復的ticket狀態

當提交代碼標記爲修復對應的 ticket（需求或者bug），Trac 中該 ticket 的狀態設置爲該值。缺省爲爲空（即 closed）

5.3. 爲新員工分配Subversion帳號的過程是如何的？

經過集中管理平臺建立新帳號。如圖所示：

該操做通常由系統管理員（帳號管理員）執行

只需建立一次帳號，用戶就自動在各個業務子系統擁有帳號。若是用戶帳號已經創建，跳過此步驟。

 注意：從事先定義好的用戶模板建立新用戶帳號，能夠避免因爲用戶組設置錯誤，致使用戶不能更改口令，或者用戶不能訪問 Subversion 服務。

訪問 Subversion 管理後臺，爲用戶分配權限。如圖所示：

該操做通常由具體項目的管理員或者項目經理執行

5.4. 拆除「核彈引爆碼」？

核彈引爆碼

是一個有趣的比喻。若是很是隱私數據或其它不該該出如今版本庫中的數據（如「核彈引爆碼」），不當心提交（檢入）到了版本庫。若是用版本庫自身的刪除功能，只是在表面刪除而已，該「核彈引爆碼」仍然能夠經過訪問版本庫歷史而查看到。從安全角度上講，是不容許的，應該從版本庫中完全刪除 ── 歷史中也不可見。

Subversion 可以完全刪除「核彈引爆碼」，可是普通用戶不行，須要管理員進行操做。（這很合理，由於版本庫安全性的另外一方面，就是數據的絕對安全 ── 一旦提交，歷史不可更改）

操做的過程以下：

用 "svnadmin dump" 命令導出版本庫到一個文件

用 "svndumpfilter" 命令過濾掉導出文件中的「核彈引爆碼」文件

再建立一個新庫，用 "svnadmin load" 命令從導出文件重建版本庫

刪除舊版本庫，將新版本庫目錄更名爲原版本庫名稱

 注意：確保新版本庫的 UUID 不變，版本庫的提交版本的編號順序也不變，整個操做對版本庫的使用者將是透明的。

參見： 管理員命令行參考

5.5. 一個版本庫拆分爲多個？多個版本合併爲一個？

參見： 管理員命令行參考

5.6. 版本庫從 CVS 到 Subverson 遷移？

參見： cvs2svn 手冊