| 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分支，不再添加新的特性。
| 
