新項目的目錄結構說明：
代碼分三部分
1、01_Trunk（開發主干）
2、02_Branches（開發分支）
3、03_Tags（提交代碼區）
文檔區
請注意SVN的路徑是區分大小寫的！
與VSS的區別：
1、不能單獨一個文件檢出，只能檢出相應的目錄
建議：開發人員在參與一個項目的時候，首次可以將該項目下所有資料都進行檢出，一個是便於查看，另一個是保證目錄結構的統一和完整性，以免提交的時候，由於目錄的混亂導致提交出錯；
2、將一個項目的源碼復制到另一項目中時,不能直接復制,要清除那此隱藏的.SVN文件夾,最好是在SVN上使用導出功能。否則，易在提交文件時錯誤提交到原來項目之上。
因為導出目錄的時候，SVN會在所有與配置庫關聯的每個文件夾下都生成一個.svn的文件夾，這個SVN的文件夾中就記錄了你當前工作副本的版本號，關聯的配置庫路徑等信息，如對整個文件夾進行復制，會將該文件夾也復制，這樣，就算你拷貝到別的文件夾下，所關聯的配置庫信息還是原來的，提交還是會提交到原先關聯的配置庫路徑的；
建議：盡量不要對目錄進行復制，系統最好設置成，文件夾選項--查看--顯示隱藏的文件和文件夾 如需要復制整個目錄，有兩種方法，一種是直接用 版本庫瀏覽器進行操作，右鍵是可以直接復制的 具體是：選中相應的文件夾，右鍵—復制到 即可
3、如果該目錄沒有寫的權限時，會在提交的時候，顯示一條錯誤信息，看到后面的錯誤編碼是403錯誤，一般是這個目錄沒有寫的權限，需申請，呵呵；同理，如果對該目錄沒有讀的權限，在版本庫瀏覽器中，點擊該目錄，也是會出現403錯誤；但現在，一般如果是項目組成員的話，我都會開通各個目錄的讀權限的，至少給大家看的權限，呵呵
4、SVN的工作模式與VSS不同，不是采用鎖定-編輯-鎖定的模式，即可以多人同時檢出，只在提交的時候提示沖突，要求解決沖突；
SVN使用要訣——先更新后提交
為避免頻繁的解決沖突，一些經常沖突的文件，可以在提交的時候選擇：保持鎖定，這樣別人在更新該文件到本地時，默認的文件屬性是只讀的；
5、用Eclipse開發需注意的事項：
.class文件夾不要提交到SVN配置庫上受控，否則編譯的.class中，
SVN一些容易混淆的概念解釋：
1、Checkout（檢出）與Export（導出）
兩者都是獲取文件，區別在於，check out方式獲取文件后，文件處於版本控制中，而export是導出當前版本的數據，文件脫離了SVN版本控制。
2、Relocate（重定位）與Switch（切換）
如果你的版本庫移動了，或許是因為移動到了一個新的目錄，或者是域名改變，你需要“relocate”你的工作副本，這樣你的版本庫URL指向新的地址，這種情況下，是版本庫本身移動了；
如果要在同一個版本庫中切換一個分支或目錄，就需要執行Switch操作。當主干和分支只有微小差別時，這個命令非常有用，你可以在目錄之間跳轉，而只會有很小區別需要傳輸。
3、Delete（刪除）
刪除文件要使用“TortoiseSVN—Delete”進行刪除，一定不要直接刪除（對於重命名、移動文件或文件夾也是一樣，要使用TortoiseSVN的菜單進行這些操作，否則之前的版本信息會丟失。）；文件被刪除后，該文件的所有修改歷史仍然保存在SVN服務器中，以后仍然可以獲得該文件的修改歷史。
4、Commit（提交）
進行了任何修改后，通過Commit操作可以將修改提交到服務器的版本倉庫中。在工作復本的文件夾的空白處點擊鼠標右鍵和選中當前目錄執行提交的效果一樣；
提交文件要慎重，盡量不要提交不需要或不能提交的文件，包括以下幾類文件：
Ø 臨時文件*tmp、垃圾文件：為了避免提交這類文件，就盡量不要直接Commit，選擇全部文件提交，而是先執行Add操作選擇需要添加的文件，這適合提交文件數目較少的情況，當然，如果你的電腦設置的可以顯示這類隱藏文件，你就直接刪了它們，以除后患，如果你有定期清理電腦垃圾文件的習慣，這類文件就自然會被清理掉；
Ø 編譯器產生的文件，例如*.obj，生成的二進制文件等，常有些同事不注意把Debug和Release目錄都Commit了！其實，“TortoiseSVN—Settings—General”中有一個設置“Global ignore pattern”（全局忽略模式），通過在模式框中輸入文件名或擴展名就可以在提交時忽略這些文件或文件夾。不同的模式之間以空格分隔，例如*/bin */obj *.bak *.~?? *.jar *.[Tt]mp；
Ø 病毒文件：在實際中，真的碰到有同事把病毒文件都提交到SVN版本庫中了，這不是害人嗎，因此首先要養成定期殺毒的良好習慣，其次在提交時一定不要一股腦全盤提交！
提交文件還要養成以下良好習慣：
Ø 提交時一定要寫備注，而且要寫有意義的備注。備注有助於人（包括三個月后的你自己）理解你對文件所做的修改；其次在檢出歷史版本時，清晰的日志有助於快速查找到自己所需要的版本；
Ø 把握Commit的頻率。不能太頻繁，每修改一個小小的地方就提交，則會產生很多版本；而隔時間太久再提交，則其他相關人員不能及時獲取你的改動，在提交時就容易造成沖突；當然，要視團隊的具體情況而定了。
Ø 在多人協作時，盡量修改自己撰寫的部分，不要修改其他部分；這就要看團隊協作的能力了。
5、Update（更新）
Update對不同的人所做的修改會自動合並，如果無法自動合並則會發生沖突，需要手工用文件比較工具進行合並；因此要注意經常更新自己的工作復本，以保證自己能夠獲得最新的修改內容，降低發生沖突的可能性；
要養成提交前先更新的好習慣，如果沒有更新就提交，很有可能提交失敗；另外，有時候會需要通過復制文件的方式覆蓋本地的同名文件，間接的修改文件然后再提交，進行這種操作一定要慎重，如果此時服務器上的文件版本相對於你復制的文件已經修改了某些BUG，這樣提交后，以前修復的BUG就又會重現！
6、Revert（撤銷）
如果進行了修改，但沒有執行Commit操作，如果這時候想放棄這些操作，就可以通過Revert操作更新到修改之前的版本。
如果你想看看先前的某個版本是什么樣子，可以通過“TortoiseSVN—Update to reversion”，回退到選擇的版本。或者“show log”，選擇某個版本，在右鍵菜單中選擇“Browser repository”，查看選擇的版本。
在實際操作中，有時需要回退到某一個版本，但是在這個過程中可能有一些文件你想保留，也有一些文件你不想保留，這種情況下推薦的做法是：export你所需要的文件版本，覆蓋當前的文件，這樣就可以同時保留先前的文件和現在新建的文件。