SVN

Posted 2020-06-14

 

一　　SVN是什么？

　　　　

　　1.1　　实际项目开发暴露的问题　

　　　　【问题产生】

　　　　问题一：当分模块开发时，多个人分别写不同的模块，那么如何把代码整合在一起呢？显然手动copy，paste面对小项目还好，面对大项目难免懵逼。

　　　　问题二：如果你说你有那个精力去copy，paste整合代码的话，但如果整合后的项目代码编译，运行出错了呢？这个错误要责任到个人话，你该去寻找谁呢? 

　　　　问题三：当面对一个大型项目，假如先做了项目A，在项目A的技术上做了项目B，在项目B的技术上做了项目C。可以理解B项目是A项目的1.0版本，C项目是A项目的2.0版本。项目A，B，C都有用户在使用，此时项目A出现了BUG，那么我们需要修改项目A，B，C三个项目中的相同BUG（已经对项目A，B，C进行备份），那你就要面临对所有版本修复相同的bug错误，这就是版本迭代开发项目要面临的问题

　　　　【总结问题】

　　　　　　(1)  代码管理混乱。(2)  备份多个版本，占用磁盘空间大。(3)  解决代码冲突困难，容易引发BUG。

　　　　　　(4)  难于追溯问题代码的修改人和修改时间。(5)  难于恢复至以前的版本。无法进行权限控制。(6)  项目版本发布困难。

　　　　【问题解决】

　　　　　使用SVN版本控制软件

　　　　　　解决问题一：团队成员每天把写的代码提交到svn，svn自动帮你整合代码

　　　　　　解决问题二：svn对每天提交的代码，有详细的loggin，包括提交时间，提交人，提交代码等等。还有个重要的一点，svn可以把项目恢复到错误产生之前的版本，再把项目变为错误产生之后的版本。通过这两个版本之间的一些提交loggin，来缩小排错范围

　　　　　　解决问题三：svn超简单解决

 

　　1.2　　与github比较

　　　　svn与当今的github功能相似,但也有些许差别。

　　　　　　(1)  svn是一个服务器，离开服务器无法提交。github可以进行离线提交，任何地方都可以提交

　　　　　　(2)  svn不能分布式管理版本控制软件。github是针对开源项目用的多，可以分布式管理版本控制软件

　　　　　　(3)  svn适合团队开发，github适合整个宇宙一起开发

　　1.3　　版本控制软件产生的效果

　　　　openstack这个开源项目，就是通过版本控制软件，集社会之智慧来发展。

　　　　openstack是什么？

　　　　　　平时软件运行在操作系统中，云端有自己的操作系统，hadoop就是云计算的应用软件的一种，提供了高平发分布式的平台。hadoop必须运行在云端操作系统，openstack就是云端的操作系统。相当于paas层(服务层)。云端就是通过开源来发展。

 

---

 

 

二 　　svn的安装

　　

　　mac自带了svn,好像是因为我装了x code的原因，具体不太清楚，以后学到了linux再来补充这里。

 

---

 　权限分为：

　　　　认证(authentication )：身份验证

　　　　授权(authorization )：访问权限

---

 

三　　服务端角度，操作仓库

 

　　2.1　　检验是否安装成功

svnserve --version

　　　　terminal显示结果:

　　

　　2.2　　创建仓库 

　　　　2.2.1　　仓库的位置

　　　　　　环境是mac下操作，我们在/Users/apple下创建了一个svn文件夹。用来充当svn仓库。

　　　　2.2.2　　创建仓库

svnadmin create /Users/apple/svn/s2sh

　　　　2.2.3　　库里的文件

　　　　　　config(负责权限的文件夹):

　　　　　　　　authz:授权

　　　　　　　　passwd:认证

　　　　　　　　svnserve.conf:

　　　　　　db:存放版本控制产生的数据

　　　　　　hooks(钩子):

　　　　　　　　一些编辑脚本，每当我们提交到仓库时，就把记录发送到我们的邮箱，svn本身没有这个功能，我们使用脚本来提供额外的功能

　　　　　　locks(上锁):

　　　　　　　　仓库中有的项目有很重要的文件，对该文件上锁，其他人无法从仓库中获取该文件　

　　2.3　　启动仓库

// -d:代表路径
// -r:为仓库路径。因为可以配置多仓库、我们在访问的时候就要指定具体的仓库　　svn://localhost/s2sh 
svnserve -d -r /Users/apple/svn（该路径是仓库路径，该路径下可以有多个仓库）

　　2.4　　检查是否启动仓库

//监听3690端口，如果成功启动仓库，说明svn在监听该端口
lsof -i:3690;

　　　　　　　　

 

---

 

 

三　　客户端角度，操作仓库

 

　　3.1　　创建用户

　　　　其实就是在任意地方创建两个文件夹。来模拟两个用户，每个文件夹代表每个用户的仓库。

　　3.2　　从仓库checkout到客户端

svn checkout svn://localhost/s2sh /Users/user1

　　3.3　　从客户端提交数据到仓库

　　　　第一步：

 

svn add /Users/user1/a.docx

　　　　第二步：提交到对应的仓库　　 

//一定要添加 "-m 提交信息" ，才可以区别你每次提交的行为
svn commit -m "add a.docx" /Users/user1/a.docx 

　　　　【说明】

　　　　　　可能当你添加了提交信息，还是会出现一个认证失败，也就是登录失败。因为svn默认不允许匿名用户登录，此时需要修改svnserve.conf。把anon-access = write这样修改后，才可以提交到仓库　

　　3.4　　从仓库checkout到客户端，

svn checkout svn://localhost/s2sh /Users/user2

终端显示:

　　我们发现版本升级，并顺利checkout到了user1提交的a.docx

　　3.5　　修改

//不需要add，直接进行commit
svn commit -m ‘a.docx update‘ /Users/user2/a.docx

　　3.6　　更新

svn update /Users/user2

　　3.7　　总结

　　

　　

---

 

 

四　　客户端tortoise

 

　　上面的属于客户端命令行操作，我们需要安装图形化客户端，但底层原理还是命令行式的,tortoise就是操作svn的客户端software。

　　4.1 　　64位客户端一个问题

　　　　“期望文件格式是1-4之间，发现了格式6”。应该修改仓库db中的format文件。把6改文4.

 

---

 

 

五　　认证与授权

 

　　开启认证与授权

//匿名用户没有任何权限
anon-access = none
//认证用户有写权限
auth-access = write
//授权文件
password-db = passwd
//认证文件
authz-db = authz

　　认证:passwd

[users]
# harry = harryssecret
# sally = sallyssecret
//添加两个用户
user1 = user1 
user2 = user2

　　授权:authz

[groups]
# harry_and_sally = harry,sally
# harry_sally_and_joe = harry,sally,&joe
//定义s2sh组，组下有user1，user2两个用户
s2sh=user1,user2

//其中"/"代表s2sh仓库下的所有东西
[s2sh:/]
//对于s2sh仓库来说 @组 下面的用户都可读可写
@s2sh=rw
//除了s2sh组，其他组什么都不能做
*=

 

---

 

 

六　　冲突的解决

 

　　6.1　　问题的出现

　　　　加入A，B两个用户。

　　　　首先A进行add，commit操作。B进行update操作。A进行修改，commit。然后B进行修改，commit的时候，会报冲突。

　　6.2　　图形化界面解决

　　　　安装tortoise后，右键寻找edit conflict。可以进行解决了

　　6.3　　避免问题

　　　　操作前，先使用"svn update"与仓库同步

 

---

 

 

七　　分支，合并，切换

 

　　在一开始我们提到的，假如先做了项目A，在项目A的技术上做了项目B，在项目B的技术上做了项目C。同时项目A，B，C都有用户在使用，此时项目A出现了BUG，那么我们需要修改项目A，B，C三个项目中的相同BUG，该问题就是项目迭代开发中会出现的问题。而且我们需要对项目A，B，C进行备份，这个问题，我就要开始用svn进行解决。

　　1.会有很多副本产生

　　2.每当项目a出现bug，修复起来很麻烦

　　3.不利于管理

　　开始进行改善

　　　　

 

　　实际开发

　　　　1.　　创建oa仓库

　　　　2.　　在仓库下创建三个文件：truck，tags，branches

　　　　3.　　把正在开发的项目导入truck中

　　　　4.　　把truck中的项目checkout到eclipse中

　　　　5.　　开发完成的项目发布到tag中。(分支过程)

　　　　6.　　继续开2.0，项目1出现了bug

　　　　7.　　tags检出到branches中

　　　　8.　　修复branches中项目的bug