你已经阅读过了关于工作副本的内容，现在我们要讲一讲客户端怎样建立和使用它。
一个 Subversion 工作副本是你本地机器一个普通的目录，保存着一些文件，你可以任意的编辑文件，而且如果是源代码文件，你可以像平常一样编译，你的工作副本是你的私有工作区，在你明确的做了特定操作之前，Subversion 不会把你的修改与其他人的合并，也不会把你的修改展示给别人。
当你在工作副本作了一些修改并且确认它们工作正常之后，Subversion 提供了一个命令可以“发布”你的修改给项目中的其他人(通过写到版本库)，如果别人发布了各自的修改，Subversion 提供了手段可以把这些修改与你的工作目录进行合并(通过读取版本库)。
一个工作副本也包括一些由 Subversion 创建并维护的额外文件，用来协助执行这些命令。通常情况下，你的工作副本每一个文件夹有一个以 .svn 为名的文件夹，也被叫做工作副本管理目录，这个目录里的文件能够帮助 Subversion 识别哪一个文件做过修改，哪一个文件相对于别人的工作已经过期了。
一个典型的 Subversion 的版本库经常包含许多项目的文件(或者说源代码)，通常每一个项目都是版本库的子目录，在这种安排下，一个用户的工作副本往往对应版本库的的一个子目录。
举一个例子，你的版本库包含两个软件项目。
换句话说，版本库的根目录包含两个子目录: paint 和 calc。
为了得到一个工作副本，你必须检出版本库的一个子树，(术语“检出”听起来像是锁定或者保留资源，实际上不是，它只是简单的得到一个项目的私有副本)。
![[警告]](images/warning.png) | 警告 |
|---|---|
不要创建和访问网络共享上的 Berkeley DB 版本库，它不能存在于一个远程的文件系统，即使是映射到盘符的共享。如果你希望在网络共享使用 Berkeley DB，结果难以预料－你可能会立刻看到奇怪的错误，也有可能几个月之后才发现数据库已经损坏了。 |
假定你修改了 button.c，因为 .svn 目录记录着文件的修改日期和原始内容，Subversion 可以告诉你已经修改了文件，然而，在你明确告诉它之前，Subversion 不会将你的改变公开。将改变公开的操作被叫做提交(或者是检入)，它提交修改到版本库中。
发布你的修改给别人，可以使用 Subversion 的提交命令。
这时你对 button.c 的修改已经提交到了版本库，如果其他人取出了 /calc 的一个工作副本，他们会看到这个文件最新的版本。
设你有个合作者，Sally，她和你同时取出了 /calc 的一个工作副本，你提交了你对 button.c 的修改，Sally 的工作副本并没有改变，Subversion 只在用户要求的时候才改变工作副本。
要使项目最新，Sally 可以要求 Subversion 更新她的工作副本，通过使用更新命令，可以将你和所有其他人在她上次更新之后的修改合并到她的工作副本。
注意，Sally 不必指定要更新的文件，Subversion 利用 .svn 以及版本库的进一步信息决定哪些文件需要更新。
一个 svn commit 操作可以作为一个原子事务操作发布任意数量文件和目录的修改，在你的工作副本里，你可以改变文件内容、删除、改名和复制文件和目录，然后作为一个整体提交。
在版本库中，每次提交被当作一次原子事务操作: 要么所有的改变发生，要么都不发生，Subversion 努力保持原子性以应对程序错误、系统错误、网络问题和其他用户行为。
每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做版本，每个版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是 0，只创建了一个空目录，没有任何内容。
可以形象的把版本库看作一系列树，想象有一组版本号，从 0 开始，从左到右，每一个修订号有一个目录树挂在它下面，每一个树好像是一次提交后的版本库“快照”。
需要特别注意的是，工作副本并不一定对应版本库中的单一版本，他们可能包含多个版本的文件。举个例子，你从版本库检出一个工作副本，最新的版本是 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 来更新你的工作副本，你会看到:
calc/Makefile:6
integer.c:6
button.c:6
Sally 对 integer.c 的改变会出现在你的工作副本，你对 button.c 的改变还在，在这个例子里，Makefile 在 4、5、6 版本都是一样的，但是 Subversion 会把 Makefile 的版本设为 6 来表明它是最新的，所以你在工作副本顶级目录作一次干净的更新，会使所有内容对应版本库的同一修订版本。
对于工作副本的每一个文件，Subversion 在管理目录 .svn/ 记录两项关键的信息:
工作文件的基准版本(叫做文件的工作版本)和
一个本地副本最后更新的时间戳。
给定这些信息，通过与版本库通讯，Subversion 可以告诉我们工作文件是处与如下四种状态的那一种:
- 未修改且是当前的
文件在工作目录里没有修改，在工作版本之后没有修改提交到版本库。svn commit 操作不做任何事情，svn update 不做任何事情。
- 本地已修改且是当前的
工作副本已经修改，从基准版本之后没有修改提交到版本库。本地修改没有提交，因此 svn commit 会成功的提交，svn update 不做任何事情。
- 本地未修改且过时
这个文件在工作副本没有修改，但在版本库中已经修改了。这个文件应当更新到最新公共版本。svn commit 不做任何事情，svn update 将会更新工作副本到最新的版本。
- 本地已修改且过时
这个文件在工作副本和版本库都被修改。svn commit 将会失败，这个文件必须首先更新，svn update 命令会合并公共和本地修改，如果 Subversion 不能自动完成，将会让用户解决冲突。