SVN 知识

最新推荐文章于 2020-09-10 16:02:31 发布

iteye_17758

最新推荐文章于 2020-09-10 16:02:31 发布

阅读量115

点赞数

文章标签： SVN subversion 工作项目管理 CVS

本文链接：https://blog.csdn.net/iteye_17758/article/details/81801205

版权

SVN基本使用

SVN 提供了一套非常 优 秀的版本控制方案。在 这 里我把官方的文档和自己 实际 使用中遇到的一些常 见的问题列在这 里，以后 还会陆续 更新。

版本控制有哪些方案

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

文件共享的问题

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

图 2.2. 需要避免的问题

锁定 - 修改 - 解锁方案

许多版本控制系统使用锁定 - 修改 - 解锁这种机制解决这种问题，在这样的模型里，在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前， Harry 要“锁定”住这个文件，锁定很像是从图书馆借一本书，如果 Harry 锁住这个文件， Sally 不能做任何修改，如果 Sally 想请求得到一个锁，版本库会拒绝这个请求。在 Harry 结束编辑并且放开这个锁之前，她只可以阅读文件。 Harry 解锁后，就要换班了， Sally 得到自己的轮换位置，锁定并且开始编辑这个文件。

图 2.3. 锁定 - 修改 - 解锁方案

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

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

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

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

复制 - 修改 - 合并方案

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

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

图 2.4. 复制 - 修改 - 合并方案

图 2.5. 复制 - 修改 - 合并方案 ( 续 )

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