好的技術問題通常會引出技術專家們依據經驗得出的深層次的觀點。但對于這樣的問題的答案也很容易演變成完全基于個人喜好的情緒傾泄，而不是根據事實、標準和具體的專業知識。比如本文的這個標題，如果你是一個SVN的堅定支持者，你完全可以把這句話反過來問。
我使用SVN有5年的歷史了，而且現在在公司里仍然是使用SVN。但是大概在3年前，我的所有個人項目都已經遷移到了git(gitHub)上。我能想出很多git優于subversion的地方，大部分是體現在分布式優于集中式的特征上，但如果你讓我說出任何SVN分過來勝過git的地方，我竟一時想不出來一個。但這能說明git完勝SVN嗎?
事實當然不是這樣，像是Windows和Linux，你不能說這個一定比那個好。近在stackexchange的討論讓我學習了不少。先舉個簡單的例子證明有些地方你只能用SVN而不能用git。谷歌的搜索排名算法，不能放到分布式開放的代碼庫了。這種情況下SVN的集中式管理是不二選擇。下面來條理的看看Subversion在哪些環境下比git更適用。
Subversion
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自動的執行了同步代碼的功能。
