SVN note2

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

• $ svn checkouthttp://host/path%20with%20space/project/espa%C3%B1a

• 如果 URL包含空格,一定要使用引号,这样你的脚本才会把它做一个单独的svn参数。

• 举个例⼦子,你从版本库检出⼀一个⼯工作副本,最近的修订号是4:

• calc/Makefile:4

• integer.c:4

• button.c:4 此刻,⼯工作⽬目录与版本库的修订版本4完全对应,然⽽而,你修改了button.c并且提交之后,

• 假设没有别的提交出现,你的提交会在版本库建⽴立修订版本5,你的⼯工作副本会是这个样⼦子的:

• calc/Makefile:4

• integer.c:4

• button.c:5

• 假设此刻,Sally提交了对integer.c的修改,建⽴立修订版本6,如果你使⽤用svn update来 更新你的⼯工作副

本,你会看到:•11

• 基本概念

• calc/Makefile:6

• integer.c:6

• button.c:6

•･ Sally 对integer.c的改变会出现在你的⼯工作副本,你对button.c的改变还在,在这个例 ⼦子
⾥里,Makefile在4, 5, 6 的修订版本都是⼀一样的,但是Subversion会把他的Makefile的修订 号设为6 来表明它是最新的,所以你在⼯工作副本顶级⽬目录作⼀一次⼲干净的更新,会使得所有内容对应 版本库的同⼀一修订版本。

• • 本地副本最近⼀一次被版本库更新的时间戳。

• 给定这些信息,通过与版本库通讯,Subversion可以告诉

  我们⼯工作⽂文件是处于如下四种状态的 那⼀一种:

• 未修改且是当前的⽂文件在⼯工作⽬目录⾥里没有修改,在⼯工作

  版本之后没有修改提交到版本库。svn commit操作不

  做 任何事情,svn update不做任何事情。

• 本地已修改且是当前的 在⼯工作⽬目录已经修改,从基本修

  订版本之后没有修改提交到版本库。本地修改没有提交,因此svn commit会成功提交,svn update不做任何事情。

• 本地未修改,已过时 这个⽂文件在⼯工作⽬目录没有修改,但

在版本库中已经修改了。这个⽂文件最终将更新到最新版本,成为当时的公共修订版本。svn commit不做任何事情,svn update将会取得最新的版本到⼯工 作副本。

•･ 本地已修改,已过时这个⽂文件在⼯工作⽬目录和版本库都得到修改。⼀一个svn commit将会失败,这个⽂文件必须⾸首先更 新,svn update 命令会合并公共和本地修改,如果Subversion不可以⾃自动完成,将会让⽤用户解 决冲突。

• 尽管 Subversion 的灵活性允许你⾃自由布局版本库,但我们有⼀一套推荐的⽅方式,创建⼀一个trunk

• ⽬目录来保存开发的“主线”,⼀一个branches⽬目录存放分⽀支拷贝,tags⽬目录保存标签拷贝,例如:16

  •

• 基本使⽤用

  • $ svn list file:///var/svn/repos• /trunk
  • /branches
  • /tags

  Subversion 努⼒力不限制版本控制的数据类型。⽂文件的内容和属性值都是按照⼆二进制数据存储 和传递

  拷贝-修改-合并模型,在这种模型⾥里,每⼀一个客户 联系项⽬目版本库建⽴立⼀一个个⼈人⼯工作副本—版本库中⽂文件和⽬目录的本地

映射。⽤用户并⾏行⼯工作,修改各 ⾃自的⼯工作副本,最终,各个私有的拷贝合并在⼀一起,成为最终的版本,这种系统通常可以辅助合并 操作,但是最终要靠⼈人⼯工去确定正误。

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

在某个命令中关闭密码缓存,可以使⽤用--no-auth-cache选项,如果希望永久关闭缓存,可以在本机Subversion的配置⽂文件中增加store-passwords = no这⼀一⾏行

1. 更新你的⼯工作副本。•svn update

2. 做出修改•svn add

• svn delete•svn copy
• svn move

3.

••

检验修改

svn statussvn diff

5.

••

可能会取消⼀一些修改解决冲突(合并别⼈人的修改)

svn updatesvn resolve

4.
• svn revert

提交你的修改

6.
• svn commit

你可通过命令svn status浏览所做的修改,通过命令svndiff检查修改的详细信息。

以下的例⼦子是来展⽰示svn status可能返回的状态代码(注意#之后的内容不是svn status打印的信息)。

?ACDM

scratch.cstuff/loot/bloo.hstuff/loot/lump.cstuff/fish.c

bar.c
# file is not under version control

# file is scheduled for addition

# file has textual conflicts from anupdate

# file is scheduled for deletion# the content in bar.c has localmodifications

在这种输出格式中,svn status打印6 列字符,紧跟⼀一些空格,接着是⽂文件或⽬目录名。第⼀一列告诉 ⽂文件或⽬目录的状态或它的内容。返回代码如下:

A item 预定加⼊入到版本库的⽂文件,⽬目录或符号链的item。

C item ⽂文件 item 发⽣生了冲突。从服务器收到的修改与⼯工作副本的本地修改发⽣生交迭(在更新期间不会 被解决)。在你提交到版本库前,必须⼿手⼯工解决冲突。

D item ⽂文件,⽬目录或是符号链item预定从版本库中删除。M item ⽂文件item的内容被修改了。 

svn revert item 与删除item,然后执行svn update -r BASE item 的效果完全一样。但是,如果你使用svn revert 有个显著的特点—它不必连接版本库就可以恢复文件。

如果你只是希望检查一个过去的版本而不希望察看它们的区别,使用svn cat:

svn list可以在不下载文件到本地目录的情况下来察看目录中的文件

事实上,svn diff有三种不同的用法:

 • 检查本地修改

• 比较工作副本与版本库 

• 比较版本库中的版本

?  匹配任意单个字符

* 匹配任意字符串,包括空字符串