SVN版本控制初探

1、基本概念

 

       版本控制系统,有时被称作源代码控制系统,是支撑项目开发的重要支柱。常用它来保存开发应用程序时文档的各个修订版(reversion)。目前已经有很多版本控制系统,比如CVS,Git,SVN等,本文主要介绍被广泛使用于开发中的SVN版本控制系统。

 

修订版(reversion)某个文件在其生命周期内保存的快照,与时间区域对应
本地工作拷贝(local working copy)修订版在本地的拷贝
版本库(repository)存放修订版的数据库
版本检入(check in)本地副本提交到服务器版本库
版本检出(check out)从服务器版本库中取出修订版成为本地工作副本
版本号来源基于文件的计数和基于仓库的计数,SVN采取后者
标签(tags)为版本加一个名字,便于记录检出
分支(branches)修订版打分支,以后可以平行修改,互不干扰
合并(merge)将分支的修订版合并为一个新的修订版
冲突(conflict)并发版本控制时防止修订版混乱的错误机制
锁(lock)为修订版加锁

       

subversion有三种联网协议:svn、svn+ssh、http。subversion通过自带的监听网络连接的svnserve小服务器达到svn访问,但文件内容传输的时候没有加密,且密码以明文方式存储在服务器的conf目录中,只能由能够访问密码文件的管理员修改;ssh使用了强大的加密机制保护客户机服务器会话的内容,被广泛用于管理互联网上的服务器;apache是高度可配置的,而subversion利用了其内建的安全机制和可缩放性,可以使用标准的http和https架设项目仓库,利用apache支持的所有验证机制。

      subversion不但能版本化文件,还能版本化目录;SVN版本号针对整个目录树,而非单个文件,每个版本号代表了一次提交后版本库整个目录树特定状态;同时支持拷贝-修改-合并和锁定-修改-解锁两种操作模式,前一种更有利于协作;提交是原子提交的,要么全部成功要么失败;它在本地维护一个原始的版本缓存(text-base),可使提交只传递修改的部分而非整个文件。

 

      

 

     SVN支持几个内置版本关键字,HEAD表示最新版本,BASE是工作拷贝检出或更新时的版本,COMMITTED是每个文件或目录最新的版本,PREV是COMMITTED的前一个版本。PREV,BASE,COMMITTED只在引用工作拷贝路径时使用,不能用于版本库URL,HEAD则可用于两种路径类型。

      分支和标签在实现上均是拷贝。SVN自身只知道拷贝而并不了解其含义。一个复制的目录之所以是标签是因为人们决定这样使用它,只要没有人修改这个目录,它永远是一个快照,但如果开始修改,它就变成了分支。每个分支都可追踪其历史版本到主干的根部。在分开的部分,则各自看不到其它分支的版本。 

 


2、常用命令

 

import:将未版本化的文件纳入版本控制并提交

checkout:从版本库中检出一个修订版

update:更新工作拷贝

add,delete,copy,move:增、删、复制、移动文件或目录

status:检查状态差异

diff:检查文件行级详细差异

revert:恢复

resolve:解决冲突

switch:切换工作拷贝对应的版本库分支

log:查看历史记录

list:显示文件目录

cat:查看某个文件内容

 


3、实战演练

 

(1)获取帮助:  

命令行下输入 svn help,它会列出所有支持的命令集合,或者要查看具体的命令使用方法svn help ci

 

(2)获取更新:

频繁地更新你的工作拷贝,不断合并他人的改动是个不错的主意,这样减少冲突可能性。在工作拷贝中使用svn update会从项目仓库中更新目录中的所有文件及其子目录中文件。

svn up [-r200]

      在更新过程中,subversion会显示每个文件的状态及对应的重要活动。打印出来的这些信息表明对每个文件和目录都做了些什么。A代表项目仓库中有新文件被添加到了工作拷贝;U表示已经用项目仓库中最新文件替换掉工作拷贝的老版本文件;D表示项目仓库中删除了文件,subversion把它从工作拷贝中移除;G表示工作拷贝中文件已经过期,而且本地还做了修改,会将项目仓库中版本和本地版本进行合并;C表示工作拷贝文件过期,而且本地也做了修改,尝试合并的时候遇到冲突。

 

(3)将项目加入版本控制:

使用svn import命令,它会自动递归提交一个路径的拷贝到版本库中。import子命令在导入数据之后,你会发现原先的目录树并没有纳入版本控制,为了开始工作,你还是要运行svn co得到一个干净的目录树工作拷贝。

svn import youku http://svn1.spec-develop.com/cdrd/storage-boss/branches/youku

 

(4)如何拉分支:

svn cp http://svn1.spec-develop.com/cdrd/storage-boss/trunk/jss_manager  http://svn1.spec-develop.com/cdrd/storage-boss/branches/v_20120808/jss_manager-m 'huanggang cp

 

(5) 

检出项目:

svn checkout命令(简写为co)让Subversion能从项目仓库的一个目录中取出文件并创建新的工作拷贝。如果不指定特定名字,该命令会把工作拷贝创建在一个与项目仓库目录同名的目录中,且取的是最新版本,当然,你也可以带上-r参数取出特定版本。要搞清楚项目是从哪来的,可以在项目目录下执行svn info命令。

svn co [-r4203] http://svn1.spec-develop.com/cdrd/storage-boss/trunk/jss.platform [spec_version]

 

 (6)显示提交日志信息:

显示提交的日志信息。默认,显示该分支的所有相关版本提交日志。 如果只想显示自己打的分支,提交的日志情况,可以使用“—stop-on-copy”即可(stop前是2个“-”)

svn log --stop-on-copy http://svn1.spec-develop.com/cdrd/storage-boss/branches/jss_shared_20120703 

 

(7)合并分支到主干:

首先将主干代码检出到本地,然后查看分支版本提交日志,查看需要合并起始的版本号,如下

svn merge --dry-run -r8756:HEAD http://svn1.spec-develop.com/cdrd/storage-boss/branches/v_20120808/jss_shared 

--dry-run 表示假合并,并没有真正合并分支修改到新分支,如果要真做,删除该参数。最新版本可用“HEAD”表示。恢复旧版本,只要把版本次序倒过来。svn merge的原理是对比版本差异,然后把差异的内容应用、合并到本地工作拷贝中。高版本:低版本,相当于“相对于高版本,低版本删除或者修改了哪些内容”。

  

(8)解决冲突

当出现“svn up”下来的文件和本地的有冲突(即出现C状态)的时候,冲入如何解决呢? 

a,打开文件:vi bundle/war/src/webroot/META-INF/autoconf/log4j.xml 

b,你会发现有这么3个标识: 

<<<<<<< .mine 

======= 

>>>>>>> .r250702 

另外还有3个文件: 

?       bundle/war/src/webroot/META-INF/autoconf/log4j.xml.r250274 

?       bundle/war/src/webroot/META-INF/autoconf/log4j.xml.mine 

?       bundle/war/src/webroot/META-INF/autoconf/log4j.xml.r250702 

以上意思是:“<<<<<<< .mine”和“=======”之间的是你本地添加到内容。“=======”和“>>>>>>> .r250702”部分的就是svn up下来的内容。 

c,捞出修改这部分代码的开发,跟他一起确认如何解决冲突。 

d,当确认了解决方案,解决了冲突,就删除类似以上那3个标识。 

最后:

svn resovled bundle/war/src/webroot/META-INF/autoconf/log4j.xml 

冲突解决。你会发现上面的3个文件不翼而飞了。 


 

4、最佳实践 

•   所有项目放在一个版本库中

•   每个项目创建自己的目录,其下各自创建trunk,branches和tags三个目录

•   trunk目录存放开发主线

•   branches目录存放分支拷贝

•   tags目录存放标签拷贝

•  开发和bug修正均每日提交到主干上

•  将测试的版本拷贝到测试分支。如/branches/1.0

•  并行工作,测试组对测试分支进行测试,开发组在主干上继续工作

•  如果一个bug在任何一个位置被发现,错误在主干上修正,然合并到分支上

•  测试结束,/branches/1.0拷贝到/tags/1.0.0,发布给客户

•  发布后的bug修正继续提交到主干上,并从主干合并到/branches/1.0

•  当积累了足够的bug修正,拷贝/branches/1.0到/tags/1.0.1,发布版本1.0.1

•  主干的2.0开发完成,一个新的2.0分支被创建,测试、打标签和最终发布

•  经过许多年,版本库结束了许多版本发布,进入了“维护”模式,许多标签代表了最终的发布版本

•   使用分支进行特性开发

•  特性开发是使用分支进行组件独立开发,最终合并的方式

•  开发周期一般为折衷模式。如果工作独立性较强,修改量较大,应该使用特性分支

•  应每周一次从主干合并更新到分支,以防止与主干差异性过大

 

 


 

5、常见错误

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值