svn是版本管理工具，主要幫助我們管理**提交日誌的。拋開系統來談，svn分為服務端和客戶端。就客戶端而言，有很多第三方客戶端，但是底層都是官方的命令列客戶端。
在公司的開發中，我們一般只需要配置好客戶端即可，根據公司給的使用者名稱和密碼連上公司的伺服器，從伺服器上check**，通過客戶端簽入**到伺服器。
如果我們想把自己的電腦作為伺服器，讓自己的電腦承擔著伺服器和客戶端的角色，就可以都給安裝了。
mac自帶svn客戶端。版本低，需公升級。
以下介紹一些簡單的svn操作：
1）用《搜尋
2）svn樹衝突
3） 在做總結之前我們先搞清幾個概念和規則：
①利用svn checkout，upade、merge下來的**本地，無論你如何操作及時產生衝突，也不會造成主幹上面的**混亂衝突。（記住本地產生衝突，還原到上乙個版本就行了，一定不要提交到主幹導致主幹出問題）
②本地**有衝突一定不可向主幹提交**，解決好了再提交
③merge合併**時，是分支或者主幹跟本地的**進行合併（這個概念一定要理解清楚），出現問題不要慌，大不了重新來過，反正只是本地操作而已
④建立分支是可以直接命令branchs/tag或者在trunk copy to 分支，切勿直接拷貝檔案
⑤養成開發時將(switch)切換到主幹(trunk)建立分支(branchs)，上線時切換到主幹合併(merge)分支，保持主幹的準確性
以下是衝突解決的乙個案例：
工程師a修改了a.txt的第一行，提交了。
工程師b也修改了a.txt的第一行，然後執行svn up，這時svn提示了：（以下，你開始扮演工程師b的角色了）
$ svn up
在 「a.txt」 中發現衝突。
選擇: (p) 推遲，(df) 顯示全部差異，(e) 編輯,
(mc) 我的版本, (tc) 他人的版本,
(s) 顯示全部選項:
我一般選擇p（推遲），即引入衝突到本地，不過不會影響到svn伺服器端，可以放心。
ok，開始解決衝突了。
這時，會生成幾個檔案：
a.txt a.txt.mine a.txt.r6328 a.txt.r6336
其中a.txt中包含了工程師a、b的所有修改，以<<<<<<>>>>>>分隔。
a.txt.mine是工程師b的修改，也就是未update前的a.txt。
a.txt.r6328 是工程師a提交前的版本，即未導致衝突的版本。
a.txt.r6336是工程師a提交後的版本，即導致衝突的版本。
一般，檢視a.txt就可以看到衝突的詳情了：
[yicheng@chengyi svntest]$ cat a.txt
<<<<<<< .mine
i also modify ,agndagnagasdg;
*****==
i modify this line;
>>>>>>> .r6336
然後，測試，測試！確定沒問題之後，就可以告訴svn，你解決衝突了：
svn resolve –accept working a.txt (該命令會刪除a.txt.mine a.txt.r6328 a.txt.r6336）
svn ci -m 』some comment』 a.txt
這裡需要注意的是，a.txt.mine a.txt.r6328 a.txt.r6336這幾個檔案的存在代表著有衝突產生。如果不解決衝突，就手工刪除它們，svn伺服器也會很傻的認為你解決了衝突，允許你繼續之後 的工作。但是，衝突依舊存在，你的a.txt中不但有別人的修改，還有那些討厭的<=>符號。
在衝突未解決前，試圖提交**是肯定會失敗的：
$ svn ci -m 」
svn: 提交失敗(細節如下):
svn: 提交終止: 「/path/to/svntest/a.txt」 處於衝突狀態
在使用svn update 的時候，會出現如下一些資訊：
$ svn update
u install
g readme
c bar.c
updated to revision 46.
那麼，u 開頭的資訊提示你，這個檔案在你本地沒有修改過，檔案已經根據版本庫的新版本更新了。g 開頭的資訊提示你，這個檔案在你本地已經修改過，但是和版本庫中對應的版本並沒有衝突的地方，svn已經合併更新了。而c 開頭的資訊提示你，這個檔案有點麻煩，你在本地的修改和版本庫中的版本修改的地方重疊了，也就是說，你修改了某一行，你的同事也修改了同一行。這個就需要你自己手工去解決了。當衝突發生時，要注意到有三件事情可以幫助你解決問題。
4）svn顏色標誌含義
svn使用不同的顏色表示更新結果
紫色：標識新增
棕色：標識刪除
綠色：標識成功歸併
亮紅：標識衝
將合併過來的**和衝突解決的**提交到服務端。
不同公司對**簽入簽出有不同的規範，以上過程可能不同。
及時更新**。
以上工具為smart svn
切記：先更新後提交，不然會覆蓋別人的**
如何降低衝突解決的複雜度：
1)當文件編輯完成後，盡快提交，頻繁的提交/更新可以降低在衝突發生的概率，以及發生時解決衝突的複雜度。
2)在提交時，寫上明確的message，方便以後查詢使用者更新的原因，畢竟隨著時間的推移，對當初更新的原因有可能會遺忘
3)養成良好的使用習慣，使用svn時每次都是先更新，後提交。每天早上開啟後，首先要從版本庫獲取最新版本。每天下班前必須將已經編輯過的文件都提交到版本庫。
4)多跟他人溝通，避免不必要的衝突。
相關資料：
版本控制工具 SVN
學習svn的 svn入門使用 伺服器 tigris svn 客戶端 tortoise svn 伺服器的搭建 tigris svn server 1.6.5 2 建立中心庫 svnadmin create d share svnrepo 3 修改許可權配置 修改conf svnserve.conf 檔...
版本控制工具SVN
及時了解團隊中其他成員的進度 輕鬆比較不同版本間的細微差別 記錄每個檔案成長的每步細節，利於成功的服用 資料共享，避免以往拷貝檔案造成的版本混亂 人人為我，我為人人，所有成員維護的實際是同乙個版本庫，無需專人維護所有檔案的最新版本，系統工作，大大提高團隊工作效率，無論團隊成員分布在天涯海角 svn核...
SVN 版本控制工具優化篇
svn是subversion的簡稱，是乙個開放源 的版本控制系統，相較於rcs cvs，它採用了分支管理系統，它的設計目標就是取代cvs。網際網路上很多版本控 務已從cvs遷移到subversion。說得簡單一點svn就是用於多個人共同開發同乙個專案，共用資源的目的。雖說現在很多開發者已經轉移git...