svn update 沒(méi)有效果 ； svn update 無(wú)法覆蓋本地文件
一般情況下公司里的所有人都會(huì)叫你在別人修改完成時(shí)，使用update來(lái)將版本庫(kù)的代碼同步進(jìn)來(lái)。這沒(méi)有錯(cuò)。但是用過(guò)github的人都不是很理解這個(gè)命令，因?yàn)樵趃it中有commit + push和checkout + pull來(lái)分別提交和下拉版本庫(kù)，而自己的文檔一般都是在分支下完成。
！此時(shí)如果初學(xué)者，例如我，單純地把update理解為checkout的話（實(shí)際上用法很類(lèi)似?。。?，你將付出一定的代價(jià)。解釋在下文，伸手黨直接跳轉(zhuǎn) 結(jié)論。
假設(shè)在電腦1提交一個(gè)文件如下：
test
abc
svn commit -m 'first commit'
#假設(shè)此時(shí)版本為 1
當(dāng)你在另外一臺(tái)電腦2上，co 進(jìn)來(lái)時(shí)文件內(nèi)容應(yīng)當(dāng)是一樣的
此時(shí)電腦1上做修改：
test
abc
computer1 add
并且同時(shí)在電腦2上做修改：
test
computer2 add
abc
ok, 萬(wàn)事妥當(dāng)，當(dāng)電腦1提交commit -m 'second commit #假設(shè)此時(shí)版本為 2'
此時(shí)，電腦2上 進(jìn)行update會(huì)出現(xiàn)一個(gè) G 表示版本庫(kù)文件與本地文件有沖突，但是svn已經(jīng)幫你解決
電腦2的文件是這個(gè)樣子的：
test
computer2 add
abc
computer1 add
也就是說(shuō)，update并不會(huì)覆蓋你本地的工作目錄，此時(shí)電腦上的結(jié)果是svn 還有 diff 但是版本已經(jīng)成為 2 ，這就是很多人update了但沒(méi)有效果的實(shí)際例子。
那么經(jīng)過(guò)查看文檔和多方驗(yàn)證得出以下結(jié)論。
<a id="jump" name="jump">結(jié)論</a>
svn update 是這樣計(jì)算的
- 當(dāng)你的文件處于最新版本，且文件內(nèi)的修改 新于 版本時(shí)間，那么
update將無(wú)效（沒(méi)有任何效果） - 當(dāng)你的文件處于非最新版本，且有修改內(nèi)容 與 版本庫(kù)不沖突（或者
svn可以解決的沖突）update能夠正常使用，而且保留你的修改內(nèi)容，并使得版本庫(kù)的修改也更新進(jìn)來(lái)?；氐?1 狀態(tài) - 當(dāng)你的文件處于非最新版本，且沖突無(wú)法解決，
svn返回 C 也就是沖突狀態(tài)，那么你就默默解決沖突吧
可見(jiàn)事實(shí)上，svn update 的其實(shí)是為了保護(hù)你本地修改而做的先一步merge，這個(gè)是用git的同學(xué)無(wú)法簡(jiǎn)單理解的（就像我一樣），因?yàn)槠鋵?shí)svn事實(shí)上沒(méi)有分支的概念，分支也只是另開(kāi)一個(gè)文件夾，可以理解為輔主分支，所有人都是在輔主分支上干活，所以每次update的是別人的代碼，自己的工作區(qū)一定不能被覆蓋或者拋棄。
但git 的思路其實(shí)是不一樣的，每個(gè)人都有自己的分支（真分支）做完以后merge到主干（無(wú)論是輔主干還是真主干）所以每次我們需要做的僅僅是把自己的分支內(nèi)容 checkout 到自己的工作區(qū)，沒(méi)有svn 那種問(wèn)題。并且我會(huì)在本地做一些log 或者簡(jiǎn)單的測(cè)試代碼，用完即刪的那種，測(cè)完了，就可以checkout，so happy。保證自己的工作區(qū)或者版本庫(kù)是干凈的。但是svn 用久了就會(huì)發(fā)現(xiàn)本地工作區(qū)很亂，有時(shí)候commit的時(shí)候都會(huì)把一些奇怪的測(cè)試代碼（提交前你沒(méi)仔細(xì)diff的話）一并交上去。要扯到 ignore 和 ci 方式上去了，打住。
結(jié)束語(yǔ)
那么如果真的你需要覆蓋本地文件的話怎么辦呢？一種是刪除再 update，另一種是revert命令?？梢詫⒈镜匚募桶姹編?kù)文件真正同步成一模一樣。
