一、 svn系統執行示意圖：
svn的每一次提交，都會在伺服器端的db/revs 和 db/rebprops目錄下各建立乙個以順序數字編號命名的檔案。其中：
1. db/revs 目錄下的檔案（即變更集內容）記錄了與上乙個提交之間的差異（字母a表示新增，m表示修改，d表示刪除）
2. db/rebprops 目錄下同名檔案則儲存著提交日誌，作者，提交時間等資訊。
這樣設計的好處有：
1. 擁有全域性版本號。每提交一次，svn的版本號就會自動加一（全域性版本號）。這為svn的使用提供了極大的便利。回想cvs時代，每個檔案都擁有各自獨立的版本號（rcs版本號），要想獲得全域性版本號，只能通過手工不斷地建立里程碑來實現。
2.實現了原子提交。svn不會像cvs那樣出現檔案的部分內容被提交而其餘的內容沒有被提交的情況(說明svn是真個專案整體提交的)。
3. 檔名不受限制。因為伺服器端不再需要建立和客戶端檔案相似的檔名，於是，檔案的命名就不再受伺服器作業系統的字符集和大小寫的限制。
4. 檔案和目錄重新命名也得到了支援。
svn最具有特色的功能是輕量級拷貝，例如：將目錄trunk拷貝為branches/v1.x只相當於在db/revs的目錄中的變更集檔案中用特定的語法做了一下標註，無須真正的檔案拷貝。svn使用輕量級拷貝的功能，輕鬆地解決了cvs存在的里程碑和分支的建立速度慢又不可見的問題，使用svn建立里程碑和分支只在眨眼之間。
svn在版本庫授權上也有改進，不再像cvs那樣依賴作業系統本身對版本庫目錄和檔案進行授權，而是採用授權檔案的方式來實現。
svn還有乙個創舉，就是在工作區跟蹤目錄下（.svn目錄）為當前目錄中的每乙個檔案都儲存乙份冗餘的原始拷貝。這樣做的好處是部分命令不再需要網路連線，例如檔案修改的差異比較，以及錯誤更改的回退等。
但是，相對於cvs，svn在本質上並沒有突破，都屬於集中式版本控制系統。即乙個專案只有唯一的乙個版本庫與之對應，所有的專案成員都通過網路向該伺服器進行提交。這樣的設計除了容易出現單點故障以外，在檢視日誌和提交資料等操作時的延遲，會讓基於廣域網協同工作的團隊抓狂。
除了集中式版本控制系統固有的問題外，svn的里程碑和分支的設計也被證明是乙個錯誤，雖然這個錯誤的設計使得svn擁有了快速建立里程碑和分支的能力，
1. 專案檔案在版本庫中必須按照一定的目錄結構進行部署，否則就可能無法建立里程碑和分支。如： 直接在版本庫的根目錄下建立專案檔案，這樣的版本庫布局，在需要建立里程碑和分支時就無從下手了，因為根目錄是不能拷貝到子目錄中的。所以svn的使用者在建立版本庫時必須遵守乙個古怪的約定：先建立三個頂級目錄 /trunk ,/tags 和 /branches。
2. 建立里程碑和分支會破壞精心設計的授權。
svn的授權是基於目錄的，分支和里程碑也被視為目錄（和其他目錄沒有分別）。因此每次建立分支和里程碑時，就要將針對/trunk及其子目錄的授權在新建的分支或里程碑上重建。隨著分支和里程碑數量的增多，授權愈加複雜，維護也愈加困難。
3. 分支太隨意從而導致混亂。 svn的分支建立非常隨意：可以基於 /trunk 目錄建立分支，也可以基於其他任何目錄建立分支，因此svn很難畫出乙個有意義的分支圖。再加上一次提交可以同時包含針對不同分支的檔案變更，使得事情變得更糟。
4. 雖然svn在1.5版本之後擁有了合併追蹤功能，但這個功能會因為混亂的分支管理而被抵消。
Svn與Git的區別
這篇主要是談談兩者的區別，至於誰優誰劣看官自己思考吧！把第一條理解到位思想到位了做起來才會有的放矢，其他幾條都是用的時候才能體會到 1 最核心的區別git是分布式的，而svn不是分布的。能理解這點，上手會很容易，宣告一點git並不是目前唯一的分布式版本控制系統，還有比如mercurial等，所以說它...
Svn與Git的區別
1 最核心的區別git是分布式的，而svn不是分布的。能理解這點，上手會很容易，宣告一點git並不是目前唯一的分布式版本控制系統，還有比如mercurial等，所以說它們差不許多。話說回來git跟svn一樣有自己的集中式版本庫和server端，但git更傾向於分布式開發，因為每乙個開發人員的電腦上都...
Git與SVN的區別
如果你在讀這篇文章，說明你跟大多數開發者一樣對git感興趣，如果你還沒有機會來試一試git，我想現在你就要了解它了。git不僅僅是個版本控制系統，它也是個內容管理系統 cms 工作管理系統等。如果你是乙個具有使用svn背景的人，你需要做一定的思想轉換，來適應git提供的一些概念和特徵。所以，這篇文章...