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
| 将目录导入代码库 |
转自:http://hi.baidu.com/jobs_lee/blog/item/1bc29dc498d6f9aa8326ac17.html/cmtid/7998db4bf0f9cbf483025cae