svn訪問規則
① SVN的用戶訪問許可權設置
在svn中，"復制"其實就是讀許可權，所以你想限制能讀但不能復制，這是做不到的，你給用戶讀的許可權，他就必然可以復制
修改、刪除、增加這是寫許可權，對這些操作可以限制
② 請問SVN可不可以在互聯網上連接如果可以連接，需要操作些什麼呢，詳細說下謝謝啦~
春風沐浴的回答是一個辦法，就是把整個庫上傳到網上免費的SVN空間服務上
如果要自己架設伺服器的話，我自己架設過，具體思路是將SVN伺服器先架設在區域網上，然後通過路由器的映射將其埠開放給互聯網訪問。為了解決ADSL線路每次重新連接時隨機分配IP地址的問題，我們還需要申請一個免費域名。
下面是我的架設方法，首先你需要具備這些條件：
1、路由器1台，應有埠映射（轉發規則-虛擬伺服器）功能，最好有內置的花生殼動態DNS功能（否則就需要另外安裝花生殼軟體）。
2、SVN伺服器一台
3、ADSL或其他通往互聯網的網路線路
然後需要做以下事情：
1、架設好SVN伺服器，保證內網訪問暢通。
2、申請免費域名
登錄花生殼網站（www.oray.net），免費注冊用戶，可得到一個免費域名，如「abcde.gicp.net」此域名可長期使用；
3、登錄路由器管理頁面
通常是訪問地址http://192.168.1.1，用戶名和密碼根據設定輸入，各型號路由器的訪問方式可能略有不同，可參考說明書進行操作。
4、設置動態域名
如果路由器內置了花生殼動態DNS功能，則可通過路由器直接設置。以TL-WR340G 54M型號的無線路由器為例，在「動態DNS」頁面，選擇服務提供者為花生殼，輸入在花生殼注冊的用戶名和密碼，然後點擊登錄。
如果路由器沒有內置的花生殼動態DNS功能，則需要在花生殼網站下載花生殼客戶端軟體，安裝（可不必安裝附帶的「向日葵」組件）後使用前面申請的花生殼帳戶名和密碼進行登錄，登錄後即可使用免費域名。
5、設置埠映射
仍以TL-WR340G 54M型號的無線路由器為例，在「轉發規則-虛擬伺服器」頁面點擊「添加新條目」，在新條目的頁面中，設置埠號為項目組SVN伺服器的訪問埠號，設置IP地址為該路由器分配給項目組SVN伺服器的內網IP地址，狀態為「生效」，然後保存。
然後你就可以在互聯網上通過你申請的免費域名（如「abcde.gicp.net」）代替IP地址來訪問SVN伺服器了。
③ 如何外網訪問SVN。 公司里有SVN。我在家，如何訪問請具體描述一下。越詳細越好。
那就看你們公司的svn是怎麼架的了，要是你們公司有獨立的伺服器，或者伺服器可以對外開發，那你只需要知道地址就行了。
假設是對外放的，你們公司 也有自己的網站在同一個伺服器上，那麼假設你在公司內網訪問時時通過http://192.168.0.1:8808/svn訪問的，你們公司的網址是http://www.gongsi.com，那你在家可以通過http://www.gongsi.com:8808/svn訪問。
④ 如何做到svn根目錄不讓訪問,但子目錄可以訪問許可權設置
首先，肯定可以實現。
然後，需要了解你的SVN架設環境和許可權管理方式。
如果你的SVN伺服器是架設在Apache上的，使用的是Apache的用戶管理機制，那麼你可以在許可權文件里這么設置：比如版本庫名稱是project，這個版本庫的所有內容對於部門A（有用戶user1～user5）是全部讀寫許可權，對於部門B（有用戶user6、user7）僅對其下的fla文件夾有隻讀許可權，但其他文件夾不給任何許可權。
[groups]
DepartmentA = uaser1,uaser2,user3,user4,user5
DepartmentB = uaser6,uaser7
[project:/]
* =
@DepartmentA = rw
[project:/fla]
@DepartmentB = r如果按以上設置，部門B訪問的時候，你可以告訴他們訪問地址直接就是到fla這層文件夾，而不要到project這層文件夾。他們如果用IE訪問project這層文件夾，會因沒有許可權而無法打開，但可以直接訪問fla這層。他們如果用TortoiseSVN訪問的時候，也是同樣只能checkout檢出fla這個文件夾。
Subversion 許可權簡介在 Subversion 的使用當中，存在「認證」、「授權」兩個概念。認證，即 authentication，是指用戶名與密碼的認證。授權，即 authorization ，是指某用戶對某個目錄是否具備讀、寫許可權的一種審核。這兩者配合作用，就組成了 Subversion 的整個帳戶管理體系。
⑤ 外網如何訪問SVN伺服器
在SVN伺服器所在的區域網內，使用SVN的內網地址進行https進行訪問。正常情況下，在內網是可以正常訪問連接使用的。
⑥ SVN使用問題
svn連接不上伺服器的原因及解決方法：
1.先在瀏覽器中訪問svn地址，確保svn地址是可以正常訪問的。如果可以在瀏覽器中正常訪問，則繼續向下進行。
2.檢查svn核心
在eclipse菜單中，依次點擊，preferences -> Team -> SVN ->SVN介面
如果svn介面的選項是JavaHL(JNI)如圖1，則改換成SVNKit(PureJava)，此時再訪問svn地址即可。
圖1:
註：如果只有一個svn JavaHL(JNI)核心的話，則需要重新安裝svn插件了。
⑦ 如何遠程訪問svn 伺服器
方法有很多，最簡單的，就是你有一個外網伺服器，直接把SVN部署到外網上。但是，我們現在既沒有外網伺服器，也不能用內網伺服器做測試，也就是說，我要用本機，直接部署SVN 在外網訪問。也就是，本機就是伺服器。
首先你需要有一個自己的域名，然後埠映射SVN到域名上面，這樣就可以了。給你們分享一個獲取域名和埠映射的軟體。我個人用的就是花生殼，一個動態域名解析軟體。
⑧ svn有網路限制嗎
有。方案一：本地安全策略-->IP安全策略
由於源代碼所在伺服器操作系統為Windows Server 2008 R2，故本身具有高安全性。可以設置IP安全策略，對特定的服務埠進行控制。此方法對於只允許單個IP、少數IP可以訪問有很好效果，但是由於公司總部內網IP段比較多，故設置起來費時費力。因為要單獨放行的IP數目過多，它沒有放行一個IP段的選項。
方法的設置就不在此贅述了，網上有很多。它的效果非常明顯，也很不錯，但是由於公司應用條件的特殊要求被我廢棄使用此方案。
方案二：採用apache的Allow與Deny
在安裝完Visual SVN Server之後，在安裝目錄下的conf中，肯定能看到一些這樣的段落，LoadMole ***
Options FollowSymLinks
AllowOverride None
RewriteEngine on
??
此時只需要在Directory增加Order與Deny規則即可。具體規則可以參見apache的幫助。按照我們公司要求，我只需要如下設置：
Options FollowSymLinks
AllowOverride None
RewriteEngine on
Order Deny,Allow
Deny From All
Allow From 192.168.10 （允許10段訪問）
Allow From 192.168.20 （允許20段訪問）
Allow From 192.168.30.1 （允許此IP地址訪問）
??
好了，設置完成後，只需要重啟你的Visual SVN Server服務即可
⑨ 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. 模塊可以以版本來維護，具體可以不同的文件夾區分。
⑩ SVN怎麼讓每個人訪問不同文件
svn許可權控制是到文件夾級別的，不是到文件級別，因此你需要首先將文件夾結構設置好，每個人要看的文件分別放在不同的文件夾中，比如根目錄是aaa，下面每個人對應的目錄分別是a1、a2、a3、a4
然後在許可權文件里先設定對根目錄所有人有讀取許可權「*
=
r」，在每個人對應的目錄里設定兩條「*
=
」(所有人無任何許可權)和「username
=
r」（對應的用戶有讀取許可權）
這樣就可以實現每個人只能讀取自己的文件夾
按你所說的，你得先把test1、test2分別放到兩個文件夾中，比如根目錄aaa，a1文件夾中放test1文件，a2文件夾中放test2文件，那麼這個許可權文件就這么寫：
[aaa:/]
*
=
r
[aaa:/a1]
*
=
user1
=
r
[aaa:/a2]
*
=
user2
=
r
這樣user1、user2檢出aaa這個文件夾的時候，user1檢出的aaa中只有a1這個文件夾，user2檢出的aaa中只有a2這個文件夾
當然了，如果你要的是讀寫許可權的話，就把上面的r換成rw，另外還可以把aaa下面的「*
=
r」換成「user1
=r」和「user2
=r」這兩句
如果用戶比較多，想控制的更復雜的話，可以在許可權文件中用group設置用戶組，按組來控制許可權