好的技術(shù)問(wèn)題通常會(huì)引出技術(shù)專家們依據(jù)經(jīng)驗(yàn)得出的深層次的觀點(diǎn)。但對(duì)于這樣的問(wèn)題的答案也很容易演變成完全基于個(gè)人喜好的情緒傾泄，而不是根據(jù)事實(shí)、標(biāo)準(zhǔn)和具體的專業(yè)知識(shí)。比如本文的這個(gè)標(biāo)題，如果你是一個(gè)SVN的堅(jiān)定支持者，你完全可以把這句話反過(guò)來(lái)問(wèn)。
　　我使用SVN有5年的歷史了，而且現(xiàn)在在公司里仍然是使用SVN。但是大概在3年前，我的所有個(gè)人項(xiàng)目都已經(jīng)遷移到了git(gitHub)上。我能想出很多git優(yōu)于subversion的地方，大部分是體現(xiàn)在分布式優(yōu)于集中式的特征上，但如果你讓我說(shuō)出任何SVN分過(guò)來(lái)勝過(guò)git的地方，我竟一時(shí)想不出來(lái)一個(gè)。但這能說(shuō)明git完勝SVN嗎?
　　事實(shí)當(dāng)然不是這樣，像是Windows和Linux，你不能說(shuō)這個(gè)一定比那個(gè)好。近在stackexchange的討論讓我學(xué)習(xí)了不少。先舉個(gè)簡(jiǎn)單的例子證明有些地方你只能用SVN而不能用git。谷歌的搜索排名算法，不能放到分布式開(kāi)放的代碼庫(kù)了。這種情況下SVN的集中式管理是不二選擇。下面來(lái)?xiàng)l理的看看Subversion在哪些環(huán)境下比git更適用。
　　Subversion
　　Subversion是集中式管理的數(shù)據(jù)倉(cāng)庫(kù)
　　雖然速度快和多副本等git分布式數(shù)據(jù)倉(cāng)庫(kù)顯而易見(jiàn)的好處吸引了很多人的喜愛(ài)，但在很多情況下，一個(gè)集中式的數(shù)據(jù)倉(cāng)庫(kù)卻是更合適的。例如，如果你有一些核心代碼想只允許部分人能訪問(wèn)，把它放到git里必然是你不希望的。很多的企業(yè)都是將它們的代碼集中管理的，我猜，所有(重要)政府項(xiàng)目估計(jì)都使用的是集中式數(shù)據(jù)倉(cāng)庫(kù)的版本控制系統(tǒng)。
　　Subversion的理念符合常規(guī)思維
　　這是說(shuō)，很多人(特別是管理者或老板)對(duì)版本號(hào)有一種習(xí)慣的認(rèn)識(shí)，把開(kāi)發(fā)視作一種按時(shí)間的線性發(fā)展軌跡，這在他們腦子里根深蒂固。并不是找借口，Git的隨意性并不是很容易去理解，你也許注意到了，任何一本關(guān)于Git的書(shū)都會(huì)在第一章第一節(jié)告訴你要拋棄腦子里所有的傳統(tǒng)觀念，重新認(rèn)識(shí)。
　　Subversion只提供一種途徑，沒(méi)有第二選擇
　　SVN是一個(gè)版本控制系統(tǒng)，它只提供一種方式做這些，每個(gè)人都使用相同的方法。是這樣。這使得你將代碼從SVN遷移到其它集中式管理的VCS或從其它集中式管理的VCS遷進(jìn)來(lái)變得很容易。Git并不僅僅是一個(gè)版本控制系統(tǒng)——它實(shí)際上是一個(gè)文件系統(tǒng)，它里面有很多的拓?fù)鋵W(xué)知識(shí)來(lái)支持你如何在不同的環(huán)境中架設(shè)代碼倉(cāng)庫(kù)——并且沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)。選擇一個(gè)合適的拓?fù)浣Y(jié)構(gòu)成了難題。
　　其它一些優(yōu)勢(shì)：
　　SVN支持空目錄
　　SVN有更好的Windows平臺(tái)支持
　　SVN可以check out/clone一個(gè)子樹(shù)(sub-tree)
　　SVN支持特權(quán)訪問(wèn)控制svn lock，在處理很難合并的文件時(shí)非常有用
　　SVN支持二進(jìn)制文件，更容易處理大文件(不需要把老版本拷來(lái)拷去)
　　提交文件相對(duì)簡(jiǎn)單，因?yàn)闆](méi)有pull/push操作，本地修改通過(guò)svn update自動(dòng)的執(zhí)行了同步代碼的功能。