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 |
将目录导入代码库。 |
客户端使用的主要工作流程:
- 日常使用,开发者最常使用的模式。其使用流程:
![](images/o_main.JPG)
- 分支管理,使用分支的主要场合:release和个人试验(如大规模的修改前)。对于前者,有必要一直存在;后者,则在实验完毕后不需要存在。在subversion中,没有明显的分支(或tag)概念,取而代之的是目录。这一点,与以前没有版本控制工具前的做法非常类似,即在修改前先复制到指定的目录,然后在进行后续的更新。使用目录来代替显式的分支(或tag),获得了概念上的简单,以及操作上的直观。同时还享受到了分支(或tag)带来的种种好处。建议在开始项目目录规划时就考虑分支(或tag),Subversion建议的目录结构:
|
形式1: |
形式2: |
主目录 |
/trunk |
/project-name/trunk |
分支目录 |
/branches |
/project-name/branches |
tag目录 |
/tags |
/project-name/tags |
使用分支的流程:
![](images/o_brach.JPG)
客户端使用检查表:
-
保证是在最新的版本下进行开发,在工作之前首先与代码库同步。
-
当工作完成之后(即编写完程序,单元测试通过)尽快的提交,频繁的提交/更新可以降低在冲突发生的概率,以及发生时解决冲突的复杂度。
-
如果冲突频繁发生,就有必要找出原因了。
-
在提交时,书写明确的message。方便以后的查找更新的原因,毕竟随着时光流逝,记忆也会变得模糊。
-
分支结构不要太复杂,在创建branch时,确保repository是最新的。
-
在release临近时,建立release分支和小组。稳定release分支,不再添加新的特性。
|