课程表

SVN课程

工具箱
速查手册

SVN 基本概念

当前位置:免费教程 » 软件/图像 » SVN

SVN简介

Subversion(简称SVN)是近年来崛起的版本管理软件系统,是CVS的接班人。目前,绝大多数开源软件都使用SVN作为代码版本管理软件。

Subversion是一个版本控制系统,相对于的RCS、CVS,采用了分支管理系统,它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。

Subversion的版本库可以通过网络访问,从而使用户可以在不同的电脑上进行操作。从某种程度上来说,允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。因为修改不再是单线进行(单线进行也就是必须一个一个进行),开发进度会进展迅速。此外,由于所有的工作都已版本化,也就不必担心由于错误的更改而影响软件质量—如果出现不正确的更改,只要撤销那一次更改操作即可。某些版本控制系统本身也是软件配置管理系统(SCM),这种系统经过精巧的设计,专门用来管理源代码树,并且具备许多与软件开发有关的特性——比如对编程语言的支持或者提供程序构建工具。不过Subversion并不是这样的系统,它是一个通用系统,可以管理任何类型的文件集。


SVN功能

·包含绝大部分CVS的功能

CVS是最基本的版本控制系统。Subversion包含了CVS的大部分功能,并且针对有些功能还稍加改进。

·目录的版本化

Subversion将目录名以版本号的形式体现。

·基于版本的复制,删除和重命名

无论复制、删除还是重命名,都会被打上版本号,尽管这听上去有些奇怪。

·自由的版本化元数据操作

Subversion允许任何元数据附加在文件或目录中。这些属性是键/值对,并且被版本化。Subversion也提供对修订版附加任何键/值属性的方法,这些属性不会被版本化,因为他们会自动将元数据附加到版本空间中,但他们可以随时被更改。

·混合追踪

Subversion 1.5开始加入了混合追踪功能。

·文件锁

支持文件锁定,当多个用户试图编辑同一个文件时会收到警告。

·Apache网络服务的支持,基于WebDAV/DeltaV协议

使用基于HTTP的WebDAV/DeltaV协议进行网络通信,而Apache网络服务器提供网络存储的站点服务。

·可执行的标签

当一个文件是可执行的时候,Subversion会提示,并且当这个可执行的文件被放在版本控制中时,Subversion会防止该程序检查其他目录。

·独立进程模式

Subversion可以运行在独立模式下

·一个只读的存储镜像

Subversion提供一个工具,SVNsync, 用于同步主服务器上的 文件到一个子存储服务器上,并且标为只读的属性


SVN客户端

Subversion的客户端有两类,一类是WebSVN等基于Web的,一种是以TortoiseSVN为代表的客户端软件。前者需要Web服务器的支持,后者需要用户在本地安装客户端,两种都有免费开源软件供使用。

TortoiseSVN 是 Subversion 版本控制系统的一个免费开源客户端,可以超越时间的管理文件和目录。文件保存在中央版本库,除了能记住文件和目录的每次修改以外,版本库非常像普通的文件服务器。你可以将文件恢复到过去的版本,并且可以通过检查历史知道数据做了哪些修改,谁做的修改。


SVN基本概念

什么是版本控制系统(VCS)

版本控制系统 (VCS) 是一个软件,帮助软件开发人员团队工作并维持他们完整的工作历史。 下面是版本控制系统(VCS) 的目标

  • 允许开发者们同时工作
  • 不会重写每个人的改变
  • 维持每个版本的全部的历史

VCS 被分成两种

  • 集中版本控制系统 (CVCS) 和
  • 分散或不集中的版本控制系统 (DVCS)

在这个教程里,我们只专注于集中的版本控制系统特别是 Subversion,Subversion 基于集中的版本控制系统,意味着使用统一的服务器让团队协作。

版本控制的术语

让我们先懂得一些在这个教程将用到的术语

  • 仓库: 仓库是任何一个版本系统的核心,它是开发者们保存工作的总部,仓库不止处理文件还有历史记录,它需要访问网络,扮演服务器的角色,版本控制工具扮演客户端的角色,客户端可以连接仓库,那么他们就可以从仓库中存储或者提取。通过保存这些更改,一个客户端的更改可以被其他人检索到,一个客户端可以让其他人的更改作为一个工作副本。

  • 主干:trunk 是主要开发所在的目录,经常被项目开发者们查看。

  • 标签:tags 目录用于储存项目中被命名的快照,标签操作允许给予对仓库中特定版本一个描述和一个难忘的名字。比如,LAST_STABLE_CODE_BEFORE_EMAIL_SUPPORT 比 Repository UUID: 7ceef8cb-3799-40dd-a067-c216ec2e5247 和Revision: 13 更令人难忘。

  • 分支:分支操作用于创建开发的另一条线,当你想把开发进程复制进两个不同的方向是很有用的。比如,当你发布 5.0 版本时,你可能想从 5.0 的 bug 修复中分离出来创建一个开发 6.0 功能的分支。

  • 工作副本:工作副本是仓库的一个快照。这个仓库被所有的成员共享,但人们不直接修改它,相反每个开发者检查这个工作副本,工作副本是一个私人的工作空间,这里开发者可以独立于其他成员做自己的工作。

  • 提交更改:提交是一个保存更改的过程,从私人工作空间到中央服务器。提交后,更改对全部成员可用,通过更新工作副本其他开发者提取这些更改。提交是一个原子操作,要么全部提交成功要么回滚,用户绝不会看到一半完成提交。

先为那些不熟悉版本控制技术的入门者提供一个简单扼要、非系统的介绍,这里将从版本控制的基本概念开始,随后阐述Subversion的独特理念,并演示一些使用Subversion的例子。

下面以分享程序源代码作为例子,但是记住Subversion可以管理任何类型的文件集——它并非是程序员专用的。

版本库

一个典型的客户/服务器系统

Subversion是一个“集中式”的信息共享系统。版本库是Subversion的核心部分,是数据的中央仓库。版本库以典型的文件和目录结构形式的文件系统树来保存信息。任意数量的客户端连接到Subversion版本库,读取、修改这些文件。客户端通过写数据将信息分享给其他人,通过读取数据获取别人共享的信息。图“一个典型的客户/服务器系统”展示了这种系统:

Subversion听起来跟一般的文件服务器没什么不同。事实上,Subversion的版本库的确是一种文件服务器,但不是“一般”的文件服务器。Subversion版本库的特别之处在于,它会记录每一次改变:每个文件的改变,甚至是目录树本身的改变,例如文件和目录的添加、删除和重新组织。

一般情况下,客户端从版本库中获取的数据是文件系统树中的最新数据,但是客户端也具备查看文件系统树以前任何一个状态的能力。举个例子,客户端有时会对一些历史性问题感兴趣,比如“上星期三时的目录结构是什么样的?”或者“谁最后一个修改了这个文件,都修改了什么?”这些都是版本控制系统的核心问题(设计用来记录和跟踪数据变化的系统)。

版本模型

版本控制系统的核心任务是实现协作编辑和数据共享。但是不同的系统使用不同的策略实现这个目的。有理由去理解这些策略的区别,首先,如果遇到了其他类似Subversion的系统,可以帮助比较现有的版本控制系统;此外,可以帮助更有效的使用Subversion,因为Subversion本身支持不同的工作方式。

文件共享

所有的版本控制系统都需要解决这样一个基础问题:怎样让系统允许用户共享信息,而不会让他们因意外而互相干扰?在版本库里意外覆盖别人的更改非常容易。

注意事项

考虑“需要避免的问题”的情景,有两个共同工作者,Harry和Sally,他们想同时编辑版本库里的同一个文件,如果首先Harry保存它的修改,过了一会,Sally可能凑巧用自己的版本覆盖了这些文件,Harry的更改不会永远消失(因为系统记录了每次修改),但Harry所有的修改不会出现在Sally新版本的文件中,所以Harry的工作还是丢失了,至少是从最新的版本中丢失了,而且可能是意外的,这是要明确避免的情况!

锁定-修改-解锁方案

许多版本控制系统使用锁定-修改-解锁机制解决这种问题,在这样的模型里,在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前,Harry要“锁定”

住这个文件,锁定很像是从图书馆借一本书,如果Harry锁住这个文件,Sally不能做任何修改,如果Sally想请求得到一个锁,版本库会拒绝这个请求。在Harry结束编辑并且放开这个锁之前,她只可以阅读文件。Harry解锁后,就要换班了,Sally得到自己的轮换位置,锁定并且开始编辑这个文件。图1.3“锁定-修改-解锁方案”描述了这样的解决方案。

锁定-修改-解锁模型有一点问题就是限制太多,经常会成为用户的障碍:

1.锁定可能导致管理问题。有时候Harry会锁住文件然后忘了此事,这就是说Sally一直等待解锁来编辑这些文件,她在这里僵住了。然后Harry去旅行了,现在Sally只好去找管理员放开锁,这种情况会导致不必要的耽搁和时间浪费。

2.锁定可能导致不必要的线性化开发。如果Harry编辑一个文件的开始,Sally想编辑同一个文件的结尾,这种修改不会冲突,设想修改可以正确的合并到一起,他们可以轻松的并行工作而没有太多的坏处,没有必要让他们轮流工作。

3.锁定可能导致错误的安全状态。假设Harry锁定和编辑一个文件A,同时Sally锁定并编辑文件B,如果A和B互相依赖,这种变化是必须同时作的,这样A和B不能正确的工作了,锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象Harry和Sally都以为自己锁住了文件,而且从一个安全,孤立的情况开始工作,因而没有尽早发现他们不匹配的修改。锁定经常成为真正交流的替代品。

拷贝-修改-合并方案

Subversion、CVS和一些版本控制系统使用拷贝-修改-合并模型,在这种模型里,每一个客户联系项目版本库建立一个个人工作拷贝—版本库中文件和目录的本地映射。用户并行工作,修改各自的工作拷贝,最终,各个私有的拷贝合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误。

下面是一个例子,Harry和Sally为同一个项目各自建立了一个工作拷贝,工作是并行的,修改了同一个文件A,Sally首先保存修改到版本库,当Harry想去提交修改的时候,版本库提示文件A已经过期,换句话说,A在他上次更新之后已经更改了,所以当他通过客户端请求合并版本库和他的工作拷贝之后,碰巧Sally的修改和他的不冲突,所以一旦他把所有的修改集成到一起,他可以将工作拷贝保存到版本库。

但是如果Sally和Harry的修改交叠了怎么办?这种情况叫做冲突,这通常不是个大问题,当Harry告诉他的客户端去合并版本库的最新修改到自己的工作拷贝时,他的文件A就会处于冲突状态,他可以看到一对冲突的修改集,并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突,只有人可以理解并作出智能的选择,一旦Harry手工地解决了冲突——也许需要与Sally讨论,它可以安全地把合并的文件保存到版本库。

拷贝-修改-合并模型感觉有一点混乱,但在实践中,通常运行的很平稳,用户可以并行的工作,不必等待别人,当工作在同一个文件上时,也很少会有交叠发生,冲突并不频繁,处理冲突的时间远比等待解锁花费的时间少。

最后,一切都要归结到一条重要的因素:用户交流。当用户交流贫乏,语法和语义的冲突就会增加,没有系统可以强制用户进行完美的交流,没有系统可以检测语义上的冲突,所以没有任何证据能够承诺锁定系统就可以防止冲突,实践中,锁定除了约束了生产力,并没有做什么事。

什么时候锁定是必需的

锁定-修改-解锁模型被认为不利于协作,但有时候锁定会更好。

拷贝-修改-合并模型假定文件是可以根据上下文合并的,就是版本库的文件主要是以行为基础的文本文件(例如程序源代码)。但对于二进制格式,例如艺术品或声音,在这种情况下,十分有必要让用户轮流修改文件,如果没有线性的访问,有些人的许多工作就最终要被放弃。

尽管Subversion一直主要是一个拷贝-修改-合并系统,但是它也意识到了需要锁定一些文件,并且提供这种锁定机制。

转载本站内容时,请务必注明来自W3xue,违者必究。
 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号