SVN環(huán)境搭建完整步驟
1、SVN安裝
從VM新建虛擬機(jī)
1）安裝路徑：D：\ubuntu-test
使用ubuntu 軟件：c:\svn安裝軟件\ubuntu-10.04.1-desktop.i386.iso
Network adapter：Bridged
Ubuntu登錄賬號/密碼：kiki/kiki
安裝完成，重啟ubuntu，打開terminal，自動(dòng)獲得了一個(gè)IP（172.28.6.13）。
2) 設(shè)置，安裝過程
a) 設(shè)置 ip 和dns上網(wǎng)。
Step1,
sudo –s 轉(zhuǎn)成root用戶，方便操作。
Step2,
設(shè)置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
是一個(gè)編輯工具，設(shè)置DNS。
加入：nameserver 10.58.100.1
Step4,
重新啟動(dòng) networking 服務(wù)：
sudo /etc/init.d/networking restart
總結(jié)：設(shè)置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) 設(shè)置apache2下的SVN
vim /etc/apache2/dav_svn.conf
設(shè)置如下：
<Location /test/>
DAV svn
SVNListParentPath on
SVNParentPath /home/repo/
# SVNIndexXSLT "/apache2-default/svnindex.xsl" （注釋掉，否則會(huì)有xml的錯(cuò)誤，不能顯示）
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 創(chuàng)建，
然后htpasswd -b dav_svn.passwd kiki kiki 更新密碼。
創(chuàng)建dav_svn.auth文件，設(shè)置*=rw方便測試。
權(quán)限文件設(shè)置注意：[]*=rw,并且具備權(quán)限繼承性，子目錄的權(quán)限將代替父目錄的權(quán)限。
2）創(chuàng)建測試所用的版本庫，路徑在：/home/repo/test1,其中test1是版本庫。
3）重啟apache服務(wù) /etc/init.d/apache2 restart
4) 設(shè)置創(chuàng)建的帳戶文件所屬者為www-data.
設(shè)置創(chuàng)建的庫所屬者為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遠(yuǎn)程登錄ubuntu出現(xiàn)中文亂碼時(shí)，設(shè)置LANG=””;
2、SVN版本對比
2.1 Subversion 1.6的新東西
改進(jìn)的認(rèn)證數(shù)據(jù)處理
版本庫根的相對URL
svn:externals的改進(jìn)
目錄樹沖突的檢測
文件系統(tǒng)存儲(chǔ)改進(jìn)
Ctypes Python綁定
改進(jìn)的交互式?jīng)_突解決
稀疏目錄的排除選項(xiàng)
svnserve的日志支持
察看歷史的新HTTP URI語法
命令行客戶端改進(jìn)
API變更、改進(jìn)以及多種語言綁定
超過65項(xiàng)新的bug修正和提升
參考：http://www.subversion.org.cn/?action-viewnews-itemid-99
2.2 以下為共進(jìn)實(shí)際情況：
服務(wù)器：10.58.100.247 Subversion1.5
客戶端：10.58.102.3 Subversion1.6
改進(jìn)和bug修正
改進(jìn)的交互式?jīng)_突解決(客戶端)
svn up:
3、SVN備份
1. 10.58.101.6 截圖：
2. 10.58.100.247 截圖
2. 10.58.101.6截圖：
1. Rsync（remote synchronize）是一個(gè)遠(yuǎn)程數(shù)據(jù)同步工具，可通過LAN/WAN快速同步多臺(tái)主機(jī)間的文件。Rsync使用所謂的“Rsync算法”來使本地和遠(yuǎn) 程兩個(gè)主機(jī)之間的文件達(dá)到同步，這個(gè)算法只傳送兩個(gè)文件的不同部分，而不是每次都整份傳送，因此速度相當(dāng)快。
第一次連通完成時(shí)，會(huì)把整份文件傳輸一次，以后則就只需進(jìn)行增量備份。
2. Rsync支持大多數(shù)的類Unix系統(tǒng)，無論是Linux、Solaris還是BSD上都經(jīng)過了良好的測試。此外，它在windows平臺(tái)下也有相應(yīng)的版 本，如cwRsync和Sync2NAS等工具。
3. Rsync的基本特點(diǎn)如下：
1.可以鏡像保存整個(gè)目錄樹和文件系統(tǒng)；
2.可以很容易做到保持原來文件的權(quán)限、時(shí)間、軟硬鏈接等；
3.無須特殊權(quán)限即可安裝；
4.優(yōu)化的流程，文件傳輸效率高；
5.可以使用rsh、ssh等方式來傳輸文件，當(dāng)然也可以通過直接的socket連接；
6.支持匿名傳輸
4. rsync是一個(gè)功能非常強(qiáng)大的工具，其命令也有很多功能特色選項(xiàng)，我們下面就對它的選項(xiàng)一一進(jìn)行分析說明。 Rsync的命令格式可以為以下六種：
rsync [OPTION]... SRC DEST
rsync [OPTION]... SRC [USER@]HOST:DEST
rsync [OPTION]... [USER@]HOST:SRC DEST
5. 從遠(yuǎn)程rsync服務(wù)器中拷貝文件到本地機(jī)。當(dāng)SRC路徑信息包含”::“分隔符時(shí)啟動(dòng)該模式。如：rsync -av root@172.16.78.192::www /databack
從本地機(jī)器拷貝文件到遠(yuǎn)程rsync服務(wù)器中。當(dāng)DST路徑信息包含”::“分隔符時(shí)啟動(dòng)該模式。如：rsync -av /databack root@172.16.78.192::www
-a, --archive 歸檔模式，表示以遞歸方式傳輸文件，并保持所有文件屬性，等于-rlptgoD
-v, --verbose 詳細(xì)模式輸出
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
常用分支模式
版本控制在軟件開發(fā)中廣泛使用，這里是團(tuán)隊(duì)里程序員最常用的兩種分支/合并模式的介紹，如果你不是使用Subversion軟件開 發(fā)，可隨意跳過本小節(jié)，如果你是第一次使用版本控制的軟件開發(fā)者，請更加注意，以下模式被許多老兵當(dāng)作最佳實(shí)踐，這個(gè)過程并不只是針對 Subversion，在任何版本控制系統(tǒng)中都一樣，但是在這里使用Subversion術(shù)語會(huì)感覺更方便一點(diǎn)。
發(fā)布分支
大多數(shù)軟件存在這樣一個(gè)生命周期：編碼、測試、發(fā)布，然后重復(fù)。這樣有兩個(gè)問題，第一，開發(fā)者需要在質(zhì)量保證小組測試假定穩(wěn)定 版本時(shí)繼續(xù)開發(fā)新特性，新工作在軟件測試時(shí)不可以中斷，第二，小組必須一直支持老的發(fā)布版本和軟件；如果一個(gè)bug在最新的代碼中發(fā)現(xiàn)，它一定也存在已發(fā) 布的版本中，客戶希望立刻得到錯(cuò)誤修正而不必等到新版本發(fā)布。
這是版本控制可以做的幫助，典型的過程如下：
開發(fā)者提交所有的新特性到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。
這個(gè)主干被拷貝到“發(fā)布”分支。 當(dāng)小組認(rèn)為軟件已經(jīng)做好發(fā)布的準(zhǔn)備(如，版本1.0)然后/trunk會(huì)被拷貝到/branches/1.0。
項(xiàng)目組繼續(xù)并行工作，一個(gè)小組開始對分支進(jìn)行嚴(yán)酷的測試，同時(shí)另一個(gè)小組在/trunk繼續(xù)新的工作(如，準(zhǔn)備2.0)，如果一個(gè)bug在任何一個(gè)位置被發(fā)現(xiàn)，錯(cuò)誤修正需要來回運(yùn)送。然而這個(gè)過程有時(shí)候也會(huì)結(jié)束，例如分支已經(jīng)為發(fā)布前的最終測試“停滯”了。
分支已經(jīng)作了標(biāo)簽并且發(fā)布，當(dāng)測試結(jié)束，/branches/1.0作為引用快照已經(jīng)拷貝到/tags/1.0.0，這個(gè)標(biāo)簽被打包發(fā)布給客戶。
分支多次維護(hù)。當(dāng)繼續(xù)在/trunk上為版本2.0工作，bug修正繼續(xù)從/trunk運(yùn)送到/branches/1.0，如果積累了足夠的bug修正，管理部門決定發(fā)布1.0.1版本：拷貝/branches/1.0到/tags/1.0.1，標(biāo)簽被打包發(fā)布。
整個(gè)過程隨著軟件的成熟不斷重復(fù)：當(dāng)2.0完成，一個(gè)新的2.0分支被創(chuàng)建，測試、打標(biāo)簽和最終發(fā)布，經(jīng)過許多年，版本庫結(jié)束了許多版本發(fā)布，進(jìn)入了“維護(hù)”模式，許多標(biāo)簽代表了最終的發(fā)布版本。
特性分支
一個(gè)特性分支是本章中那個(gè)重要例子中的分支，你正在那個(gè)分支上工作，而Sally還在/trunk繼續(xù)工作，這是一個(gè)臨時(shí)分支，用來作復(fù)雜的修改而不會(huì)干擾/trunk的穩(wěn)定性，不象發(fā)布分支(也許要永遠(yuǎn)支持)，特性分支出生，使用了一段時(shí)間，合并到主干，然后最終被刪除掉，它們在有限的時(shí)間里有用。
還有，關(guān)于是否創(chuàng)建特性分支的項(xiàng)目政策也變化廣泛，一些項(xiàng)目永遠(yuǎn)不使用特性分支：大家都可以提交到/trunk，好處是系統(tǒng)的簡單—沒有人需要知道分支和合并，壞處是主干會(huì)經(jīng)常不穩(wěn)定或者不可用，另外一些項(xiàng)目使用分支達(dá)到極限：沒有修改曾經(jīng)直接提交到主干，即使最細(xì)小的修改都要?jiǎng)?chuàng)建短暫的分支，然后小心的審核合并到主干，然后刪除分支，這樣系統(tǒng)保持主干一直穩(wěn)定和可用，但是造成了巨大的負(fù)擔(dān)。
許多項(xiàng)目采用折中的方式，堅(jiān)持每次編譯/trunk并進(jìn)行回歸測試，只有需要多次不穩(wěn)定提交時(shí)才需要一個(gè)特性分支，這個(gè)規(guī)則可以用這樣一個(gè)問題檢驗(yàn)：如果開發(fā)者在好幾天里獨(dú)立工作，一次提交大量修改(這樣/trunk就不會(huì)不穩(wěn)定。)，是否會(huì)有太多的修改要來回顧？如果答案是“是”，這些修改應(yīng)該在特性分支上進(jìn)行，因?yàn)殚_發(fā)者增量的提交修改，你可以容易的回頭檢查。
最終，有一個(gè)問題就是怎樣保持一個(gè)特性分支“同步”于工作中的主干，在前面提到過，在一個(gè)分支上工作數(shù)周或幾個(gè)月是很有風(fēng)險(xiǎn)的，主干的修改也許會(huì)持續(xù)涌入，因?yàn)檫@一點(diǎn)，兩條線的開發(fā)會(huì)區(qū)別巨大，合并分支回到主干會(huì)成為一個(gè)噩夢。
這種情況最好通過有規(guī)律的將主干合并到分支來避免，制定這樣一個(gè)政策：每周將上周的修改合并到分支，注意這樣做時(shí)需要小心，需要手工記錄合并的過程，以避免重復(fù)的合并(在“手工跟蹤合并”一節(jié)描述過)，你需要小心的撰寫合并的日志信息，精確的描述合并包括的范圍(在“合并分支到另一分支”一節(jié)中描述過)，這看起來像是脅迫，可是實(shí)際上是容易做到的。
在一些時(shí)候，你已經(jīng)準(zhǔn)備好了將“同步的”特性分支合并回到主干，為此，開始做一次將主干最新修改和分支的最終合并，這樣以后，除了你的分支修改的部分，最新的分支和主干將會(huì)絕對一致，所以在這個(gè)特別的例子里，你會(huì)通過直接比較分支和主干來進(jìn)行合并：
$ 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修訂版本的分支，你確定了只在分支上的增量信息，兩條開發(fā)線都有了分枝的修改。
可以用另一種考慮這種模式，你每周按時(shí)同步分支到主干，類似于在工作拷貝執(zhí)行svn update的命令，最終的合并操作類似于在工作拷貝運(yùn)行svn commit，畢竟，工作拷貝不就是一個(gè)非常淺的分支嗎？只是它一次只可以保存一個(gè)修改。
5、Subversion管理代碼最佳實(shí)踐
代碼管理實(shí)踐
代碼倉庫均采用svn來管理
5.1 代碼目錄的創(chuàng)建：
一般創(chuàng)建三個(gè)目錄分別為
trunk(主干)，
tags（標(biāo)簽/標(biāo)記)，
branches(分支)。
tags和branches下一般為根據(jù)需要從trunk目錄拷貝過來的。
5.2 tags的創(chuàng)建要求：
代碼在一種平臺(tái)下通過編譯（必須）
代碼編譯出來的版本通過一定的冒煙測試。
在項(xiàng)目要求的平臺(tái)都可以編譯通過。
一般有一個(gè)安裝包給測試時(shí)，就需要在tags下建立對應(yīng)代碼的標(biāo)簽。
tags下的代碼一般不可以修改。
5.3 兩種代碼管理模式介紹:
a、始終分支系統(tǒng)(OpenOffice社區(qū)采用管理方式)
典型特征:項(xiàng)目較大，代碼較多，編譯時(shí)間較長，參與人員比較多時(shí)。
每個(gè)用戶對每項(xiàng)編碼任務(wù)的創(chuàng)建或操作都是在私有分支中進(jìn)行的。
編碼完成后，原編碼者、同級或經(jīng)理將對所有私有分支的更改進(jìn)行審查并將它由合并到 /trunk 中。
里程碑的創(chuàng)建
集成人員集成將開發(fā)人員提交的功能集成到主干上，編譯通過后，提交的主干上，集成了一定的功能后，創(chuàng)建一個(gè)里程碑版本，一般建議按周創(chuàng)建里程碑版本。并在tags下創(chuàng)建相應(yīng)的代碼快照，并將安裝包傳至指定位置。
開發(fā)人員基于里程碑版本開發(fā)。
開發(fā)人員一般基于最新的里程碑版本創(chuàng)建分支，并在分支上工作，并在自己的分支上提交，在提交到svn之前需要編譯通過。開發(fā)人員需要根據(jù)自己開發(fā)情況來同步到主干的里程碑代碼。如果需要集成到主干上，需要同步到最近的里程碑。
測試人員.
測試人員對開發(fā)人員的代碼進(jìn)行測試，達(dá)到一定的測試標(biāo)準(zhǔn)后，測試通過，然后交由集成人員來集成。
b、按需分支系統(tǒng)（Subversion社區(qū)采用管理方式）
適用方式代碼較少，或者參與開發(fā)的人員較少
開發(fā)人員可以直接在主干上提交。開發(fā)負(fù)責(zé)人來編譯版本給測試。
開發(fā)者把所有的新特性提交到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。新近的開發(fā)人員不能提交代碼，交由有經(jīng)驗(yàn)的開發(fā)人員驗(yàn)證后來提交到主干上。
當(dāng)開發(fā)小組認(rèn)為軟件已經(jīng)做好基本發(fā)布的準(zhǔn)備(如，版本1.0)然后/trunk會(huì)被拷貝到/branches/1.0。這個(gè)主干被拷貝到“發(fā)布”分支。然后在發(fā)布分支上繼續(xù)修改bug.
如果bug修正經(jīng)測試達(dá)到一定的要求認(rèn)為可以完成時(shí)，可以拷貝到/tags/1.0.0，這個(gè)標(biāo)簽被建立并發(fā)布給相關(guān)人員。
5.4 向svn庫提交提交代碼要求
針對每次提交到主干上的代碼均需要編譯通過
代碼每次提交到svn上均需要添加注釋。
每個(gè)人都用自己賬號來提交代碼。
6、參考資料
l 分支模式在SVN環(huán)境下的應(yīng)用
http://www.webwoo.net/SVN/svnsy/2009/1211/51007.html
l 持續(xù)集成之“分支策略”
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 百度-主干開發(fā)，分支提測
http://www.cnblogs.com/topiemie/
l subversion管理代碼最佳實(shí)踐
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