Ⅰ svn常用命令
SVN常用命令如下：
獲取本地目錄的文件或目錄：
向版本庫添加新文件：
提交改動到版本庫：
文件或目錄加鎖/解鎖：
更新到特定版本或更新工作副本：
查看文件或目錄狀態：
刪除文件：
查看日誌：
查看文件詳細信息：
比較文件差異：
合並版本差異到當前文件：
獲取幫助信息：
此外，還有一些非常用的但有用的SVN命令：
顯示版本庫下的文件和目錄列表：
創建版本控制下新目錄：
恢復本地修改：
更新工作副本至不同URL：
解決沖突文件：
輸出文件或URL內容：
這些命令涵蓋了SVN操作的大部分常用場景。
Ⅱ SVN中如何解決文件沖突
在SVN中解決文件沖突，可以按照以下步驟進行：
1. 識別沖突
2. 查看沖突文件
3. 解決沖突
打開沖突文件：首先，打開存在沖突的文件。
選擇沖突解決方案：
在本例中，通過右鍵單擊沖突文件的紅色區域，並選擇「Use this text block」，可以選擇使用當前查看的版本或另一個版本的內容來解決沖突。
4. 提交解決後的文件
5. 驗證解決結果
注意事項：
Ⅲ svn 命令行怎麼解決沖突
解決版本沖突的命令。在沖突解決之後，需要使用svn resolved來告訴subversion沖突解決，這樣才能提交更新。沖突發生時，subversion會在Work Copy中保存所有的目標文件版本（上次更新版本、當前獲取的版本，即別人提交的版本、自己更新的版本、目標文件。假設文件名是sandwich.txt，對應的文件名分別是：sandwich.txt.r1、
sandwich.txt.r2、sandwich.txt.mine、sandwich.txt）。同時在目標文件中標記來自不同用戶的更改。
解決沖突的辦法：
- 手動解決：沖突發生時，通過和其他用戶溝通之後，手動更新目標文件。然後執行svn resolved filename來解除沖突，最後提交。
- 放棄自己的更新，使用別人的更新。使用最新獲取的版本覆蓋目標文件，執行svn resolved filename並提交。
- 放棄自己的更新，使用svn revert，然後提交。在這種方式下不需要使用svn resolved。
對於svn resolved命令需要非常小心，必須是非常確定沖突已經解決才能使用。否則，會導致Subversion以為沖突解決，而使代碼庫不正確。 解決沖突詳細文檔:
http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解決沖突（合並別人的修改）
我們可以使用svn status -u來預測沖突，當你運行svn update一些有趣的事情發生了：
$ svn update U INSTALL G README C bar.c
Updated to revision 46.
U和G沒必要關心，文件干凈的接受了版本庫的變化，文件標示為U表明本地沒有修改，文件已經根據版本庫更新。G標示合並，標示本地已經修改過，與版本庫沒有重迭的地方，已經合並。
但是C表示沖突，說明伺服器上的改動同你的改動沖突了，你需要自己手工去解決。 當沖突發生了，有三件事可以幫助你注意到這種情況和解決問題： ● Subversion列印C標記，並且標記這個文件已沖突。
● 如果Subversion認為這個文件是可合並的，它會置入沖突標記—特殊的橫線分開沖突的「兩面」—在文件里可視化的描述重疊的部分（Subversion使用svn:mime-type屬性來決定一個文件是否可以使用上下文的，以行為基礎合並，更多信息可以看「svn:mime-type」一節）。
● 對於每一個沖突的文件，Subversion放置三個額外的未版本化文件到你的工作拷貝：
● filename.mine
● 你更新前的文件，沒有沖突標志，只是你最新更改的內容。（如果Subversion認為這個文件不可以合並，.mine文件不會創建，因為它和工作文件相同。） ● filename.rOLDREV
Ⅳ svn 命令行怎麼解決沖突
工程師A修改了a.txt的第一行，提交了。
工程師B也修改了a.txt的第一行，然後執行svn up，這時SVN提示了：（以下，你開始扮演工程師B的角色了）
$ svn up
在 「a.txt」 中發現沖突。
選擇: (p) 推遲，(df) 顯示全部差異，(e) 編輯,
(mc) 我的版本, (tc) 他人的版本,
(s) 顯示全部選項:
我一般選擇p（推遲），即引入沖突到本地，不過不會影響到SVN伺服器端，可以放心。
OK，開始解決沖突了。
這時，會生成幾個文件：
a.txt a.txt.mine a.txt.r6328 a.txt.r6336
其中a.txt中包含了工程師A、B的所有修改，以<<<<<<<、=======、>>>>>>>分隔。
a.txt.mine是工程師B的修改，也就是未update前的a.txt。
a.txt.r6328 是工程師A提交前的版本，即未導致沖突的版本。
a.txt.r6336是工程師A提交後的版本，即導致沖突的版本。
一般，查看a.txt就可以看到沖突的詳情了：
[yicheng@chengyi svntest]$ cat a.txt
<<<<<<< .mine
i also modify ,agndagnagasdg;
=======
i modify this line;
>>>>>>> .r6336
以上，<<<<<<< .mine和=======之間是工程師B（當前的「你」）修改的內容，=======與>>>>>>> .r6336之間是工程師A修改的內容。這時，最好的辦法是，叫上工程師A，你們一起確定這些修改是否都需要，是否相互兼容，然後留下需要的部分，刪 除<<<<<<< .mine、=======和>>>>>>> .r6336。
然後，測試，測試！確定沒問題之後，就可以告訴SVN，你解決沖突了：
svn resolve –accept working a.txt (該命令會刪除a.txt.mine a.txt.r6328 a.txt.r6336）
svn ci -m 』some comment』 a.txt
這里需要注意的是，a.txt.mine a.txt.r6328 a.txt.r6336這幾個文件的存在代表著有沖突產生。如果不解決沖突，就手工刪除它們，SVN伺服器也會很傻的認為你解決了沖突，允許你繼續之後 的工作。但是，沖突依舊存在，你的a.txt中不但有別人的修改，還有那些討厭的<=>符號。
在沖突未解決前，試圖提交代碼是肯定會失敗的：
$ svn ci -m 」
svn: 提交失敗(細節如下):
svn: 提交終止: 「/path/to/svntest/a.txt」 處於沖突狀態
在使用svn update 的時候，會出現如下一些信息：
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
那麼，U 開頭的信息提示你，這個文件在你本地沒有修改過，文件已經根據版本庫的新版本更新了。G 開頭的信息提示你，這個文件在你本地已經修改過，但是和版本庫中對應的版本並沒有沖突的地方，svn已經合並更新了。而C 開頭的信息提示你，這個文件有點麻煩，你在本地的修改和版本庫中的版本修改的地方重疊了，也就是說，你修改了某一行，你的同事也修改了同一行。這個就需要你自己手工去解決了。當沖突發生時，要注意到有三件事情可以幫助你解決問題。