SVN有任何勝過git的地方嗎？

　　好的技術問題通常會引出技術專家們依據經驗得出的深層次的觀點。但對於這樣的問題的答案也很容易演變成完全基於個人喜好的情緒傾洩，而不是根據事實、標準和具體的專業知識。就比如本文的這個標題，如果你是一個SVN的堅定支持者，你完全可以把這句話反過來問。

　　我使用SVN有5年的歷史了，而且現在在公司裡仍然是使用SVN。但是大概在3年前，我的所有個人專案都已經遷移到了git(gitHub)上。我能想出很多git優於subversion的地方，大部分是體現在分散式優於集中式的特徵上，但如果你讓我說出任何SVN分過來勝過git的地方，我竟一時想不出來一個。但這就能說明git完勝SVN嗎？

　　事實當然不是這樣，就像是Windows和Linux，你不能說這個一定就比那個好。最近在stackexchange的討論讓我學習了不少。先舉個簡單的例子證明有些地方你只能用SVN而不能用git。谷歌的搜尋排名演算法，就不能放到分散式開放的程式碼庫了。這種情況下SVN的集中式管理就是不二選擇。下面就來條理的看看Subversion在哪些環境下比git更適用。

　　Subversion是集中式管理的資料倉儲

　　雖然速度快和多副本等git分散式資料倉儲顯而易見的好處吸引了很多人的喜愛，但在很多情況下，一個集中式的資料倉儲卻是更合適的。例如，如果你有一些核心程式碼想只允許部分人能訪問，把它放到git裡必然是你不希望的。很多的企業都是將它們的程式碼集中管理的，我猜，所有(重要)政府專案估計都使用的是集中式資料倉儲的版本控制系統。

　　Subversion的理念符合常規思維

　　這是說，很多人(特別是管理者或老闆)對版本號有一種習慣的認識，把開發視作一種按時間的線性發展軌跡，這在他們腦子裡根深蒂固。並不是找藉口，Git的隨意性並不是很容易去理解，你也許注意到了，任何一本關於Git的書都會在第一章第一節告訴你要拋棄腦子裡所有的傳統觀念，重新認識。

　　Subversion只提供一種途徑，沒有第二選擇

　　SVN是一個版本控制系統，它只提供一種方式做這些，每個人都使用相同的方法。就是這樣。這使得你將程式碼從SVN遷移到其它集中式管理的VCS或從其它集中式管理的VCS遷進來變得很容易。Git並不僅僅是一個版本控制系統——它實際上是一個檔案系統，它裡面有很多的拓撲學知識來支援你如何在不同的環境中架設程式碼倉庫——並且沒有一個統一的標準。選擇一個合適的拓撲結構就成了難題。

　　其它一些優勢：

• SVN支援空目錄
• SVN有更好的Windows平臺支援
• SVN可以check out/clone一個子樹(sub-tree)
• SVN支援特權訪問控制svn lock，在處理很難合併的檔案時非常有用
• SVN支援二進位制檔案，更容易處理大檔案(不需要把老版本拷來拷去)
• 提交檔案相對簡單，因為沒有pull/push操作，本地修改通過svn update自動的執行了同步程式碼的功能。