svn 沖突的產(chǎn)生與解決

本文格式為Word版，下載可任意編輯——svn沖突的產(chǎn)生與解決svn沖突的產(chǎn)生與解決

1、如何產(chǎn)生沖突

當(dāng)開發(fā)人員A和開發(fā)人員B從版本庫同時(shí)檢出文檔1.txt，而A和B同時(shí)修改了1.txt的同一地方，后提交的一方會(huì)在拷貝副本中產(chǎn)生沖突。兩個(gè)工作拷貝，A拷貝中文件1.txt內(nèi)容為dfqerq123dfwre

B拷貝中文件1.txt內(nèi)容為dfqerq123erwrq

在B版本提交之前版本庫上的1.txt（base版本）內(nèi)容為dfqerq

B拷貝先提交版本到版本庫中，以至于最新版本內(nèi)容變?yōu)閐fqerq123erwrq

此時(shí)A版本也提交則會(huì)產(chǎn)生沖突，無法提交，需要先svnupdate，此時(shí)會(huì)在A拷貝中產(chǎn)生三個(gè)臨時(shí)文件1.txt.rNew\\1.txt.rOld\\1.txt.mine，其中1.txt.rNew是最新版本，1.txt.rOld是base版本，1.txt.mine是A修改后的版本，在此例中內(nèi)容為dfqerq123dfwre

而update之后A拷貝中的1.txt內(nèi)容為>>>>>>.r18

其中>>>>>>.r18之間是版本服務(wù)器上的版本

2、解決沖突

第一種，利用update的選項(xiàng)進(jìn)行沖突解決，也就是說不管當(dāng)前拷貝副本是否是最新版本，都使用—accept參數(shù)作為沖突處理方式

–acceptARG:specifyautomaticconflictresolutionaction(?postpone‘,?base‘,?mine-conflict‘,?theirs-conflict‘,?mine-full‘,?theirs-full‘,?edit‘,?launch‘)

(p)postpone–marktheconflicttoberesolvedlater//讓文件在更新完成之后保持沖突狀態(tài)。(df)diff-full–showallchangesmadetomergedfile//使用標(biāo)準(zhǔn)區(qū)別格式顯示base修訂版本和沖突文件本身的區(qū)別。

(e)edit–changemergedfileinaneditor//用你喜歡的編輯器開啟沖突的文件，編輯器是環(huán)境變量EDITOR設(shè)置的。

(r)resolved–acceptmergedversionoffile//完成文件編輯之后，通知svn你已經(jīng)解決了文件的沖突，它必需接受當(dāng)前的內(nèi)容—從本質(zhì)上講就是你已經(jīng)―解決了‖沖突。

(mf)mine-full–acceptmyversionofentirefile(ignoretheirchange//丟棄新從服務(wù)器接收的變更，并只使用你查看文件的本地修改。

(tf)theirs-full–accepttheirversionofentirefile(losemychanges)//丟棄你對(duì)查看文件的本地修改，只使用從服務(wù)器新接收的變更。

(l)launch–launchexternaltooltoresolveconflict//啟動(dòng)一個(gè)外置程序來執(zhí)行沖突解決，這需要一些預(yù)先的準(zhǔn)備。

(h)help–showthislist//顯示所有在沖突解決時(shí)可能使用的命令。

其次種，在update時(shí)并不處理沖突，利用svnresolve解決沖突

1、利用svnresolve–acceptbase選擇base版本，即1.txt.rOld作為最終提交的版本

–acceptARG:specifyautomaticconflictresolutionsource(?base‘,?working‘,?mine-conflict‘,?theirs-conflict‘,?mine-full‘,?theirs-full‘)

2、手工修改1.txt文件，然后將當(dāng)前拷貝即1.txt作為最終提交的版本svnresolve–acceptworking1.txt

3、svnresolve–accepttheirs-full1.txt使用1.txt.rNew作為最終提交的版本4、svnresolve–acceptmine-full1.txt使用1.txt.mine作為最終提交的版本

5、svnresolve–acceptmine-conflict1.txt使用1.txt.mine的沖突部分作為最終提交的版本5、svnresolve–accepttheirs-conflict1.txt使用1.txt.rNew的沖突部分作為最終提交的版本

第三種，使用svnrevert取消變更

（以上文章來源：/s/blog_65fd4c1e0100h2cg.html）－－－－－

前兩天在解決沖突時(shí)用到了svnresolve這個(gè)命令，找到這篇文章主要是由于他對(duì)–accept參數(shù)的說明比較全

比官方的文檔更詳細(xì)。

svn文件沖突,樹沖突詳解

解決沖突

偶爾，當(dāng)你從版本庫更新、合并文件時(shí)，或者切換工作副本至一個(gè)不同的URL時(shí)你會(huì)遇到?jīng)_突。有兩種沖突:

文件沖突

當(dāng)兩名(或更多)開發(fā)人員修改了同一個(gè)文件中相鄰或一致的行時(shí)就會(huì)發(fā)生文件沖突。

樹沖突

當(dāng)一名開發(fā)人員移動(dòng)、重命名、刪除一個(gè)文件或文件夾，而另一名開發(fā)人員也對(duì)它們進(jìn)行了移動(dòng)、重命名、刪除或者僅僅是修改時(shí)就會(huì)發(fā)生樹沖突。

文件沖突

當(dāng)兩名或更多開發(fā)人員修改了同一個(gè)文件中相鄰或一致的行時(shí)就會(huì)發(fā)生文件沖突。由于Subversion不知道你的項(xiàng)目的具體狀況，它把解決沖突的工作留給了開發(fā)人員。一旦出現(xiàn)沖突，你就應(yīng)當(dāng)開啟有問題的文件，查找以字符串>>>>>>版本

對(duì)于每個(gè)沖突的文件Subversion在你的目錄下放置了三個(gè)文件:

文件名.ext.mine

這是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是說，沒有沖突標(biāo)志。這個(gè)文件除了你的最新修改外沒有別的東西。

文件名.ext.r舊版本

這是在你更新你的工作副本之前的基礎(chǔ)版本(BASErevision)文件。也就是說，它是在你做最終修改之前所檢出的文件。

文件名.ext.r新版本

這個(gè)文件是當(dāng)你更新你的工作副本時(shí)，你的Subversion客戶端從服務(wù)器接收到的。這個(gè)文件對(duì)應(yīng)于版本庫中的最新版本。

你可以通過TortoiseSVN→編輯沖突運(yùn)行外部合并工具/沖突編輯器，或者你可以使用任何別的編輯器手動(dòng)解決沖突。你需要沖定哪些代碼是需要的，做一些必要的修改然后保存。

然后，執(zhí)行命令TortoiseSVN→已解決并提交人的修改到版本庫。需要注意的是已解決命令并不是真正的解決了沖突，它只是刪除了filename.ext.mine和filename.ext.r*兩個(gè)文件，允許你提交修改。

假使你的二進(jìn)制文件有沖突，Subversion不會(huì)試圖合并文件。本地文件保持不變(完全是你最終修改時(shí)的樣子)，但你會(huì)看到filename.ext.r*文件。假使你要撤消你的修改，保存版本庫中的版本，請(qǐng)使用還原(Revert)命令。假使你要保持你的版本覆蓋版本庫中的版本，使用已解決命令，然后提交你的版本。

你可以右擊父文件夾，選擇TortoiseSVN→已解決...，使用―已解決‖命令來解決多個(gè)文件。這個(gè)操作會(huì)出現(xiàn)一個(gè)對(duì)話框，列出文件夾下所有有沖突的文件，你可以選擇將哪些標(biāo)記成已解決。

樹沖突

當(dāng)一名開發(fā)人員移動(dòng)、重命名、刪除一個(gè)文件或文件夾，而另一名開發(fā)人員也對(duì)它們進(jìn)行了移動(dòng)、重命名、刪除或者僅僅是修改時(shí)就會(huì)發(fā)生樹沖突。有好多種不同的情形可以導(dǎo)致樹沖突，而且不同的情形需要不同的步驟來解決沖突。

當(dāng)一個(gè)文件通過Subversion在本機(jī)刪除后，文件也從本機(jī)文件系統(tǒng)中刪除。因此即使它是樹沖突的一部分，卻既不能顯示沖突的疊加圖標(biāo)也不能通過右鍵單擊來解決沖突。使用檢查修改對(duì)話框來獲得編輯沖突選項(xiàng)。

TortoiseSVN能夠協(xié)助找到合并更改的正確位置，但是需要作一些額外的工作來整理沖突。請(qǐng)牢記:當(dāng)進(jìn)行一次更新操作后，工作副本的基礎(chǔ)文件將會(huì)包括每一個(gè)項(xiàng)目在執(zhí)行更新操作時(shí)版本庫中的版本。假使你在進(jìn)行更新后再撤銷更改，工作副本將返回到版本庫的狀態(tài)，而不是你開始進(jìn)行更改前的狀態(tài)。

本地刪除，當(dāng)更新時(shí)有更改進(jìn)入

1.開發(fā)人員A修改Foo.c并將其提交至版本庫中

2.開發(fā)人員B同時(shí)在他的工作副本中將文件Foo.c改名為Bar.c，或者僅僅是刪除了Foo.c或它的父文件夾。

更新開發(fā)人員B的工作副本會(huì)導(dǎo)致樹沖突:

??

在工作副本中，F(xiàn)oo.c被刪除了，但是被標(biāo)記為樹沖突。

假使沖突是由于更改文件名引起的而不是刪除文件引起的，那么Bar.c被標(biāo)記為添加，但是其中卻不包括開發(fā)人員A修改的內(nèi)容。

開發(fā)人員B現(xiàn)在必需做出選擇是否保存開發(fā)人員A的更改。在更改文件名的案例中，他可以將Foo.c的更改合并到改名后的文件Bar.c中去。對(duì)于刪除文件或文件夾的案例中，他可以選擇保存包含開發(fā)人員A更改內(nèi)容的項(xiàng)目并放棄刪除操作?；蚴裁匆膊蛔龆苯訉_突標(biāo)記為已解決，那樣他實(shí)際上丟棄了開發(fā)人員A的更改。

假使TortoiseSVN能夠找到被改名為Bar.c的原始文件，沖突編輯對(duì)話框?qū)⒖梢院喜⒏摹＿@取決于在什么地方調(diào)用更新操作，它可能不能找到原始文件。

本地更改，當(dāng)更新時(shí)有刪除進(jìn)入

1.開發(fā)人員A將文件Foo.c改名為Bar.c并將其提交至版本庫中。2.開發(fā)人員B在他的工作副本中修改文件Foo.c?；蛘咴谝粋€(gè)文件夾改名的案例中...

1.開發(fā)人員A將父文件夾FooFolder改名為BarFolder并將其提交至版本庫中。2.開發(fā)人員B在他的工作副本中修改文件Foo.c。

更新開發(fā)人員B的工作副本會(huì)導(dǎo)致樹沖突。對(duì)于一個(gè)簡(jiǎn)單的文件沖突:

??

Bar.c被當(dāng)作一個(gè)正常文件添加到工作副本中。Foo.c被標(biāo)記為添加(包括其歷史記錄)并且產(chǎn)生樹沖突。

對(duì)于一個(gè)文件夾沖突:

??

BarFolder被當(dāng)作一個(gè)正常文件夾添加到工作副本中。FooFolder被標(biāo)記為添加(包括其歷史記錄)并且產(chǎn)生樹沖突。Foo.c被標(biāo)記為已修改。

開發(fā)人員B現(xiàn)在需要做出決定是否接受開發(fā)人員A作出的結(jié)構(gòu)改變并且合并她的更改到新結(jié)構(gòu)下適當(dāng)?shù)奈募校蛘咧苯臃艞夐_發(fā)人員A的更改并保存本地文件。

要合并她的本機(jī)更改到新布局中，開發(fā)人員B必需先找出沖突的文件Foo.c經(jīng)過改名/移動(dòng)后在版本庫中的新文件名是什么?？梢允褂萌罩緦?duì)話框來完成這個(gè)任務(wù)。更改必需要手工合并，由于沒有方法自動(dòng)的或者簡(jiǎn)單的完成此操作。一旦更改移植完畢，沖突的路徑就是多余的并且可以刪除。在此案例中，使用沖突編輯對(duì)話框中的刪除按鈕進(jìn)行清理并將沖突標(biāo)記為已解決。

假使開發(fā)人員B認(rèn)為A的更改是錯(cuò)誤的，那么在沖突編輯對(duì)話框中她必需選擇保存按鈕。這樣就會(huì)標(biāo)記沖突的文件/文件夾為已解決，但是需要手工刪除開發(fā)人員A的更改。又是通過日志對(duì)話框幫助追蹤哪些文件移動(dòng)了。

本地刪除，當(dāng)更新時(shí)有刪除進(jìn)入

1.開發(fā)人員A將文件Foo.c改名為Bar.c并將其提交至版本庫中。

2.開發(fā)人員B將文件Foo.c改名為Bix.c更新開發(fā)人員B的工作副本會(huì)導(dǎo)致樹沖突:

???

Bix.c被標(biāo)記為添加(包括其歷史記錄)。Bar.c被添加到工作副本中，其狀態(tài)為?正常‘。Foo.c被標(biāo)記為刪除并且產(chǎn)生一個(gè)樹沖突。

要解決這個(gè)沖突，開發(fā)人員B必需找出沖突的文件Foo.c經(jīng)過改名/移動(dòng)后在版本庫中的新文件名是什么?？梢允褂萌罩緦?duì)話框來完成這個(gè)任務(wù)。

然后，開發(fā)人員B需要決定Foo.c的新文件名中的哪一個(gè)需要保存-開發(fā)人員A改的那個(gè)還是他自己改的那個(gè)。

在開發(fā)人員B手工解決沖突后，使用沖突編輯對(duì)話框中的按鈕將樹沖突標(biāo)記為已解決。

本地缺少，當(dāng)合并時(shí)有更改進(jìn)入

1.開發(fā)人員A在主干上工作，修改Foo.c并將其提交至版本庫中

2.開發(fā)人員B在分支上工作，將Foo.c改名為Bar.c并將其提交至版本庫中合并開發(fā)人員A的主干更改到開發(fā)人員B的分支工作副本會(huì)導(dǎo)致樹沖突:

??

Bar.c已經(jīng)存在于工作副本中，其狀態(tài)為?正常‘。Foo.c被標(biāo)記為缺少并產(chǎn)生樹沖突。

要解決這個(gè)沖突，開發(fā)人員B要在沖突編輯對(duì)話框中標(biāo)記文件為已解決，這樣就會(huì)將其從沖突列表中刪除。她接下來需要決定是否將缺少的文件Foo.c從版本庫中復(fù)制到工作副本中，是否將開發(fā)人員A的對(duì)Foo.c的更改和合并到改名后的Bar.c或者是否通過標(biāo)記沖突為已解決來忽略更改什么事也不做。注意，假使你將缺少的文件從版本庫中復(fù)制到工作副本中然后再標(biāo)記為已解決，你復(fù)制下來的文件將被再次刪除。你必需先解決沖突。

本地更改，當(dāng)合并時(shí)有刪除進(jìn)入

1.開發(fā)人員A在主干上工作，將Foo.c改名為Bar.c并將其提交至版本庫中2.開發(fā)人員B在分支上工作，修改Foo.c并將其提交至版本庫中

當(dāng)文件夾改名時(shí)有類似的案例，但是在Subversion1.6中還未被識(shí)別...

1.開發(fā)人員A在主干上工作，將父文件夾FooFolder改名為BarFolder并將其提交至版本庫中。2.開發(fā)人員B在分支上工作，在她的工作副本中修改Foo.c。合并開發(fā)人員A的主干更改到開發(fā)人員B的分支工作副本會(huì)導(dǎo)致樹沖突:

??

Bar.c被標(biāo)記為添加。

Foo.c被標(biāo)記為修改并產(chǎn)生樹沖突。

開發(fā)人員B現(xiàn)在需要做出決定是否接受開發(fā)人員A作出的結(jié)構(gòu)改變并且合并她的更改到新結(jié)構(gòu)下適當(dāng)?shù)奈募校蛘咧苯臃艞夐_發(fā)人員A的更改并保存本地文件。

要合并她的本機(jī)更改到新布局中，開發(fā)人員B必需先找出沖突的文件Foo.c經(jīng)過改名/移動(dòng)后在版本庫中的新文件名是什么?？梢酝ㄟ^適用于合并源碼的日志對(duì)話框來完成這個(gè)任務(wù)。沖突編輯器僅顯示工作副本的日志由于它不知道將哪個(gè)路徑的更改合并進(jìn)來，所以你需要自己找到它。更改必需要手工合并，由于沒有方法自動(dòng)的或者簡(jiǎn)單的完成此操作。一旦更改移植完畢，沖突的路徑就是多余的并且可