什么是版本控制系统(VCS)
版本控制系统 (VCS) 是一个软件，帮助软件开发人员团队工作并维持他们完整的工作历史。 下面是版本控制系统(VCS) 的目标
- 允许开发者们同时工作
- 不会重写每个人的改变
- 维持每个版本的全部的历史
VCS 被分成两种
- 集中版本控制系统 (CVCS)
- 分散或不集中的版本控制系统 (DVCS)
学习svn用到的术语
仓库: 仓库是任何一个版本系统的核心，它是开发者们保存工作的总部，仓库不止处理文件还有历史记录，它需要访问网络，扮演服务器的角色，版本控制工具扮演客户端的角色，客户端可以连接仓库，那么他们就可以从仓库中存储或者提取。通过保存这些更改，一个客户端的更改可以被其他人检索到，一个客户端可以让其他人的更改作为一个工作副本。 主干：trunk 是主要开发所在的目录，经常被项目开发者们查看。 标签：tags 目录用于储存项目中被命名的快照，标签操作允许给予对仓库中特定版本一个描述和一个难忘的名字。比如，LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT 比 Repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 和Revision: 13 更令人难忘。 分支：分支操作用于创建开发的另一条线，当你想把开发进程复制进两个不同的方向是很有用的。比如，当你发布 5.0 版本时，你可能想从 5.0 的 bug 修复中分离出来创建一个开发 6.0 功能的分支。 工作副本：工作副本是仓库的一个快照。这个仓库被所有的成员共享，但人们不直接修改它，相反每个开发者检查这个工作副本，工作副本是一个私人的工作空间，这里开发者可以独立于其他成员做自己的工作。 提交更改：提交是一个保存更改的过程，从私人工作空间到中央服务器。提交后，更改对全部成员可用，通过更新工作副本其他开发者提取这些更改。提交是一个原子操作，要么全部提交成功要么回滚，用户绝不会看到一半完成提交。
svn
1.SVN
1.1简介
SVN是Subversion的简称，是一个开放源代码的跨平台的开源的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。说得简单一点SVN就是用于多个人共同开发同一个项目，共用资源的目的
svn版本管理工具管理随着时间改变的各种数据，这些数据放置在一个中央资料档案库中，svn会备份并记录每个文件每一次的修改变动，这样我们就可以把任意一个时间点的档案恢复到一个旧的版本。
svn相关站点：
svn客户端：http://www.tortoisesvn.net
官方手册：http://svnbook.red-bean.com
svn与git的区别
svn:是集中式的版本控制系统，存在一个中央版本库，所有开发人员本地开发所使用的代码都是来源版本库，提交代码也必须要提交到这个版本库
svn的备份要备份所有代码数据，以及所有更改的版本记录，也可以直接备份中央代码库
git：是分布式的版本控制系统，在git中，已经没有了中央版本库的说法了，但是有远程和本地的完整的git仓库，用来开发小组的代码共享
其中本地和远程仓库中的代码是等价的，没有主从之分
1.2 运行方式，访问方式和数据存储
svn服务器有3种运行方式：
独立服务器 ：svn://svn.test.com/object
apache运行:http://svn.test.com/object
1.单独安装svn和apache服务器
2.第二种是csvn（apache+svn），是一个单独整合个软件，带web界面的svn软件
svn服务器本地直接访问：file:///application/svndata/sadoc
svn客户端的访问方式：
数据存储
svn存储版本数据也有2种方式：BDB(一种事务安全型表类型)和FSFS(一种不需要数据库的存储系统)。因为BDB方式在服务器中断时，有可能锁住数据，所以还是FSFS方式更安全一点。
在svn1.2以前的版本使用BDB,1.2以后使用FSFS
SVN是基于关系数据库的(BerkleyDB)或一系列二进制文件的(FS_FS)。一方面这解决了许多问题 (例如，并行读写共享文件)以及添加了许多新功能(例如运行时的事务特性。)。然而另一方面，数据存储由此变得不透明。
1.3 svn版本系统逻辑架构原理
1.4 集中式管理工作的流程图
集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。下面举例说明： 开始新一天的工作： 1、从服务器下载项目组最新代码。 2、进入自己的分支，进行工作，每隔一个小时向服务器自己的分支提交一次代码，很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了。 3、下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。 这就是经典的svn工作流程，从流程上看，有不少缺点，但也有优点。优缺点参考
集中式管理工作的流程图
2.配置SVN服务
2.1查看系统环境
[root@node1 /]# cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) [root@node1 /]# uname -a Linux node1 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [root@node1 /]# uname -r 3.10.0-693.el7.x86_64 [root@node1 /]# uname -m x86_64 [root@node1 /]#
2.2安装svn(subversion)
检查是否安装了svn
[root@node1 /]# svn --version
-bash: svn: command not found
安装svn
[root@node1 /]# yum install subversion -y
yum安装rpm包本地不清除的方法
[root@node1 /]# cat /etc/yum.conf
keepcache=0 #0修改为1，rpm包下载后不清除
查看版本
[root@node1 /]# rpm -qa subversion
subversion-1.7.14-14.el7.x86_64
配置并启动
1.建立svn版本库数据存储的目录(svndata)及用户，密码权限目录(svnpassword)
[root@node1 /]# mkdir -p application/svndata #数据存储的根目录
[root@node1 /]# mkdir -p application/svnpasswd #用户密码权限目录
2.使用命令svnserve启动服务
[root@node1 /]# svnserve -d -r /application/svndata || pkill svnserve 停止svn服务
svnserve -d -r 目录 --listen-port 端口号
-d：表示启动以守护进程的方式启动
-r：配置方式决定了版本库访问方式
--listen-port：指定SVN监听端口，不加此参数，SVN默认监听3690
--listen-host：指定SVN监听的host，不加此参数，默认全部监听
--pid-file：存放进程号文件
更多svnserve参数：man svnserve
3.查看是否启动，端口为3690
[root@node1 /]# ps -ef |grep svn
root 16304 1 0 18:59 ? 00:00:00 svnserve -d -r /application/svndata/
4.创建版本库（可以创建多个，放置不同的代码）
[root@node1 /]# svnadmin create /application/svndata/sadoc
svnadmin --help 可以查看svnadmin用法
5.调整svn配置文件及权限文件
[root@node1 conf]# cd /application/svndata/sadoc/conf #版本库的配置文件目录
[root@node1 conf]# ll
total 12
-rw-r--r-- 1 root root 1080 Nov 8 20:03 authz #用户权限验证文件
-rw-r--r-- 1 root root 309 Nov 8 20:03 passwd #用户密码文件
-rw-r--r-- 1 root root 3090 Nov 8 20:03 svnserve.conf #sadoc版本库主配置文件，并且包含上面两个配置文件
修改之前要做备份 tar -zcvf ./back_tar.gz .
编辑svnserve.conf修改以下四项：注意修改后要重新启动
anon-access = none #不允许匿名访问，read是允许匿名访问
auth-access = write #是否支持用户可写
password-db = /application/svnpasswd/passwd #指定用户密码数据库，方便统一管理
authz-db = /application/svnpasswd/authz #用户权限数据库
将用户模板copy到配置文件指定的路径里面
[root@node1 conf]# cp authz passwd /application/svnpasswd/
进入/application/svnpasswd修改文件属性，增加安全性，只有root用户可读
[root@node1 svnpasswd]# chmod 700 *
编辑passwd添加账号密码，因为账号密码是明文的，所以上一步修改文件权限，修改后不用重新启动
[root@node1 svnpasswd]# vim passwd
p0st = 123456
shuang = 123456
配置用户权限文件
注意：
权限配置文件中出现的用户名必须是已在用户配置文件中定义过的
对权限配置文件的修改立即生效，不必重新启动svn
[groups] #gtoups下面的变量就是组名，后面可抱哈你多个用户名，用逗号隔开
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
ett_wang = p0st,shuang
# [repository:/baz/fuz] 版本库:/版本库项目/项目目录 #所以这里既可以给整个组赋权限，也可以给单个用户赋权限
# @harry_and_sally = rw 用户组名:权限
# * = r 用户名:权限
[sadoc:/]
@ett_wang = rw
p0st = rw
shuang = r
其中方括号内部有很多种写法
[/]，表示根目录及以下，这里的根目录指的是svnserve启动时指定的，[/]就表示对全部版本库的设置权限
[svndata:/]表示对版本库svndata设置权限
[svndata:/sadoc]表示对版本库svndata中的sadoc设置权限
[svndata:/sadoc/test]表示对版本库svndata中的sadoc项目的test项目设置权限
权限主体可以是用户组，用户，或者*，用户组在前面加@。*表示全部用户
权限可以是w,r,wr和空，空代表没有任何权限
对于组，要以@开头，用户不需要@开头
使用diff authz authz.bak 可以进行对比，查看文件不同
6.重启svn服务：
[root@node1 svnpasswd]# pkill svnserve
[root@node1 svnpasswd]# svnserve -d -r /application/svndata/
注意： 更改svnserve.conf需要重启svn，更改authz、passwd文件时不需要重启；
检查3690端口是否处于监听状态，至此svn服务器搭建完成；下面是svn客户端的安装与使用；
只有更改了svnserve.conf才需要重启服务，剩下的更改都是立即生效的不需要重启
2.3svn启动方式
svnserve -d -r 目录 --listen-port 端口号
-r: 配置方式决定了版本库访问方式。
--listen-port: 指定SVN监听端口，不加此参数，SVN默认监听3690
方式一：-r直接指定到版本库(称之为单库svnserve方式)
svnserve -d -r /opt/svn/runoob
在这种情况下，一个svnserve只能为一个版本库工作。
authz配置文件中对版本库权限的配置应这样写：[groups]
admin=user1
dev=user2
[/]
@admin=rw
user2=r
使用类似这样的URL：svn://192.168.0.1/ 即可访问runoob版本库
方式二：指定到版本库的上级目录(称之为多库svnserve方式)
svnserve -d -r /opt/svn
这种情况，一个svnserve可以为多个版本库工作
authz配置文件中对版本库权限的配置应这样写：
[groups]
admin=user1
dev=user2
[runoob:/]
@admin=rw
user2=r
[runoob01:/]
@admin=rw
user2=r
如果此时你还用[/]，则表示所有库的根目录，同理，[/src]表示所有库的根目录下的src目录。
使用类似这样的URL：svn://192.168.0.1/runoob 即可访问runoob版本库。
2.3 连接svn服务器
windows：
下载tortoisesvn（windos上面svn工具），安装，如果英文看不懂，可以安装中文包汉化
输入用户名和密码，复选框能让tortoisesvn的缺省目录：%APPDATA%\Subversion\auth的三个子目录内保存认证信息
svn.simple：里面包含了进本的认证方式所需的认证信息，注意，密码是通过wincrpty的api加密的不是明文
svn.ssl.server：里面包含了ssl服务器认证
svn.username：里面包含了用户名的认证信息（不需要提供密码）
新建一个文件夹用来接收svn现在的内容，在文件夹上右键就有很多功能了
linux：
在linux使用svn时，要安装svn
查看svn中的数据
svn list svn://192.168.10.231/sadoc --username=p0st --password=123456
svn ls svn://192.168.10.231/sadoc --username=p0st --password=123456
svn ls svn://192.168.10.231/sadoc --username=p0st --password=123456 --verbose #可以显示详细的信息
svn cat svn://192.168.10.231/sadoc/hosts --username=p0st --password=123456 #可以查看文件内容
checkout:检出文件到本地
svn checkout svn://192.168.10.231/sadoc /tmp --username=p0st --password=123456
命令 下载 地址 下载到哪里（本地服务器） 账号密码
add:往版本库中添加新的文件,但是还没提交进去
svn add hosts
将添加或者改动的文件提交到版本库
svn commit -m “LogMessage“ [-N] [--no-unlock] PATH(如果选择了保持锁，就使用–no-unlock开关)
svn commit -m hosts
备注：提交多个文件中间用空格隔开如 svn ci -m "哈哈~~" test.php test2.php style.css
如果出现编码错误的话，需要制定utf-8的编码方式
export LC_CTYPE="en_US.UTF-8"
export LC_ALL=
locale
导入svn原始目录树 trunk（主干） branch（分支）tag（确定之后的版本号）
svn import
mkdir -p /svn/trunk /svn/branch /svn/tag
svn import /svn file:application/svndata/ -m "import"
svn import /svn svn://192.168.10.231/sadoc/ --username=p0st --password=123456 -m “import是注释”
将主干保存为分支
svn copy svn://192.168.10.231/sadoc/trunk svn://192.168.10.231/sadoc/branch/branch_cms_110623 -m "create a branch by p0st"
查看当前svn版本库的信息svn info
svn://192.168.10.231/sadoc --username=p0st --password=123456
注意：要是用svn help 或者svn help add 等命令来查看怎么使用
3.svn钩子脚本
3.1钩子简介
钩子脚本的具体写法就是操作系统中shell脚本程序的写法，所谓钩子就是与一些版本库事件触发的程序，例如新修订版本的创建，或是未版本化属性的修改。每个钩子都会被告知足够多的信息，包括那是什么事件，所操作的对象，和触发事件的用户名。通过钩子的输出或返回状态，
钩子程序能让工作继续、停止或是以某种方式挂起。类似inotify和sersync
对每种Subversion版本库支持的钩子的都有一个模板，通过查看这些脚本的内容，你能看到是什么事件触发了脚本及如何给传脚本传递数据。同时，这些模版也是如何使用这些脚本，结合Subversion支持的工具来完成有用任务的例子。要实际安装一个可用的钩子，
你需要在 repos/hooks目录下安装一些与钩子同名（如 start-commit或者post-commit）的可执行程序或脚本。
提示：
由于安全原因，Subversion版本库在一个空环境中执行钩子脚本—就是没有任何环境变量，甚至没有$PATH或%PATH%。由于这个原因，许多管理员会感到很困惑，它们的钩子脚本手工运行时正常，可在Subversion中却不能运行。
要注意，必须在你的钩子中设置好环境变量或为你的程序指定好绝对路径。
必须要去掉项目里面钩子的后缀名
3.2钩子脚本
注意：svn钩子的目录在/application/svndata/sadoc/hooks下，该目录已经提供了几个钩子的模板
常用的钩子脚本
post-commint：在提交完成成功之后执行该钩子，提交已经完成不会更改，因此，本脚本的返回值被忽略，不可更改，提交完成时触发事物
1.svn更新自动周知，msn，邮件或者短信
2.svn更新触发checkount程序，然后rsync实时推送到服务器等
#此脚本是在commit之后，svn版本库进行更新，并且将版本库里面的内容通过rsync推送到/oldboy备份
#!/bin/bash
#REPOS='$1'
#REV='$2'
#export LANG=en_US.UTF-8
#export LC_ALL=
#LOGPATH="/app/log.log"
#[ ! d $LOGPATH ] && mkdir ${LOGPATH} -p
#update content from svn
SVN=/usr/bin/svn
$SVN update --username p0st --password 123456 /tmp --no-auth-cache
#$SVN update --username p0st --password 123456 /tmp --no-auth-cache >>$LOGPATH 2>&1
if [[ $? -eq 0 ]]; then
/usr/bin/rsync -az --delete /tmp /oldboy/
fi
注意：
1.钩子使用时，要去掉后缀名，可以cp post-commit.tmpl post-commit
2.如果是在windos写的脚本，在linux上执行脚本要进行转换格式 dos2unix post-commint 或者使用编辑器打开时:set ff=unix,然后:wq
3.钩子要有执行权限，通常是700,如果有乱码，可以将脚本中的文件系统的编码注释去掉,特别要注意环境变量的使用，可以查看狗子的模板中是怎么使用的
pre-commit:提交完成前执行该脚本
1.用作限制文件上传大小和扩展名，控制提交要输入的信息等
start-commit：在客户端还没有向服务器提交数据之前，即还没有建立subversion transaction缩写为（txn）之前，执行该钩子（脚本）
不常用的钩子脚本
svn通过ldap统一认证
4.大中小企业代码发布解决方案
4.1svn目录组织结构说明
[root@node1 svndata]# pwd /application/svndata [root@node1 svndata]# ls -al drwxr-xr-x 6 root root 58 Nov 9 20:06 . drwxr-xr-x 4 root root 38 Nov 9 17:22 .. drwxr-xr-x 2 root root 6 Nov 9 20:06 branch #分支，为测试使用，几天上线的项目必须开分支，测试需要本分支通过，主线合并到分支通过，才能合并到主线进行测试 drwxr-xr-x 6 root root 86 Nov 9 17:23 sadoc #版本库 drwxr-xr-x 2 root root 6 Nov 9 20:06 tags #版本记录使用 drwxr-xr-x 2 root root 6 Nov 9 20:06 trunk #主线，与正式线相对应，当天不上线文件不允许提交
4.2大中小企业上线解决方案
小型企业上线架构方案
小型企业上线构架方案建议
1.开发人员需在个人电脑上搭建lamp环境测试开发号的网站代码，并且在办公室或idc机房的测试环境测试通过，最好有专职的测试人员
2.程序代码上线要规定时间。例如，三天一上线，如网站需经常更新课每天下午17点上线，这个看网站业务性质而定，原则上就是能最小的影响用户体验最好
3.代码上线之前需要备份。网站程序出了问题方便回退。另外，从上线技巧上讲，上传代码是尽可能的先上传到网站的临时目录，上传完整之后一步mv过去，或者通过ln做软连接，比较严格的更新代码，将服务器从集群下线（平滑下线），然后更新
4.尽量由运维人员管理上线，对于代码的功能性开发人员更在意，而对于代码的性能和服务的稳定运维更在意。因此如果网站问题归运维管，就要让运维上线，这样更科学，否则，开发随意更新，出了问题运维负责，这样就错了
中型企业上线架构方案
中型企业上线构架方案建议
一般是规范运维人员操作步骤，指定统一的上线操作脚本，备份文件名称，备份文件路径。使操作人性化，统一化，自动化
大型企业上线架构方案
在大型集群环境一般有数台集群机器，因此要分批更新。
下面是java环境代码上线：
1.本地开发人员从svn中抽取代码，当天上线的提交到trunk，否则，长期项目单开分支开发，然后合并主线（trunk）
2.办公内网开发测试时，由开发人员或者配置管理员通过部署jenkins实现统一部署（即在部署平台式控制开发机器从SVN版本库中checkout代码，编译，打包，发布到开发机，idc_dep.war）
3.开发人员和测试人员一起测试程序，没有出现问题后，打上新的tag标记
4.配置管理员，根据上步的tag标记，checkout出上线代码，平配置好idc测试环境的所有配置，执行编译，打包（mvn,ant，php不需要打包），然后发布到idc内的统一分发服务器，这里要注意，不同的配置文件是随着代码同时发布的
5.配置管理员或sa上线人员，把分发的程序代码内容推送到相关的测试服务器（包名如：idc_test.war）,然后通知开发及测试人员进行测试，如果有问题向上回滚到内网开发测试从新测试修改
6.如果测试没有问题，继续打好tag标记，此时配置管理员根据上步的tag标记，checkout出测试好的代码，并配置好idc正式环境的所有配置，执行编译，打包（mvn，ant），然后发布到idc内的统一分发服务器主机上，准备批量发布
7.配置管理员和sa上线人员，把分发的内容推送到相关的正式服务器（包名：idc_product.war）,然后通知开发以及测试人员进行测试，如果有问题，直接发布回滚指令
注意：idc正式上线的过程对于java程序来说，可以将集群上的服务器分为ab两组分批上线的思路，即在流量较少的时候平滑下线一半的服务器，在测试集群挂上服务器。然后进行代码测试，无问题后，在正式集群挂上服务器，同时在平滑下线另一半的服务器，然后发布更新代码测试（或者直接发布就上线）如果前端有dns智能解析，上线还可以分地区的若干服务器，逐渐普及到全国的服务器，这个称为灰度发布
4.3大中小企业上线注意事项
代码上线解决方案注意事项：
1.上线的流程里，办公测试环境->idc测试环境->正式生产环境，所有的环境中所有的软件版本统一，尽量单一。例如：操作系统，web服务器，jdk版本，php，tomcat，resin等版本
2.开发团队小组办公内部测试环境测试（该测试环境属于开发小组维护，或定时自动更新代码），代码有问题返回给开发人员重新开发
3.有专门的测试工程师，程序有问题直接返回给开发人员（此时返回的一般为程序的bug，称为bug库），无问题则进行idc测试
4.idc测试有测试人员和运维人员参与，叫idctest，进行程序的压力测试，有问题直接返回给开发人员，无问题直接环境上线
5.书台服务器代码分发上线（java程序）
1）假设有六台服务器，将服务器分为ab两组，a三台，b三台，先对a组从负载均衡服务器上平滑下线，b组正常提供服务器，避免服务器因线上影响业务
2）下线过程中通过脚本将a组服务器从集群中踢出，避免负载均衡器将请求发给a组服务器
3）将代码发到a租服务器的站点目录下，对a组服务器在测试负载均衡器上线并重启，并有专门的测试人员进行访问测试，测试成功后，在正式负载均衡器上挂上a租服务器的同事，下线b组服务器，b组服务器做和a组等同操作，期间也要及时观察上线服务器的装鲁昂，有问题及时回滚
6.如果php上线：发布代码时，可以直接发布到正式服务器的临时目录，然后mv或者直接link的方式发布到正式线目录，不需要重启服务，当然测试也是少不了的，测试出了测试是否正常以外，还需要测试各个相关业务接口
7.大多数门户网站的前端都已经静态化或者cache了，因此动态的部分访问平时就不会特别多，流量低谷时就号了，再加上是平滑上下线，用户感知更小
php程序上线的具体方案
对于php上线：发布代码时，可以直接发布到正式服务器的临时目录，然后mv或者直接link的方式发布到正式线目录，不需要重启服务
4.4svn服务器上到底要包含什么？
1）svn上存放代码（不含资源，大公司的网站资源和程序都是分离的），在上线的时候尽可能要全量上线，因为我们要保证svn的代码是最新的 2）存放服务的配置文件（lamp环境等配置） 开发小组测试使用的配置文件 办公环境测试使用的配置文件 idc环境测试使用的配置文件 线上应用使用的配置文件
扫一扫
5116
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
