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