SVN環境搭建完整步驟
1、SVN安裝
從VM新建虛擬機
1）安裝路徑：D：\ubuntu-test
使用ubuntu 軟件：c:\svn安裝軟件\ubuntu-10.04.1-desktop.i386.iso
Network adapter：Bridged
Ubuntu登錄賬號/密碼：kiki/kiki
安裝完成，重啟ubuntu，打開terminal，自動獲得了一個IP（172.28.6.13）。
2) 設置，安裝過程
a) 設置 ip 和dns上網。
Step1,
sudo –s 轉成root用戶，方便操作。
Step2,
設置IP, vi /etc/network/interfaces
加入：
auto eth0
iface eth0 inet static
address 172.28.6.239
netmask 255.255.0.0
gateway 172.28.16.1
Step3,
Sudo nano /etc/resolv.conf
是一個編輯工具，設置DNS。
加入：nameserver 10.58.100.1
Step4,
重新啟動 networking 服務：
sudo /etc/init.d/networking restart
總結：設置OK，ping 172.28.6.69成功。
b) apt-get update 先更新一下源。
c) 安裝VIM
apt-get install vim
d) 安裝openssh-server
e) 安裝subversion
f) 安裝subversion-tools
g) 安裝apache2
h) 安裝libapache2-svn
i) 安裝tree
j) 設置apache2下的SVN
vim /etc/apache2/dav_svn.conf
設置如下：
<Location /test/>
DAV svn
SVNListParentPath on
SVNParentPath /home/repo/
# SVNIndexXSLT "/apache2-default/svnindex.xsl" （注釋掉，否則會有xml的錯誤，不能顯示）
AuthType Basic
AuthName "Subversion Repository"
AuthUserFile /etc/apache2/dav_svn.passwd
Require valid-user
AuthzSVNAccessFile /etc/apache2/dav_svn.authz z居然泄露了，害我找了好久的原因
</Location>
PS：
1）剛安裝好的apache2沒有dav_svn.passwd文件，
使用vim 創建，
然后htpasswd -b dav_svn.passwd kiki kiki 更新密碼。
創建dav_svn.auth文件，設置*=rw方便測試。
權限文件設置注意：[]*=rw,并且具備權限繼承性，子目錄的權限將代替父目錄的權限。
2）創建測試所用的版本庫，路徑在：/home/repo/test1,其中test1是版本庫。
3）重啟apache服務 /etc/init.d/apache2 restart
4) 設置創建的帳戶文件所屬者為www-data.
設置創建的庫所屬者為www-data,
root@kiki-desktop:/etc/apache2# chown www-data:www-data dav_svn.passwd
root@kiki-desktop:/etc/apache2# chmod 777 dav_svn.passwd
root@kiki-desktop:/home# chown -R www-data:www-data repo
5）訪問：http://IP/test/庫名，SSH遠程登錄ubuntu出現中文亂碼時，設置LANG=””;
2、SVN版本對比
2.1 Subversion 1.6的新東西
改進的認證數據處理
版本庫根的相對URL
svn:externals的改進
目錄樹沖突的檢測
文件系統存儲改進
Ctypes Python綁定
改進的交互式沖突解決
稀疏目錄的排除選項
svnserve的日志支持
察看歷史的新HTTP URI語法
命令行客戶端改進
API變更、改進以及多種語言綁定
超過65項新的bug修正和提升
參考：http://www.subversion.org.cn/?action-viewnews-itemid-99
2.2 以下為共進實際情況：
服務器：10.58.100.247 Subversion1.5
客戶端：10.58.102.3 Subversion1.6
改進和bug修正
改進的交互式沖突解決(客戶端)
svn up:
3、SVN備份
1. 10.58.101.6 截圖：
2. 10.58.100.247 截圖
2. 10.58.101.6截圖：
1. Rsync（remote synchronize）是一個遠程數據同步工具，可通過LAN/WAN快速同步多臺主機間的文件。Rsync使用所謂的“Rsync算法”來使本地和遠 程兩個主機之間的文件達到同步，這個算法只傳送兩個文件的不同部分，而不是每次都整份傳送，因此速度相當快。
第一次連通完成時，會把整份文件傳輸一次，以后則就只需進行增量備份。
2. Rsync支持大多數的類Unix系統，無論是Linux、Solaris還是BSD上都經過了良好的測試。此外，它在windows平臺下也有相應的版 本，如cwRsync和Sync2NAS等工具。
3. Rsync的基本特點如下：
1.可以鏡像保存整個目錄樹和文件系統；
2.可以很容易做到保持原來文件的權限、時間、軟硬鏈接等；
3.無須特殊權限即可安裝；
4.優化的流程，文件傳輸效率高；
5.可以使用rsh、ssh等方式來傳輸文件，當然也可以通過直接的socket連接；
6.支持匿名傳輸
4. rsync是一個功能非常強大的工具，其命令也有很多功能特色選項，我們下面就對它的選項一一進行分析說明。 Rsync的命令格式可以為以下六種：
rsync [OPTION]... SRC DEST
rsync [OPTION]... SRC [USER@]HOST:DEST
rsync [OPTION]... [USER@]HOST:SRC DEST
5. 從遠程rsync服務器中拷貝文件到本地機。當SRC路徑信息包含”::“分隔符時啟動該模式。如：rsync -av root@172.16.78.192::www /databack
從本地機器拷貝文件到遠程rsync服務器中。當DST路徑信息包含”::“分隔符時啟動該模式。如：rsync -av /databack root@172.16.78.192::www
-a, --archive 歸檔模式，表示以遞歸方式傳輸文件，并保持所有文件屬性，等于-rlptgoD
-v, --verbose 詳細模式輸出
4、SVN分支策略（常用分支模式-摘自svn指南.doc）
參考資料：
Subversion1.4手冊 http://www.subversion.org.cn/svnbook/1.4/svn.branchmerge.maint.html
Subversion1.6手冊 http://i18n-zh.googlecode.com/svn/www/svnbook/zh/svn.tour.cycle.html#svn.tour.cycle.resolve
常用分支模式
版本控制在軟件開發中廣泛使用，這里是團隊里程序員最常用的兩種分支/合并模式的介紹，如果你不是使用Subversion軟件開 發，可隨意跳過本小節，如果你是第一次使用版本控制的軟件開發者，請更加注意，以下模式被許多老兵當作最佳實踐，這個過程并不只是針對 Subversion，在任何版本控制系統中都一樣，但是在這里使用Subversion術語會感覺更方便一點。
發布分支
大多數軟件存在這樣一個生命周期：編碼、測試、發布，然后重復。這樣有兩個問題，第一，開發者需要在質量保證小組測試假定穩定 版本時繼續開發新特性，新工作在軟件測試時不可以中斷，第二，小組必須一直支持老的發布版本和軟件；如果一個bug在最新的代碼中發現，它一定也存在已發 布的版本中，客戶希望立刻得到錯誤修正而不必等到新版本發布。
這是版本控制可以做的幫助，典型的過程如下：
開發者提交所有的新特性到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。
這個主干被拷貝到“發布”分支。 當小組認為軟件已經做好發布的準備(如，版本1.0)然后/trunk會被拷貝到/branches/1.0。
項目組繼續并行工作，一個小組開始對分支進行嚴酷的測試，同時另一個小組在/trunk繼續新的工作(如，準備2.0)，如果一個bug在任何一個位置被發現，錯誤修正需要來回運送。然而這個過程有時候也會結束，例如分支已經為發布前的最終測試“停滯”了。
分支已經作了標簽并且發布，當測試結束，/branches/1.0作為引用快照已經拷貝到/tags/1.0.0，這個標簽被打包發布給客戶。
分支多次維護。當繼續在/trunk上為版本2.0工作，bug修正繼續從/trunk運送到/branches/1.0，如果積累了足夠的bug修正，管理部門決定發布1.0.1版本：拷貝/branches/1.0到/tags/1.0.1，標簽被打包發布。
整個過程隨著軟件的成熟不斷重復：當2.0完成，一個新的2.0分支被創建，測試、打標簽和最終發布，經過許多年，版本庫結束了許多版本發布，進入了“維護”模式，許多標簽代表了最終的發布版本。
特性分支
一個特性分支是本章中那個重要例子中的分支，你正在那個分支上工作，而Sally還在/trunk繼續工作，這是一個臨時分支，用來作復雜的修改而不會干擾/trunk的穩定性，不象發布分支(也許要永遠支持)，特性分支出生，使用了一段時間，合并到主干，然后最終被刪除掉，它們在有限的時間里有用。
還有，關于是否創建特性分支的項目政策也變化廣泛，一些項目永遠不使用特性分支：大家都可以提交到/trunk，好處是系統的簡單—沒有人需要知道分支和合并，壞處是主干會經常不穩定或者不可用，另外一些項目使用分支達到極限：沒有修改曾經直接提交到主干，即使最細小的修改都要創建短暫的分支，然后小心的審核合并到主干，然后刪除分支，這樣系統保持主干一直穩定和可用，但是造成了巨大的負擔。
許多項目采用折中的方式，堅持每次編譯/trunk并進行回歸測試，只有需要多次不穩定提交時才需要一個特性分支，這個規則可以用這樣一個問題檢驗：如果開發者在好幾天里獨立工作，一次提交大量修改(這樣/trunk就不會不穩定。)，是否會有太多的修改要來回顧？如果答案是“是”，這些修改應該在特性分支上進行，因為開發者增量的提交修改，你可以容易的回頭檢查。
最終，有一個問題就是怎樣保持一個特性分支“同步”于工作中的主干，在前面提到過，在一個分支上工作數周或幾個月是很有風險的，主干的修改也許會持續涌入，因為這一點，兩條線的開發會區別巨大，合并分支回到主干會成為一個噩夢。
這種情況最好通過有規律的將主干合并到分支來避免，制定這樣一個政策：每周將上周的修改合并到分支，注意這樣做時需要小心，需要手工記錄合并的過程，以避免重復的合并(在“手工跟蹤合并”一節描述過)，你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍(在“合并分支到另一分支”一節中描述過)，這看起來像是脅迫，可是實際上是容易做到的。
在一些時候，你已經準備好了將“同步的”特性分支合并回到主干，為此，開始做一次將主干最新修改和分支的最終合并，這樣以后，除了你的分支修改的部分，最新的分支和主干將會絕對一致，所以在這個特別的例子里，你會通過直接比較分支和主干來進行合并：
$ cd trunk-working-copy
$ svn update
At revision 1910.
$ svn merge http://svn.example.com/repos/calc/trunk@1910 \
http://svn.example.com/repos/calc/branches/mybranch@1910
U real.c
U integer.c
A newdirectory
A newdirectory/newfile
…
通過比較HEAD修訂版本的主干和HEAD修訂版本的分支，你確定了只在分支上的增量信息，兩條開發線都有了分枝的修改。
可以用另一種考慮這種模式，你每周按時同步分支到主干，類似于在工作拷貝執行svn update的命令，最終的合并操作類似于在工作拷貝運行svn commit，畢竟，工作拷貝不就是一個非常淺的分支嗎？只是它一次只可以保存一個修改。
5、Subversion管理代碼最佳實踐
代碼管理實踐
代碼倉庫均采用svn來管理
5.1 代碼目錄的創建：
一般創建三個目錄分別為
trunk(主干)，
tags（標簽/標記)，
branches(分支)。
tags和branches下一般為根據需要從trunk目錄拷貝過來的。
5.2 tags的創建要求：
代碼在一種平臺下通過編譯（必須）
代碼編譯出來的版本通過一定的冒煙測試。
在項目要求的平臺都可以編譯通過。
一般有一個安裝包給測試時，就需要在tags下建立對應代碼的標簽。
tags下的代碼一般不可以修改。
5.3 兩種代碼管理模式介紹:
a、始終分支系統(OpenOffice社區采用管理方式)
典型特征:項目較大，代碼較多，編譯時間較長，參與人員比較多時。
每個用戶對每項編碼任務的創建或操作都是在私有分支中進行的。
編碼完成后，原編碼者、同級或經理將對所有私有分支的更改進行審查并將它由合并到 /trunk 中。
里程碑的創建
集成人員集成將開發人員提交的功能集成到主干上，編譯通過后，提交的主干上，集成了一定的功能后，創建一個里程碑版本，一般建議按周創建里程碑版本。并在tags下創建相應的代碼快照，并將安裝包傳至指定位置。
開發人員基于里程碑版本開發。
開發人員一般基于最新的里程碑版本創建分支，并在分支上工作，并在自己的分支上提交，在提交到svn之前需要編譯通過。開發人員需要根據自己開發情況來同步到主干的里程碑代碼。如果需要集成到主干上，需要同步到最近的里程碑。
測試人員.
測試人員對開發人員的代碼進行測試，達到一定的測試標準后，測試通過，然后交由集成人員來集成。
b、按需分支系統（Subversion社區采用管理方式）
適用方式代碼較少，或者參與開發的人員較少
開發人員可以直接在主干上提交。開發負責人來編譯版本給測試。
開發者把所有的新特性提交到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。新近的開發人員不能提交代碼，交由有經驗的開發人員驗證后來提交到主干上。
當開發小組認為軟件已經做好基本發布的準備(如，版本1.0)然后/trunk會被拷貝到/branches/1.0。這個主干被拷貝到“發布”分支。然后在發布分支上繼續修改bug.
如果bug修正經測試達到一定的要求認為可以完成時，可以拷貝到/tags/1.0.0，這個標簽被建立并發布給相關人員。
5.4 向svn庫提交提交代碼要求
針對每次提交到主干上的代碼均需要編譯通過
代碼每次提交到svn上均需要添加注釋。
每個人都用自己賬號來提交代碼。
6、參考資料
l 分支模式在SVN環境下的應用
http://www.webwoo.net/SVN/svnsy/2009/1211/51007.html
l 持續集成之“分支策略”
http://wwling2001.blogbus.com/logs/164479726.html
l SVN常用分支模式
http://i18n-zh.googlecode.com/svn/www/svnbook-1.4/svn.branchmerge.commonuses.html
l 配置管理一問一答
http://qa.uml.net.cn/Question/List.aspx?t=1&tid=13&tn=%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86&area=0
l 百度-主干開發，分支提測
http://www.cnblogs.com/topiemie/
l subversion管理代碼最佳實踐
http://www.zxbc.cn/html/20081212/68890.html
l Subversion中文站
http://www.subversion.org.cn/?action-category-catid-1
l Subversion FAQ(常見問題解答)
http://subversion.apache.org/faq.zh.html