SVN是Subversion(版本控制系统)的简称

工作副本

你的工作副本是你的私有工作区，每一个开发者在自己的电脑上都有属于自己的工作副本，有时可以将其理解为沙箱。在你明确的做了特定操作之前，Subversion 不会把你的修改与其他人的合并，也不会把你的修改展示给别人。你可以将最新的版本从版本库上取下来，在本地的副本上工作而不影响其他人，如果对更改满意就可以将其提交到版本库中。

当对工作副本中的文件做了一些更改并确认他们能够正常工作后，Subversion 提供将这些更改公布给同项目的其他人员的命令(通过写入版本库)。如果其他人公布他们的更改，Subversion 提供将这些更改合并到工作副本的命令(通过读取本版本库)。但Subversion 只在用户要求的时候才改变工作副本（你提交了你对 某文件的修改，Sally 的工作副本并没有改变，只在Sally要求的时候才改变）。

工作副本中的每一个文件的左下角都有一个绿色的对钩。它们只出现在工作副本中的 TortoiseSVN 状态图标。绿色的图标表示文件未被修改，和版本库中的文件版本一致。

注意，当你把一个文件夹导入到版本库这个过程并不能使刚才的文件夹变成一个工作副本！

版本库 repository

版本库通常位于运行 Subversion 服务器的文件服务器上，向 Subversion 客户端(例如TortoiseSVN)提供需要的数据。 版本库储存所有的数据，按照文件树形式储存数据－包括文件和目录，任意数量的客户端可以连接到版本库，读写这些文件。

还原（Revert）

如果你想抛弃还没有提交的更改并将文件复原到修改之前的状态：TortoiseSVN → Revert 。它抛弃了所做的更改(扔到回收站里)并复原到修改之前的版本。如果你想抛弃更改的一部分，可以使用 TortoiseMerge 来查看区别并有选择的复原被修改的文件行。

复制-修改-合并模型

Subversion 缺省使用复制-修改-合并模型

举例：Harry 和 Sally 参加同一个项目每人都有各自的工作副本，从同一个版本库复制出来的。他们同时工作，在自己的副本中修改同一个文件 A。Sally 先将她的更改保存到版本库中。 稍后，当 Harry 尝试提交他的更改时，版本库提示他的文件 A 已经过时。换句话说，自从他上次复制文件后，无论如何版本库中的文件 A 已经被修改了。所以 Harry 要用客户端程序将版本库中文件 A 的新更改 合并 到他的工作副本中。

1. 碰巧的是 Sally 的更改和他的不重合; 所以一旦他整合了两人的更改，他就可以把他的工作副本复制回版本库。
2. 但是如果 Sally 和 Harry 的修改重叠了该怎么办？这种情况叫做冲突，当Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件 A 就会处于冲突状态: 他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论)，他就可以安全的把合并的文件保存到版本库 。

更新（Update）

要使项目最新，用户可以要求 Subversion 更新她的工作副本，通过使用更新（Update）命令，可以将所有其他人的修改合并到她的工作副本。 注意，用户不必指定要更新的文件，Subversion 利用 .svn (管理目录 )以及版本库的进一步信息决定哪些文件需要更新。

版本库的 URL

URL 方案反映了访问方法。

方案	访问方法
file://	直接版本库访问(本地磁盘或者网络磁盘)。
http://	通过 WebDAV 协议访问支持 Subversion 的 Apache 服务器。
https://	与 http:// 相似，但是用 SSL 加密。
svn://	通过未认证的 TCP/IP 自定义协议访问 svnserve 服务器。
svn+ssh://	通过认证并加密的 TCP/IP 自定义协议访问 svnserve 服务器。

一般创建一个文件夹为版本库时弹出的对话框会提示路径，如：file:///C:\Users\Administrator\Desktop\SVN1

请注意，file: 后面始终有三个斜杠?

（对于大多数情况，Subversion 的 URL 使用标准格式，允许服务器名称和端口作为 URL 的一部分明确的指出来。files:// 访问方式一般用于本地访问，尽管它可以使用 UNC 路径（Universal Naming Convention）通用命名规则）来引用网络主机。因此 URL使用这种格式 file://hostname/path/to/repos。对于本机而言，URL 中的 hostname 部分必须省略或者使用 localhost。就是因为这个原因，本机路径通常含有 3 个斜线，file:///path/to/repos。 ）

Commit提交

在版本库中，每次提交被当作一次原子事务操作: 要么所有的改变发生，要么都不发生。

每当版本库接受了一个提交，文件系统进入了一个新的状态，叫做版本，每个版本被赋予一个独一无二的自然数，一个比一个大，初始修订号是 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 来表明它是最新的，所以你在工作副本顶级目录作一次干净的更新，会使所有内容对应版本库的同一修订版本。