1. linux怎麼還原rsync備份的svn文件
問題可以說具體點的。。svn文件還原很容易，rsync備份是什麼意思呢
2. 如何在阿里雲伺服器上部署SVN服務
阿里雲搭建SVN伺服器
1：安裝svn
apt-get install subversion
2. 開啟svn伺服器
svnserve -d
檢查是否開啟：ps aux | grep svnserve
若出現如下內容：
wkr 6537 0.0 0.0 13784 956 ? Ss 16:18 0:00 svnserve -d
wkr 7593 0.0 0.0 5784 864 pts/0 S+ 21:57 0:00 grep –color=auto svnserve
表示服務已開啟。（注意：一定要有第1行，只有第2行說明服務未啟動）
停止svn服務： killall svnserve
3. 建立倉庫
svnadmin create /home/svnrepos
理論上，倉庫可以建立在任何目錄中。
注意：重啟svnserve 執行 svnserve -d -r /home
這樣在eclipse客戶端把工程導入svn的時候 url需要填寫
svn://ip/svnrepos/project_name
如果啟動的時候帶如下參數：svnserve -d -r/home/svnrepos
客戶端：svn://ip/project_name 這樣子會報錯。驗證失敗
4. 修改配置文件
編輯 svnserve.conf
vi /home/svnrepos/conf/svnserve.conf
把anon-access = read 改為 none，auth_access = write
password-db = passwd authz-db = authz的注釋去掉，還有[general]的注釋也要去掉（這個默認沒有注釋）。
註：當你去掉注釋的時候，不要簡單的把前面的＃去掉，要把前面的空格一塊去掉，不然在Eclipse中使用的時候會出現配置文件格式錯誤的問題。
注意：如果authz-db = authz 這個注釋掉了，則不需要配置/home/svnrepos/conf/authz
5. 修改帳戶文件
vi /home/svnrepos/conf/passwd
### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
[users]
# harry = harryssecret
# sally = sallyssecret
user1 = pass1 # 輸入你定義的用戶名和密碼，密碼顯然沒有加密
6. 修改授權文件
gedit /home/svnrepos/conf/authz
修改或者輸入下面2行：
[svnrepos:/] ##格式為 版本庫名稱 + :/
user1 = rw
其中，repos1是倉庫名稱，user1是用戶名，rw代表讀寫。
7.客戶端連接
svn co svn://ip/oplinux
用戶名密碼:rsync
8.實現SVN與WEB同步,可以CO一個出來,也可以直接配在倉庫中
1)設置WEB伺服器根目錄為/alidata/www/webroot
2)checkout一份SVN
svn co svn://localhost/alidata/www/svndata/myproject /alidata/www/webroot
修改許可權為WEB用戶
chown -R www:www /alidata/www/webroot/myproject
3)建立同步腳本
cd /alidata/www/svndata/oplinux/hooks/
cp post-commit.tmpl post-commit
編輯post-commit,在文件最後添加以下內容
export LANG=en_US.UTF-8
SVN=/usr/bin/svn
WEB=/alidata/www/webroot/
$SVN update $WEB –username myname –password myname
chown -R www:www $WEB
增加腳本執行許可權
chmod +x post-commit
這樣，我們上傳svn後，生產站點就能立馬顯示出來了，自動化程度高了很多。
3. linux上的rsync命令詳解
rsync 就是遠程同步的意思remote sync.
rsync 被用在UNIX / Linux執行備份操作操作.
rsync 工具包被用來從一個位置到另一個位置高效地同步文件和文件夾. rsync可以實現在同一台機器的不同文件直接備份,也可以跨伺服器備份.
rsync 語法如下
從語法結構我們可以看出, 源和目標即可以在本地也可以在遠端. 如果是遠端的話,需要指明登錄用戶名, 遠端伺服器名, 和遠端文件或目錄. 同時源可以是多個, 目標位置只能是一個.
說明:
-z: --compress 使用壓縮機制
-v: --verbose 列印詳細信息
-r: --recursive 以遞歸模式同步子目錄
注意: 同步完成後, 我們會發現文件的時間戳timestamps發生了改變.
有時我們希望拷貝或同步時, 時間戳不要發生變化, 源文件是什麼時間戳,目標文件就是什麼時間戳, 這時我們需要使用 -a --archive 歸檔模式選項. -a 選項相當於7個選項的組合 -rlptgoD
-r, --recursive: 遞歸模式Recursive mode
-l, --links: 將符號鏈接當作符號鏈接文件拷貝, 不拷貝符合鏈接指向的文件內容.
-p, --perms: 保留文件許可權
-t, --times: 保留修改時間戳
-g, --group: 保留用戶組信息
-o, --owner: 保留用戶信息(需要超級用戶許可權)
-D, 相當於 --devices --specials 的組合, 保留設備文件, 保留特殊文件.
同步完成後, 我們再來看文件屬性, 時間戳信息得到了保留, 不僅如此文件的所有者 和所在組也得到保留.
說明: Pubkeys 是一個普通文件
使用rsync, 也可以從本地拷貝多個文件或目錄到遠端, 以下即為示例:
注意:
與本地文件拷貝不同的地方在於, 當拷貝文件到遠程伺服器時, 我們指定遠程主機上的用戶名, 伺服器地址, 路徑等信息, 類是於使用scp命令拷貝, 如果沒有設置ssh免密碼登錄我們還需要提供遠程用戶的密碼等信息.有時你不想頻繁輸入密碼, 或者rsync運行在一個無人執守的腳本裡面, 這是需要預先設置ssh免密登錄, 或者使用結合expect命令,自動輸入密碼, 但是出於安全考慮, 密碼需要加密. 所以在條件許可的情況下, 還是推薦設置ssh免密登錄.
與示例 4 稍有不同, 這時遠端目錄或文件作為源位置, 本地目錄或文件作為目標位置, 示例如下:
rsync 允許指定遠程主機上運行shell命令.
這時需要使用 -e 選項:
-e, --rsh=COMMAND 指定遠端使用的shell命令
Use rsync -e ssh to specify which remote shell to use. In this case, rsync will use ssh.
在一下特殊的使用場景中, 我們不希望拷貝文件時, 我們不希望拷貝過程覆蓋掉目標位置中用戶做出的修改. 這時我們需要使用 -u 選項明確的告訴rsync命令保留用戶在目標文件中作出的修改. 在下面的例子中, 文件Basenames是用戶基於上次的拷貝, 修改過的文件, 當我們使用了-u 選項後, 該文件中的修改將不會被覆蓋掉.
在某些特殊場景中, 我們只需要遠程伺服器上的目錄結構, 而不希望花大量時間, 帶寬拷貝文件內容, 這時我們可以使用 -d, --dirs選項來達到目的.
有時我們希望拷貝文件時, 能實時的顯示拷貝進度, 以及傳輸速率等信息. 尤其是拷貝大文件時, 程序不輸出信息, 用戶往往無法區分程序是在響應中, 還是已經掛起, 在這種情況下如果使用 –progress 就會非常有幫助.
rsync –progress option displays detailed progress of rsync execution as shown below.
你也可以使用rsnapshot工具 (rsnapshot會調用rsync)來備份本地linux伺服器, 或者備份遠程linux伺服器.
有時我們希望目標文件和源文件保持嚴格一致, 不要多文件也不要少文件, 這是我們可能需要使用 -delete 選項來達到目的. 如果使用 -delete 選項, rsync將刪除目標位置多餘的文件或文件夾. 此選項還可以結合--delete-excluded 選項一起使用, 添加一些例外的文件.
上述示例中, new-file.txt 是源文件中沒有的文件, 其將會在拷貝時被刪除掉.
在某些特殊的場景下, 我們只想更新, 目標位置已經存在的文件或目錄, 而不關心源位置的新文件, 這時我們可以使用-existing 選項僅僅更新已經存在的文件.
讓我們來驗證一下這個選項的功能, 首先在源端添加一個新文件 new-file.txt.
從上面的例子可以看到, 由於加了--existing選項新文件new-file.txt沒有被拷貝到目標位置
選項-i, --itemize-changes 非常有用, 當我們想了解目標位置和源位置的文件差異時.
在源端:
在目標端:
注意: 在上面的例子中, 源位置和目標位置有兩處差異. 第一, 源文件Basenames的所有者和組 與 目標文件不同, 第一Dirnames文件大小也不一樣.
現在讓我們來看看rsync會怎樣顯示這些差異
輸出信息只在相應文件前面顯示了9個字母來標識改變, 這些字母具體是什麼意思呢? 請參考以下詳細說明
rsync 可以使用--include 和 --exclude 選項結合通配符進行文件或文件夾過濾
在上面的示例中, 僅僅以P打頭的文件和文件夾被包含了進來, 其他的文件都被過濾在拷貝的過程中被排除在外了.
可以使用--max-size 告訴rsync 不要拷貝大小超過某個值的文件, 可以使用K, M, G指定文件大小, M for megabytes and G for gigabytes.
rsync 有個重要優點就是, 可以做到在拷貝的過程中, 只拷貝發生變化了的部分, 而不是發送整個文件.
但是在某些場景中, 比如文件較少, 文件size較小時, 我們的帶寬又足夠大, cpu資源相對又貧乏, 我們不希望它這樣做, 因為畢竟計算源端和目標端的checksum, 並做對比, 也需要額外cpu開銷. 這時我們可以使用 -W, --whole-file 選項, 讓rsync不用計算那麼多, 一上來就直接開始傳送文件. 我們可以像下面這么做.
15個Rsync命令實例
4. 怎麼svn伺服器上的 資料庫備份到本地
將本地的記錄修改成與伺服器上的一致。也就是說，將本地與伺服器上不同的地方，改成與伺服器上的一樣。
svn備份一般採用三種方式：
1）svnadmin mp
2)svnadmin hot
3)svnsync.
注意，svn備份不宜採用普通的文件拷貝方式（除非你備份的時候將庫暫停），如命令、rsync命令。
筆者曾經用 rsync命令來做增量和全量備份，在季度備份檢查審計中，發現備份出來的庫大部分都不可用，因此最好是用svn本身提供的功能來進行備份。
優缺點分析
==============
第一種svnadmin mp是官方推薦的備份方式，優點是比較靈活，可以全量備份也可以增量備份，並提供了版本恢復機制。
缺點是：如果版本比較大，如版本數增長到數萬、數十萬，那麼mp的過程將非常慢；備份耗時，恢復更耗時；不利於快速進行災難恢復。
個人建議在版本數比較小的情況下使用這種備份方式。
第二種svnadmin hot原設計目的估計不是用來備份的，只能進行全量拷貝，不能進行增量備份；
優點是：備份過程較快，災難恢復也很快；如果備份機上已經搭建了svn服務，甚至不需要恢復，只需要進行簡單配置即可切換到備份庫上工作。
缺點是：比較耗費硬碟，需要有較大的硬碟支持（俺的備份機有1TB空間，呵呵）。
第三種svnsync實際上是製作2個鏡像庫，當一個壞了的時候，可以迅速切換到另一個。不過，必須svn1.4版本以上才支持這個功能。
優點是：當製作成2個鏡像庫的時候起到雙機實時備份的作用；
缺點是：當作為2個鏡像庫使用時，沒辦法做到「想完全拋棄今天的修改恢復到昨晚的樣子」；而當作為普通備份機制每日備份時，操作又較前2種方法麻煩。
5. svn資料庫怎麼防止拷貝
採用三種方式：
1）svnadmin mp
2)svnadmin hot
3)svnsync.
注意，svn備份不宜採用普通的文件拷貝方式（除非你備份的時候將庫暫停），如命令、rsync命令。
6. 從linux中同步文件夾的軟體
用rsync命令同步就行了
rsync可以讓兩個目錄的內容一致，它同步只會同步有更新過的文件，減少傳輸量。可以是本機上的兩個目錄，也可以是本機的目錄同步到伺服器上，還可以是把伺服器上的目錄同步到本機上。
基本命令是 rsync 命令的參數 源目錄 目的目錄
rsync可以基於ssh協議來做，這樣就省去了很多配置rsync server的麻煩，如果兩個機器已經實現ssh無密碼登陸，那麼rsync就會提示輸入密碼，還有一種是通過密鑰文件來實現免密碼，例如下面
1、rsync -vzrtopg --progress -e ssh --delete 用戶名@伺服器IP:/var/www/dirA/ /var/bak/
2、rsync -vzrtopg --progress -e "ssh -i /path/pwd.pem" --delete 用戶名@伺服器IP:/var/www/dirA/ /var/bak/
就是把伺服器上的dirA目錄同步到本地的/var/bak目錄下，其中方法1是用戶已經做了ssh免密碼登陸，方法2是通過密鑰(存放在/path 下的pwd.pem文件)來同步
7. 如何通過rsync+sersync 實現同步備份
如何通過rsync+sersync 實現同步備份
3、rsync+sersync更快更節約資源實現web數據同步
4、unison+inotify實現web數據雙向同步
一：為什麼要實現同步備份
伺服器上有些重要文件或數據時，可以把他們多備份一份到其他伺服器上，這樣就不怕數據或文件丟失了。
二：環境的搭建
伺服器A：192.168.1.10 源伺服器
伺服器B: 192.168.1.20 目的伺服器
我們要實現的就是把A伺服器上的文件同步到B伺服器上，從而實現備份。我們主要是在B伺服器上安裝配置rsync，在A伺服器上安裝配置sersync,通過sersync把文件推送到B伺服器上
三：開始搭建
從B伺服器開始：
1.關閉selinux，在/etc/sysconfig/selinux 這個文件，設置SELINUX=disable
2.防火牆開通873埠 -A INPUT -m state --state NEW -m tcp -p tcp --dport 873 -j ACCEPT
3.開始安裝rsync
yum install rsync -y
4.配置rsync,rsync的配置文件是/etc/rsyncd.conf,配置如下：
圖下方需要注意的地方：secrets file這個是配置同步的密碼文件的。[rsynctest]這個是配置同步模塊的名稱，path是配置同步的目錄，hosts allow是允許同步的主機，hosts deny：拒絕同步的主機
5.創建同步的用戶與密碼的文件,即上圖中的secrets file這個配置選項中的文件。/etc/rsync.passwd，同進要設置這個文件的許可權為600
echo "user:password" >> /etc/rsync.passwd
chmod 600 /etc/rsync.passwd
6.創建同步的目錄：即上圖中path配置選項中的目錄。
mkdir /home/rsynctest
7.啟動rsync
rsync --daemon --config=/etc/rsyncd.conf
接著重啟一下xinetd
/etc/init.d/xinetd restart
8.配置開機啟動 echo "rsync --daemon --config=/etc/rsyncd.conf" >> /etc/rc.d/rc.local
到這樣B伺服器基本就配置完成了。
接著配置A伺服器：
1.先到sersync官網下載sersync:http://sersync.sourceforge.net/
wget http://sersync.googlecode.com/files/sersync2.1_64bit_binary.tar.gz
2.安裝sersync
# mkdir /usr/local/sersync
# mkdir /usr/local/sersync/conf
# mkdir /usr/local/sersync/bin
# mkdir /usr/local/sersync/log
# tar zxvf sersync2.5_32bit_binary_stable_final.tar.gz
# cd GNU-Linux-x86/
# cp confxml.xml /usr/local/sersync/conf
# cp sersync2 /usr/local/sersync/bin
3.創建密碼文件,同B伺服器一樣，不過這個文件只要保存一個密碼就行了，不用用戶名,許可權也是600
echo "password" >> /etc/rsync.passwd
chmod 600 /etc/rsync.passwd
4.配置sersync,配置文件就是上第二步復制的confxml.xml這個文中，路徑在/usr/local/sersync/conf中
---------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<head version="2.5">
# 設置本地IP和埠
<host hostip="localhost" port="8008"></host>
# 開啟DUBUG模式
<debug start="false"/>
# 開啟xfs文件系統
<fileSystem xfs="false"/>
# 同步時忽略推送的文件(正則表達式),默認關閉
<filter start="false">
<exclude expression="(.*)\.svn"></exclude>
<exclude expression="(.*)\.gz"></exclude>
<exclude expression="^info/*"></exclude>
<exclude expression="^static/*"></exclude>
</filter>
<inotify>
# 設置要監控的事件
<delete start="true"/>
<createFolder start="true"/>
<createFile start="true"/>
<closeWrite start="true"/>
<moveFrom start="true"/>
<moveTo start="true"/>
<attrib start="true"/>
<modify start="true"/>
</inotify>
<sersync>
# 本地同步的目錄路徑
<localpath watch="/data">
# 遠程IP和rsync模塊名
<remote ip="192.168.1.20" name="data"/>
<!--<remote ip="192.168.8.39" name="tongbu"/>-->
<!--<remote ip="192.168.8.40" name="tongbu"/>-->
</localpath>
<rsync>
# rsync指令參數
<commonParams params="-auvzP"/>
# rsync同步認證
<auth start="true" users="user" passwordfile="/etc/rsync.passwd"/>
# 設置rsync遠程服務埠，遠程非默認埠則需打開自定義
<userDefinedPort start="false" port="874"/><!-- port=874 -->
# 設置超時時間
<timeout start="true" time="100"/><!-- timeout=100 -->
# 設置rsync+ssh加密傳輸模式,默認關閉，開啟需設置SSH加密證書
<ssh start="false"/>
</rsync>
# sersync傳輸失敗日誌腳本路徑，每隔60會重新執行該腳本，執行完畢會自動清空。
<failLog path="/usr/local/sersync/log/rsync_fail_log.sh" timeToExecute="60"/><!--default every 60mins execute once-->
# 設置rsync+crontab定時傳輸，默認關閉
<crontab start="false" schele="600"><!--600mins-->
<crontabfilter start="false">
<exclude expression="*.php"></exclude>
<exclude expression="info/*"></exclude>
</crontabfilter>
</crontab>
# 設置sersync傳輸後調用name指定的插件腳本，默認關閉
<plugin start="false" name="command"/>
</sersync>
# 插件腳本範例
<plugin name="command">
<param prefix="/bin/sh" suffix="" ignoreError="true"/> <!--prefix /opt/tongbu/mmm.sh suffix-->
<filter start="false">
<include expression="(.*)\.php"/>
<include expression="(.*)\.sh"/>
</filter>
</plugin>
# 插件腳本範例
<plugin name="socket">
<localpath watch="/opt/tongbu">
<deshost ip="192.168.138.20" port="8009"/>
</localpath>
</plugin>
<plugin name="refreshCDN">
<localpath watch="/data0/htdocs/cms.xoyo.com/site/">
<cdninfo domainname="ccms.chinacache.com" port="80" username="xxxx" passwd="xxxx"/>
<senrl base="http://pic.xoyo.com/cms"/>
<regexurl regex="false" match="cms.xoyo.com/site([/a-zA-Z0-9]*).xoyo.com/images"/>
</localpath>
</plugin>
</head>
------------------------------------------------------------------------------------------------------------------
5.創建同步目錄：mkdir /home/rsynctest
6.設置環境變數：
# echo "export PATH=$PATH:/usr/local/sersync/bin/" >> /etc/profile
# source /etc/profile
7.啟動sersync
sersync2 -r -d -o /usr/local/sersync/conf/confxml.xml
註：重啟操作如下：
# killall sersync2 && sersync2 -r -d -o /usr/local/sersync/conf/confxml.xml
8.設置開機啟動
# echo "sersync2 -r -d -o /usr/local/sersync/conf/confxml.xml" >> /etc/rc.local
更多詳情可以看http://www.cnblogs.com/myblog1314/p/4569797.html這個裡面的
8. SVN的操作說明以及備份策略
2.1 文件檢出
安裝TortoiseSVN後，SVN會跟Windows的資源管理器完美集成。點擊右鍵，我們可以在菜單欄中選擇「SVN檢出」選項，輸入要檢出代碼的文件庫的URL地址，我們就可以檢出該URL地址下的文件庫的文件。默認情況下是檢出最新版本的代碼，如果需要，我們可以通過瀏覽日誌，根據日誌來找出想要的版本，然後在「版本」選項中指定相應版本就可以檢出相關代碼了 。
之後，對於同一個項目的主幹開發，我們都在這個檢出的代碼文件目錄下操作，而不是每一次提交或更新都重新檢出一次。
2.2 文件添加
我們在本地創建的文件(包括目錄)不會受SVN的控制，為了讓其接受SVN的控制必須將其添加到文件庫中。對於團隊其他成員需要的文件，如代碼文件、某些模塊的.a文件（由於某些需要，該模塊代碼不公開），我們必須讓它們接受SVN的控制，並且保持最新的版本。
2.3 文件刪除
當我們需要刪除無用的文件(包括目錄)時，不能使用Windows的資源管理工具，而必須使用SVN本身的刪除文件功能。這樣該文件被刪除後，其所有修改歷史仍然保存在SVN伺服器中，以後仍然可以獲得該文件的修改歷史。
2.4 文件改名
當我們需要對文件(包括目錄)進行改名的時，不能使用Windows的資源管理工具，而必須使用SVN本身的文件改名功能。這樣該文件被改名後，其改名前的所有修改歷史仍然保存在SVN伺服器中，保持連續的修改信息。
2.5 文件更新
其他團隊成員提交到SVN上的改動不會自動更新到你的本地拷貝中來，我們需要通過更新文件操作來獲取其他成員對項目文件所做的修改。SVN更新文件操作會把文件庫里的文件與本地文件進行合並，從而達到了同時保留其他成員的修改及本地的修改的目的。如果無法自動合並則會發生沖突，需要使用文件比較工具進行手工合並，合並完成後才能提交已解決沖突的文件。沖突的詳細解決方法見第三章——沖突解決。
在團隊開發時，更新是一件很重要的工作，可以保持團隊成員之間的工作內容一致，因此要注意經常更新自己的工作拷貝，以保證自己能夠獲得最新的修改內容。
2.6 改動提交
我們對文件(包括目錄)所做的一切改動，包括添加、刪除、修改文件都必須提交到SVN伺服器文件庫中才能正式生效，之後團隊的其他成員才可以獲取你所作的修改。
提交是很重要的一項操作，要求做到：
提交代碼之前一定要保證修改後的代碼能編譯通過，不能提交編譯不通過的代碼。
比較修改前及修改後的代碼，把調試信息或其他不相關的信息去掉，再次確保提交的代碼是正確的並且提交的是需要提交的文件。
不要等到修改了很多代碼才提交，而是相關小功能完成時就應該提交一次。這樣以後發現問題時就很容易撤銷有問題的代碼——因為撤銷只能針對一次提交，所以在一次提交里涉及過多的功能是不推薦的。
提交時必須填寫log信息，說明這次提交增加了什麼功能或者修正了什麼bug。這些信息有助於自己和其他團隊成員了解整個項目的歷史。當出現問題時也方便定位到對應的版本代碼，所以log信息必須足夠詳細。
事務性提交。也就是說提交要麼成功，要麼全部失敗——即提交出現錯誤時會自動回滾，實際上沒有提交任何東西。出現錯誤時，解決錯誤，再次提交上次提交的全部內容即可。
3. 沖突解決
沖突的解決是我們使用SVN過程中的一個棘手問題，所以獨立一節來談論。
3.1 沖突的產生
沖突發生在多個成員同時對同一個文件進行修改的情形下。即當有其他成員已經提交了修改，而自己在本地拷貝中也對該文件進行了修改，而且修改的是同一個地方，那麼在進行本地文件的更新時，SVN會不知道該選擇那個修改（SVN上的修改還是本地的修改）來進行合並，所以沖突就產生了。
舉例說，假如受SVN控制的文件Day.txt在SVN伺服器上的當前內容如下：
圖表 3 Day.txt文件在本地的修改
我們可以看到，在文本的第一行，SVN上及本地都做了修改。這樣當在本地進行更新（提交之前必須先更新），SVN合並時就不知道monday後面到底該是work還是sleep，所以沖突就產生了。
而第三、五行是各自進行了修改，並沒有沖突，所以這兩行可以順利合並，合並後可以看到所有人所做的修改。
3.2 沖突的解決
沖突發生後，SVN會在本地保存該文件的不同修改版本，見下圖藍色圖標：
圖表 4 Day.txt文件的不同版本
Day.txt.r35是版本35的Day.txt文件（本地拷貝最新版本）
Day.txt.r37是版本37的Day.txt文件（SVN上最新版本）
Day.txt.mine的是本地修改後的Day.txt文件
Day.txt文件中包含了合並後的內容
3.2.1 簡單沖突解決
對於簡單的內容沖突，我們可以直接在合並後的文件上修改。在上例中，我們打開Day.txt文件，可以看到SVN合並後的內容：
圖表 5 Day.txt合並後內容
我們看到沒有沖突的修改：(play basketball)及（meeting）順利地合並了，而沖突的部分出現了一些標記。其中標記
<<<<<<< .mine
=======
之間包含的是本地修改的沖突部分的內容，即monday(work)。而標記
=======
>>>>>>> .r37
之間包含的是版本37（SVN上最新版本）該部分內容，即monday(sleep)。
不失一般性，假如我們現在要保留的內容是monday(work)，那麼我們只要把標記及monday(sleep)部分內容去掉即可：
圖表 6 Day.txt解決沖突後內容
確保修改正確後，把Day.txt文件設置為「已解決的」。
圖表 7 Day.txt標記為已解決
之後，後綴為mine,r35,r37文件全部消失，僅保留已解決沖突的Day.txt文件，提交到SVN即可。
3.2.2 復雜沖突解決
對於文件內容復雜的文件，上述的解決方法容易漏掉一些要修改的部分，解決起來也耗時耗力。這時要通過SVN提供的工具來解決。
選擇SVN功能「編輯沖突」，打開沖突編輯工具:
圖表 8 沖突編輯工具
上半部分的兩個內容欄分別顯示的是版本37的內容及本地修改的內容。
下半部分的內容欄顯示的是合並後的內容。
每個內容欄左邊的標記清楚地標識了該文件做了那些修改。
文件沖突的部分用紅色顯眼地表示了出來。在合並欄，點擊沖突部分，點擊右鍵，我們可以選擇用哪個內容（SVN上最新內容或者本地修改內容）來解決沖突部分，也可以選擇兩個內容都使用，同時選擇它們出現的先後順序。
逐一解決各個沖突。確保所有沖突都解決後，保存文件，並標記為「已解決」的，退出該工具即完成沖突的解決。
4. 加鎖策略
事實上，解決沖突還有一種方法，那就是「嚴格加鎖」。
「嚴格加鎖」要求在編輯文件之前必須先對文件加鎖，然後才能進行編輯。此時團隊其他成員不能對該文件進行編輯，即保證了同一時刻只有一個人在編輯該文件，因此避免了沖突的出現。
那麼，什麼類型的文件我們應該採取「嚴格加鎖」呢？
Excel、圖片等不可合並的文件，我們必須對其「嚴格加鎖」。「嚴格加鎖」的文件都標記為「可讀」的，即不可編輯。要編輯這些「嚴格加鎖」的文件，必須先對其加鎖，加鎖後文件更改為「可讀可寫」。編輯完這類文件後要第一時間提交。提交完成時，SVN會自動解開任何你擁有的鎖 。
文本文件，比如程序代碼，SVN通常可以為我們合並改動，無須「嚴格加鎖」。對於一些大家都頻繁改動的重要源代碼文件，可能會引起大量沖突，我們也不推薦「嚴格加鎖」，因為加鎖會導致大家持續得走來走去去詢問加鎖情況。正確做法是把文件分成數個邏輯單元，大家都修改各自的單元，減少合並時的沖突。
5. 標簽&分支
一個項目最初存放的目錄我們稱之為主幹(trunk)。下面我們討論除了主幹之外其他存放項目的目錄——標簽(tag)和分支(branch)。
5.1 標簽（tag）
版本號可以區分多次的代碼修改，我們可以使用版本號來檢出需要的代碼，但對於重要版本的代碼，如第三版發布代碼，我們不希望記住r37這樣的數字。這時，我們就可以通過創建標簽來對SVN中這個發布版本的文件的這個時刻的狀態創建一個「快照」，以後就可以通過這個標簽名字來檢出第三發布版本的代碼。
標簽其實是當前項目文件的簡單拷貝，保存在標簽所在的目錄下。創建標簽也是挺簡單的，不過要注意：
標簽的名字一定要有描述性，可以僅憑名字就知道為什麼要創建標簽。
不能過多地使用標簽，只有在重要時刻或者發布版本時才可以創建標簽。
標簽是項目文件在某個時刻的狀態，不能對其進行修改 。
5.2 分支（branch）
分支跟標簽一樣，也是當前項目文件的簡單拷貝，保存在分支所在的目錄下。
分支跟標簽的根本區別在於，標簽不能對其進行修改，而分支就是為了某種目的的修改而建立的。在檢出代碼時檢出指定分支即可，分支的操作跟主幹上的操作完全相同。
5.2.1 何時創建
遇到下述情況，我們可以通過創建分支來解決問題：
發布分支
當我們快要發布一個版本了，一個開發小團隊要為這次發布做好准備，比如說修改一些收尾的bug。這時他們需要的是項目的穩定性，而同時我們還有其他團隊要開發預計下次發布才會添加進去的功能，顯然他們不能在同一份代碼上工作，因此我們需要從主幹中建立出一個發布分支，發布團隊都從這個發布分支檢出及提交代碼。當程序被發布之後，這個分支依然是活動的。這樣，如果客戶報告了一些bug，團隊會在這個發布分支中修正它們並視情況合並到主幹中去。
試驗分支
當我們需要對項目做大范圍的改動，並且這改動對系統的其餘部分有深遠的影響，而我們又不能保證這次改動一定能成功的時候就可以建立試驗分支。如果試驗失敗了，可以廢棄這個分支；成功了我們只要把分支的改動合並到主幹代碼中去就可以了。
其他情況，我們不建議創建分支，更不推薦在分支上創建分支，因為分支過多，合並時的沖突將會是一種難於解決的災難。
5.2.2 合並分支
我們在分支上所修正的bug很可能在主幹上或者其他分支上也存在，因為它們往往來自同一份代碼，所以我們在分支上所做的改動有必要合並到主幹或者其他分支中去。
對於簡單的bug，一次提交就能解決問題的，那麼我們只要記住提交新版本號，然後使用新版本號把改動合並到其他的受影響的主幹及分支中去就可以了。
對於復雜的bug，可能需要多個開發者花幾天的時間提交多次才能修好。這時光用版本號來記住修改的內容就有點勉為其難了。因此，我們可以使用標簽來標記我們修正過程的開始和結束，然後使用這些標簽幫助我們把修正的代碼合並到主幹和其他分支中去。整個過程如下：
① 給分支打個標簽，標記bug修改開始。
② 測試重現bug，修正代碼讓新測試通過。
③ 提交你的改動到SVN上。
④ 重復步驟2、3，直到確定bug已經修正。
⑤ 再給分支打個標簽，標記bug修正結束。
⑥ 使用兩個標簽來把修正的代碼合並到所有其他受影響的主幹和分支上。
6. 注意事項
經常更新
由於文件可能有多個人修改，應該經常更新你的工作拷貝中的文件，這樣能降低發生沖突的可能性。
測試提交
提交前先在本地進行測試。不允許將有錯誤的文件提交到SVN伺服器上。
填寫備注
提交時一定要寫備註：備注有助於其他人（包括三個月後的你自己）理解你對文件所做的修改。
整體提交
提交文件時注意要提交一項改動所對應的所有文件，不要一次提交一個文件或者一次提交修改了很多功能的一堆文件。
發布標簽
對於每一個發布的版本都要建立標簽：當用戶告訴你發生某個問題時，你可以迅速地追蹤到問題是在哪個版本引入的 。
附：測試自動化小組SVN使用指導原則
1. Project的構建
Project在SVN伺服器上的目錄架構如下：
SVN上的項目文件：
1. 必須保證Trunk上的代碼是最新的！定期對Trunk上的代碼進行更新，各小組可根據各自實際情況自己把握
2. Tag是根據項目需要所打的標簽，每一個發布的版本都要打Tag，主要是方便有需要時可以直接根據Tag返回到之前的狀態，以便於分析、測試；Tag中必須包含相應的release文件及當時編譯或發布時的源代碼，必須有相關的文檔註明項目背景、發布情況等。
3. Branch文件夾可以用作備份用，可以用個人名字命名文件夾；此外，Branch分支主要用來進行短暫或者探索性的開發使用，最終的軟體版本必須更新、合並到Trunk主幹上。
4. 關於同一項目組開發環境的建議：同一項目組成員的開發環境最好一致，軟體安裝路徑和Project文件存放路徑最好一致。
2. 版本號
關於版本號命名規則：主版本號.子版本號.修正版本號
1. 項目初版本時，版本號為0.1.0；
2. 當項目在進行了局部修改或 bug 修正時，主版本號和子版本號都不變，修正版本號加 1；
3. 當項目在原有的基礎上增加了部分功能時，主版本號不變，子版本號加 1，修正版本號復位為 0；
4. 當項目在進行了重大修改或局部修正累積較多，而導致項目整體發生全局變化時，主版本號加 1，子版本號和修正版本號復位為0；
5. 編譯版本號一般是編譯器在編譯過程中自動生成的，我們只定義其格式，如果編譯器不能自動生成，人手添加，數值代表為當前的系統時間。
例子：V1.0.1 Build090305 Rel111123
其它版本使用規則：
1. α（alphal）內部測試版
此版本表示該軟體僅僅是一個初步完成品，只在組內內部交流，該版本軟體的 bug 較多，限內部測試使用。
例子：V0.1.1 Build090305 alphal1
2. β（beta）外部測試版
該版本相對於α版已有了很大的改進，經過組內的測試，消除了嚴重的錯誤，但還是存在著一些缺陷，需要經過大規模測試來進一步消除。
例子：V0.1.2 Build090305 beta1
3. demo 演示版
僅限評審或講解時做介紹使用。
例子：V0.1.3 Build090305 demo1
4. release 最終版
該版本意味「最終釋放版」，在出了一系列的測試版之後，終歸會有一個正式版本，一般情況下，release不會以單詞形式出現在軟體封面上，取而代之的是符號 (Rel) 。release版本發布時，必須將待發布的軟體和相應版本更新記錄打包在一起發出。
例子：V1.0.1 Build090305 Rel111123
3. 許可權限制
如果項目本身需要對項目組成員作不同的許可權控制，可以考慮維護兩個工程：一個工程裡面有相應的源文件，一個則只有編譯後的文件。
4. 模塊的版本維護
1. 文件一般不需要版本，但要有詳細的更新歷史記錄；
2. 模塊可以以版本來維護，具體可以不同的文件夾區分。