Subversion简明手册--客户端使用
 

2009-05-15 作者:修行的武者 来源:修行的武者的blog

 

Subversion对于使用者来说,可以简单的视为“具有记忆功能的文件系统”,尤其是将“目录”这一概念纳入版本控制之后(这也是其他很多版本控制工具不具备的功能)。通过(目标,时间)这个坐标,唯一定位了处于Subversion控制下的对象,为了简单起见,采用的是(目标,修订号)。

与大多数版本控制工具不一样的是,在Subversion中,修订号是针对当前代码库中所有对象的(而不是针对特定对象的)包括:子目录、目录和文件。这样,修订号的实际意义也演变成:“对代码库的第几次提交”。

在了解使用流程之前,先看看客户端常用命令:

svn update

从代码库获取最新的版本到当前Work Copy。

svn checkout

从代码库取出版本,建立Work Copy。

svn add
svn delete
svn copy
svn move

当操作Work Copy时。这些命令不会马上对代码库发生作用,而是在svn commit之后代码库才会变化。

当命令是作用于非Work Copy(如url)时,代码库会立即反应这些命令的操作结果。

svn status
svn diff
svn revert

检查更新状态的命令,最好在每次提交之前都使用它们检查一下。

svn status用于检查Work Copy下所有更新的概况;

svn diff用于检查哪些部分进行了更新;

svn revert用于放弃更新,并使用.svn目录中的对应的副本覆盖。

svn merge
svn resolved

解决版本冲突的命令。在冲突解决之后,需要使用svn resolved来告诉subversion冲突解决,这样才能提交更新。冲突发生时,subversion会在Work Copy中保存所有的目标文件版本(上次更新版本、当前获取的版本,即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt,对应的文件名分别是:sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt)。同时在目标文件中标记来自不同用户的更改。

解决冲突的办法:

-手动解决:冲突发生时,通过和其他用户沟通之后,手动更新目标文件。然后执行svn resolved filename来解除冲突,最后提交。

- 放弃自己的更新,使用别人的更新。使用最新获取的版本覆盖目标文件,执行svn resolved filename并提交。

- 放弃自己的更新,使用svn revert,然后提交。在这种方式下不需要使用svn resolved。

对于svn resolved命令需要非常小心,必须是非常确定冲突已经解决才能使用。否则,会导致Subversion以为冲突解决,而使代码库不正确。

svn commit

提交更新到代码库中。

svn log

检查代码库日志,了解变动情况。

svn cat
svn list

显示代码库的目录结构和文件内容。

svn cleanup

清除锁定文档,这些文档通常是由于subversion的命令被中断引起的。

svn import

将目录导入代码库。

客户端使用的主要工作流程:

- 日常使用,开发者最常使用的模式。其使用流程:


 

-  分支管理,使用分支的主要场合:release和个人试验(如大规模的修改前)。对于前者,有必要一直存在;后者,则在实验完毕后不需要存在。在subversion中,没有明显的分支(或tag)概念,取而代之的是目录。这一点,与以前没有版本控制工具前的做法非常类似,即在修改前先复制到指定的目录,然后在进行后续的更新。使用目录来代替显式的分支(或tag),获得了概念上的简单,以及操作上的直观。同时还享受到了分支(或tag)带来的种种好处。建议在开始项目目录规划时就考虑分支(或tag),Subversion建议的目录结构:

  形式1: 形式2:
 主目录
/trunk /project-name/trunk
分支目录
/branches /project-name/branches
tag目录
/tags  /project-name/tags

使用分支的流程:

客户端使用检查表:

- 保证是在最新的版本下进行开发,在工作之前首先与代码库同步。

- 当工作完成之后(即编写完程序,单元测试通过)尽快的提交,频繁的提交/更新可以降低在冲突发生的概率,以及发生时解决冲突的复杂度。

- 如果冲突频繁发生,就有必要找出原因了。

- 在提交时,书写明确的message。方便以后的查找更新的原因,毕竟随着时光流逝,记忆也会变得模糊。

- 分支结构不要太复杂,在创建branch时,确保repository是最新的。

- 在release临近时,建立release分支和小组。稳定release分支,不再添加新的特性。


火龙果软件/UML软件工程组织致力于提高您的软件工程实践能力,我们不断地吸取业界的宝贵经验,向您提供经过数百家企业验证的有效的工程技术实践经验,同时关注最新的理论进展,帮助您“领跑您所在行业的软件世界”。
资源网站: UML软件工程组织