linuxsvn沖突解決

❶ svn沖突怎麼解決

通過SVN客戶端更新需要的文件，如果出現有感嘆號的文件，找到出現感嘆號的文件。

選擇感嘆號文件，即沖突文件，單擊滑鼠右鍵對沖突文件進行編輯操作，如下圖所示：

進入沖突編輯頁面對出現問號的部分進行調整，如下圖所示：

4
沖突文件調整過程中，可以選擇使用自己的版本或對方版本或兩個都使用，如下圖所示：

5
完成後，點擊上圖【save】進行保存，至些svn的沖突文件就處理好了，重新提交就可以。

❷ linux svn 沖突

我理解你的意思應該是說在伺服器上有一個SVN的客戶端，正常的話是從你本地客戶端修改文件上傳後，由SVN自動更新伺服器上的這個客戶端中的內容。但你直接修改了伺服器上這個客戶端中的文件，而且沒有進行commit操作，隨後在你本地客戶端又修改了這個文件，commit後SVN自動更新伺服器上那個客戶端的文件時，報告發生了沖突。

如果是這個情況，你需要對伺服器上那個SVN客戶端中的文件進行手動處理，合並你兩次修改的內容，然後用SVN對沖突的文件標記為「沖突已解決」，然後在伺服器上那個SVN客戶端執行commit操作。完了以後記得在你本地客戶端update一下，否則你在本地再改這個文件並commit的時候，本地也會報告發生沖突。

❸ svn如何解決分支沖突

1、 如何產生沖突

當開發人員A和開發人員B從版本庫同時檢出文檔1.txt，而A和B同時修改了1.txt的同一地方，後提交的一方會在拷貝副本中產生沖突。

兩個工作拷貝，A拷貝中文件1.txt內容為

dfqerq
123dfwre

B拷貝中文件1.txt內容為

dfqerq
123erwrq

在B版本提交之前版本庫上的1.txt（base版本）內容為

dfqerq

B拷貝先提交版本到版本庫中，以至於最新版本內容變為

dfqerq
123erwrq

此時A版本也提交則會產生沖突，無法提交，需要先svn

update，此時會在A拷貝中產生三個臨時文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版
本，1.txt.rOld是base版本，1.txt.mine是A作者修改後的版本，在此例中內容為

dfqerq
123dfwre

而update之後A拷貝中的1.txt內容為

<<<<<<< .mine
dfqerq
123dfwre=======
dfqerq
123erwrq>>>>>>> .r18

其中<<<<<<< .mine與=======之間表示A修改後的內容，=======與>>>>>>> .r18之間是版本伺服器上的版本

2、解決沖突

第一種，利用update的選項進行沖突解決，也就是說不管當前拷貝副本是否是最新版本，都使用—accept參數作為沖突處理方式

–accept ARG : specify automatic conflict resolution action
(『postpone』, 『base』, 『mine-conflict』,
『theirs-conflict』, 『mine-full』, 『theirs-full』,
『edit』, 『launch』)

(p) postpone – mark the conflict to be resolved later //讓文件在更新完成之後保持沖突狀態。
(df) diff-full – show all changes made to merged file //使用標准區別格式顯示base修訂版本和沖突文件本身的區別。
(e) edit – change merged file in an editor //用你喜歡的編輯器打開沖突的文件，編輯器是環境變數EDITOR設置的。
(r) resolved – accept merged version of file //完成文件編輯之後，通知svn你已經解決了文件的沖突，它必須接受當前的內容—從本質上講就是你已經「解決了」沖突。
(mf) mine-full – accept my version of entire file (ignore their change//丟棄新從伺服器接收的變更，並只使用你查看文件的本地修改。
(tf) theirs-full – accept their version of entire file (lose my changes)//丟棄你對查看文件的本地修改，只使用從伺服器新接收的變更。
(l) launch – launch external tool to resolve conflict//啟動一個外置程序來執行沖突解決，這需要一些預先的准備。
(h) help – show this list //顯示所有在沖突解決時可能使用的命令。

第二種，在update時並不處理沖突，利用svn resolve解決沖突

1、利用svn resolve –accept base選擇base版本，即1.txt.rOld作為最後提交的版本

–accept ARG : specify automatic conflict resolution source
(『base』, 『working』, 『mine-conflict』,
『theirs-conflict』, 『mine-full』, 『theirs-full』)

2、手工修改1.txt文件，然後將當前拷貝即1.txt作為最後提交的版本

svn resolve –accept working 1.txt

3、svn resolve –accept theirs-full 1.txt 使用1.txt.rNew作為最後提交的版本

4、svn resolve –accept mine-full 1.txt 使用1.txt.mine作為最後提交的版本

5、svn resolve –accept mine-conflict 1.txt 使用1.txt.mine的沖突部分作為最後提交的版本

5、svn resolve –accept theirs-conflict 1.txt 使用1.txt.rNew的沖突部分作為最後提交的版本

第三種，使用svn revert取消變更

（以上文章來源：http://blog.sina.com.cn/s/blog_65fd4c1e0100h2cg.html）

－－－－－

前兩天在解決沖突時用到了svn resolve這個命令，找到這篇文章主要是因為他對–accept參數的說明比較全

比官方的文檔更詳細。

svn文件沖突,樹沖突詳解

解決沖突

偶爾，當你從版本庫更新、合並文件時，或者切換工作副本至一個不同的 URL 時你會遇到沖突。有兩種沖突:

文件沖突

當兩名(或更多)開發人員修改了同一個文件中相鄰或相同的行時就會發生文件沖突。

樹沖突

當一名開發人員移動、重命名、刪除一個文件或文件夾，而另一名開發人員也對它們進行了移動、重命名、刪除或者僅僅是修改時就會發生樹沖突。

文件沖突

當兩名或更多開發人員修改了同一個文件中相鄰或相同的行時就會發生文件沖突。由於 Subversion 不知道你的項目的具體情況，它把解決沖突的工作留給了開發人員。一旦出現沖突，你就應該打開有問題的文件，查找以字元串<<<<<<<開頭的行。有沖突的區域用如下的方式標記:

<<<<<<< 文件名
你的修改
=======
合並自版本庫中的代碼
>>>>>>> 版本

對於每個沖突的文件 Subversion 在你的目錄下放置了三個文件:

文件名.ext.mine

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

文件名.ext.r舊版本

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

文件名.ext.r新版本

這個文件是當你更新你的工作副本時，你的 Subversion 客戶端從伺服器接收到的。這個文件對應於版本庫中的最新版本。

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

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

如果你的二進制文件有沖突，Subversion不會試圖合並文件。本地文件保持不變(完全是你最後修改時的樣子)，但你會看到filename.ext.r*文件。如果你要撤消你的修改，保留版本庫中的版本，請使用還原(Revert)命令。如果你要保持你的版本覆蓋版本庫中的版本，使用已解決命令，然後提交你的版本。

你可以右擊父文件夾，選擇TortoiseSVN → 已解決...，使用「已解決」命令來解決多個文件。這個操作會出現一個對話框，列出文件夾下所有有沖突的文件，你可以選擇將哪些標記成已解決。

樹沖突

當一名開發人員移動、重命名、刪除一個文件或文件夾，而另一名開發人員也對它們進行了移動、重命名、刪除或者僅僅是修改時就會發生樹沖突。有很多種不同的情形可以導致樹沖突，而且不同的情形需要不同的步驟來解決沖突。

當一個文件通過 Subversion 在本機刪除後，文件也從本機文件系統中刪除。因此即使它是樹沖突的一部分，卻既不能顯示沖突的疊加圖標也不能通過右鍵單擊來解決沖突。使用檢查修改對話框來獲得編輯沖突選項。

TortoiseSVN 能夠協助找到合並更改的正確位置，但是需要作一些額外的工作來整理沖突。請牢記: 當進行一次更新操作後，工作副本的基礎文件將會包括每一個項目在執行更新操作時版本庫中的版本。如果你在進行更新後再撤銷更改，工作副本將返回到版本庫的 狀態，而不是你開始進行更改前的狀態。

本地刪除，當更新時有更改進入

開發人員 A 修改 Foo.c 並將其提交至版本庫中

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

更新開發人員 B 的工作副本會導致樹沖突:

在工作副本中，Foo.c 被刪除了，但是被標記為樹沖突。

如果沖突是由於更改文件名引起的而不是刪除文件引起的，那麼 Bar.c 被標記為添加，但是其中卻不包括開發人員 A 修改的內容。

開發人員 B 現在必須做出選擇是否保留開發人員 A 的更改。在更改文件名的案例中，他可以將 Foo.c 的更改合並到改名後的文件 Bar.c 中去。對於刪除文件或文件夾的案例中，他可以選擇保留包含開發人員 A 更改內容的項目並放棄刪除操作。或什麼也不做而直接將沖突標記為已解決，那樣他實際上丟棄了開發人員 A 的更改。

如果 TortoiseSVN 能夠找到被改名為 Bar.c 的原始文件，沖突編輯對話框將可以合並更改。這取決於在什麼地方調用更新操作，它也許不能找到原始文件。

本地更改，當更新時有刪除進入

開發人員 A 將文件 Foo.c 改名為 Bar.c 並將其提交至版本庫中。

開發人員 B 在他的工作副本中修改文件 Foo.c。

或者在一個文件夾改名的案例中...

開發人員 A 將父文件夾 FooFolder 改名為 BarFolder 並將其提交至版本庫中。

開發人員 B 在他的工作副本中修改文件 Foo.c。

更新開發人員 B 的工作副本會導致樹沖突。對於一個簡單的文件沖突:

Bar.c 被當作一個正常文件添加到工作副本中。

Foo.c 被標記為添加(包括其歷史記錄)並且產生樹沖突。

對於一個文件夾沖突:

BarFolder 被當作一個正常文件夾添加到工作副本中。

FooFolder 被標記為添加(包括其歷史記錄)並且產生樹沖突。

Foo.c 被標記為已修改。

開發人員 B 現在需要做出決定是否接受開發人員 A 作出的結構改變並且合並她的更改到新結構下適當的文件中，或者直接放棄開發人員 A 的更改並保留本地文件。

要合並她的本機更改到新布局中，開發人員 B 必須先找出沖突的文件 Foo.c 經過改名/移動後在版本庫中的新文件名是什麼。可以使用日誌對話框來完成這個任務。更改必須要手工合並，因為沒有辦法自動的或者簡單的完成此操作。一旦更改移植完畢，沖突的路徑就是多餘的並且可以刪除。在此案例中，使用沖突編輯對話框中的刪除按鈕進行清理並將沖突標記為已解決。

如果開發人員 B 認為 A 的更改是錯誤的，那麼在沖突編輯對話框中她必須選擇保留按鈕。這樣就會標記沖突的文件/文件夾為已解決，但是需要手工刪除開發人員 A 的更改。又是通過日誌對話框幫助追蹤哪些文件移動了。

本地刪除，當更新時有刪除進入

開發人員 A 將文件 Foo.c 改名為 Bar.c 並將其提交至版本庫中。

開發人員 B 將文件 Foo.c 改名為 Bix.c

更新開發人員 B 的工作副本會導致樹沖突:

Bix.c 被標記為添加(包括其歷史記錄)。

Bar.c 被添加到工作副本中，其狀態為『正常』。

Foo.c 被標記為刪除並且產生一個樹沖突。

要解決這個沖突，開發人員 B 必須找出沖突的文件 Foo.c 經過改名/移動後在版本庫中的新文件名是什麼。可以使用日誌對話框來完成這個任務。

然後，開發人員 B 需要決定 Foo.c 的新文件名中的哪一個需要保留 - 開發人員 A 改的那個還是他自己改的那個。

在開發人員 B 手工解決沖突後，使用沖突編輯對話框中的按鈕將樹沖突標記為已解決。

本地缺少，當合並時有更改進入

開發人員 A 在主幹上工作，修改 Foo.c 並將其提交至版本庫中

開發人員 B 在分支上工作，將 Foo.c 改名為 Bar.c 並將其提交至版本庫中

合並開發人員 A 的主幹更改到開發人員 B 的分支工作副本會導致樹沖突:

Bar.c 已經存在於工作副本中，其狀態為『正常』。

Foo.c 被標記為缺少並產生樹沖突。

要解決這個沖突，開發人員 B 要在沖突編輯對話框中標記文件為已解決，這樣就會將其從沖突列表中刪除。她接下來需要決定是否將缺少的文件 Foo.c 從版本庫中復制到工作副本中，是否將開發人員 A 的對 Foo.c 的更改和合並到改名後的 Bar.c 或者是否通過標記沖突為已解決來忽略更改什麼事也不做。

注意，如果你將缺少的文件從版本庫中復制到工作副本中然後再標記為已解決，你復制下來的文件將被再次刪除。你必須先解決沖突。

本地更改，當合並時有刪除進入

開發人員 A 在主幹上工作，將 Foo.c 改名為 Bar.c 並將其提交至版本庫中

開發人員 B 在分支上工作，修改 Foo.c 並將其提交至版本庫中

當文件夾改名時有類似的案例，但是在 Subversion 1.6 中還未被識別...

開發人員 A 在主幹上工作，將父文件夾 FooFolder 改名為 BarFolder 並將其提交至版本庫中。

開發人員 B 在分支上工作，在她的工作副本中修改 Foo.c 。

合並開發人員 A 的主幹更改到開發人員 B 的分支工作副本會導致樹沖突:

Bar.c 被標記為添加。

Foo.c 被標記為修改並產生樹沖突。

開發人員 B 現在需要做出決定是否接受開發人員 A 作出的結構改變並且合並她的更改到新結構下適當的文件中，或者直接放棄開發人員 A 的更改並保留本地文件。

要合並她的本機更改到新布局中，開發人員 B 必須先找出沖突的文件 Foo.c 經過改名/移動後在版本庫中的新文件名是什麼。可以通過適用於合並源碼的日誌對話框來完成這個任務。沖突編輯器僅顯示工作副本的日誌因為它不知道將哪個路 徑的更改合並進來，所以你需要自己找到它。更改必須要手工合並，因為沒有辦法自動的或者簡單的完成此操作。一旦更改移植完畢，沖突的路徑就是多餘的並且可 以刪除。在此案例中，使用沖突編輯對話框中的刪除按鈕進行清理並將沖突標記為已解決。

如果開發人員 B 認為 A 的更改是錯誤的，那麼在沖突編輯對話框中她必須選擇保留按鈕。這樣就會標記沖突的文件/文件夾為已解決，但是需要手工刪除開發人員 A 的更改。又是通過日誌對話框幫助追蹤哪些文件移動了。

本地刪除，當合並時有刪除進入

開發人員 A 在主幹上工作，將 Foo.c 改名為 Bar.c 並將其提交至版本庫中

開發人員 B 工作在分之上，將 Foo.c 改名為 Bix.c 並將其提交至版本庫中

合並開發人員 A 的主幹更改到開發人員 B 的分支工作副本會導致樹沖突:

Bix.c 被標記為正常(未修改)狀態。

Bar.c 被標記為添加(包括其歷史記錄)。

Foo.c 被標記為缺少並且產生樹沖突。

要解決這個沖突，開發人員 B 必須先找出沖突的文件 Foo.c 經過改名/移動後在版本庫中的新文件名是什麼。可以通過適用於合並源碼的日誌對話框來完成這個任務。沖突編輯器僅顯示工作副本的日誌因為它不知道將哪個路徑的更改合並進來，所以你需要自己找到它。

然後，開發人員 B 需要決定 Foo.c 的新文件名中的哪一個需要保留 - 開發人員 A 改的那個還是他自己改的那個。

在開發人員 B 手工解決沖突後，使用沖突編輯對話框中的按鈕將樹沖突標記為已解決。

❹ svn有沖突怎麼解決

在團隊開發中很多情況都會出現，下面就來一個一個的講解一下svn中的一下應用，以及遇到問題後如何解決。在Myeclipse中一定要有安裝svn，可以在線安裝也可以離線安裝。
項目一定要是在svn中檢出出來的，還有就是做過修改的，不管會別人修改的還是自己修改的，這樣才能看出來有沒有差別，然後右擊項目找打Team的與資源庫同步，這樣就能進入同步的界面，我們就從這里開始分析。
在途中最重要的是要分析一下這個區域的東西。

分析：第一個圖標是重新同步，如果在你同步的過程中還有人提交了文件，那麼點擊這個就會重新同步；第二：一個加號的那個是你自己有沒有添加文件，如果有添加的文件上就會出現一個加號圖標，減號也一樣，如果你刪除了文件上一樣會出現一個減號的圖。第三：藍色的圖標是別人提交的東西；第四：想右的灰色箭頭是你要提交的東西或者是修改的東西；第五：如果是全部的；而第六個紅色的箭頭的是別人的東西和你提交的東西改到了同一個地方。
其實紅色箭頭是需要處理的，這是需要雙擊文件，如果在兩個文件區域沒有紅色的區域那就可以直接更新，然後在提交，如果有紅色的區域，你需要解決一下沖突，你可以把你寫的東西換到其他的行中，這樣就不會沖突了，也可以兩個改的相通即可。

❺ 試用svn時遇到文件沖突時怎麼處理

沖突有很多情況：
你update代碼並修改了，你提交前，別人已經修改並提交了，當你再提交就會有沖突；
最後把沖突的文件備份，然後更新庫上最新的到本地。再把自己的代碼合並進去就好了。

❻ 怎樣處理SVN的提交代碼沖突

方法/步驟

1
我個人認為不管是提交、更新、編輯沖突第一個操作都應該是和資源庫進行同步，項目右鍵==》Team==>於資源庫同步（這里需要注意的是你的開發環境中已經正常集成了SVN，可以直接在myeclipse中使用）具體操作如下圖

2
與SVN資源庫同步後，就會在界面上顯示如你當前的項目需要更新多少文件、提交多少文件。如下圖：

3
到這里我們知道了情況後就是操作順序的問題，我個人建議先更新沒有沖突的文件到本地，再編輯沖突文件、最後測試確認無問題再提交到SVN上。在這個界面上更新和提交的操作我就不詳細說明了，我這里想詳細說說編輯沖突。如下圖

4
在
上面的圖片中需要重點說明的是圖片2和3.編輯沖突是會出現藍色和紅色的對比框。藍色的可以點擊中間的小正方形從伺服器移動到本地，紅色的移動後還得手動
修改成一樣的，要不然還會出現沖突。這些事做完了保存一下，要保證你本地的已經有的部分和伺服器上一致，這次修改或者需要提交的是伺服器上沒有的。到這里
還要像圖3那樣標記一下為合並。
5
最後一步其實就是提交，但是我建議在提交之前還是本地運行一下看看有沒有運行錯誤、報錯之類的。確認沒有問題後就回到那個資源庫對比界面選擇提交。
http://jingyan..com/article/6b97984dbe8d881ca2b0bfc0.html

❼ 在linux中更新svn 總是出現這個是什麼問題求大神解答

skipped '.' 表示當前目錄出現沖突了哦，處理方法：
1.退到上一層執行svn cleanup清除；
2.第一種解決不了，在使用此方法，.退到上一層執行svn revert 後面跟你現在所在的路徑，中間不要截斷，直到該命令運行完成停止，在執行svn up就可以了；

❽ 更新本地文件到SVN中時有沖突如何解決

有沖突一般是可能本地與主SVN伺服器都修改了同一處地方。
解決方法,可先把本地的沖突文件刪除掉，再重新從SVN更新下來到本地。然後你再修改提交，應該就沒有問題了。
所以SVN協同工作時 一定要養成先更新 再提交的好習慣。希望可以幫到你。