│样式                 存取方式
     file:///              直接从本地磁盘上访问仓库
     http://               通过 WebDAV 协议访问 Apache 服务器，进而访问仓库
     https://              和 http:// 相同，但使用 SSL 来作加密
     svn://                通过自定义的协议访问一个 svnserve 服务器
     svn+ssh://            和 svn:// 相同，但通过一个 SSH 通道来使用

    很多情况下，Subversion 的 URLs 都使用标准的语法，并允许在 URL 中使用服务器名称和端口号。记住， file:// 方式只在本地服务器上有效。也就是说客户端和服务器在同一台机器上的情况。事实上，按照惯例，在 URL 中的服务器名称必须是空的或者是 localhost：

    $ svn checkout file:///path/to/repos
    ......
    $ svn checkout file://localhost/path/to/repos
    ......

    同样，在 Windows 平台上使用 file:// 方式时，也需要使用一种非官方的"标准语法"来存取本地的仓库。除非是仓库和客户端不在同一个驱动器上。下面两种 URL 语法都可以正确工作。假设 X 是仓库所在的驱动器。

    C:\> svn checkout file:///X:/path/to/repos
    ......
    C:\> svn checkout "file:///X|/path/to/repos"
    ......

    在第二种语法中，你必须使用引号来标记一下，以防止 '|' 被当作管道命令。
    注意：这里的 URL 使用斜杠 '/' 而不是反斜杠 '\' 。
    （结束）

    假设你对 button.c 文件作了修改。由于 .svn 目录中记录了文件的修改日期和原始内容，Subversion 可以指出你已经修改了文件。但是，如果你不明确声明，Subversion 不会自作主张去把这些修改发布。发布修改的动作通常叫做"提交"（committing or checking in）修改到仓库。
    你可以使用 Subversion 的 commit 命令来发布修改：

    $ svn commit button.c
    Sending        button.c
    Transmitting file data .
    Committed revision 57.

    这样，你对 button.c 文件的修改就提交到仓库了；如果其他用户 check out 了一份 /calc 的工作副本，他们就会在最新版本的文件里看到你做的修改了。
    假如你有一个协作开发者 Sally 。她和你同时 check out 了 /calc 目录的工作副本。当你提交你对 button.c 的修改后，Sally 的工作副本就变成了旧的了；Subversion 只有在用户请求时才会更新本地工作副本。
    如果 Sally 想让她的项目保持更新，她可以使用 update 命令来请求 Subversion 更新她的本地工作副本。这样，你的修改将会合并到她的工作副本，当然还有在她签出（check out）期间其他人所作的修改。

    $ pwd
    /home/sally/calc

    $ ls -A
    .svn/    Makefile    integer.c    button.c

    $ svn update
    U button.c

    执行 svn update 时候的输出内容表明 Subversion 更新了 button.c 的内容。Sally 并不需要指定更新哪个文件；Subversion 根据 .svn 目录以及仓库中的信息来决定哪些文件将被更新。

2.3.2 修订本

    一个 svn commit 操作可以将任意数量的文件和目录的修改发布作为一个单独的原子事务来处理。在你的工作副本中，你可以修改文件内容，创建、删除、重命名以及复制文件和目录，然后作为一个单独的单元来提交所有这些修改。
    在仓库中，每一次提交都被作为一个原子事务来对待：要么所有的提交都成功执行，要么什么都不发生。Subversion 试图在面对程序崩溃、系统崩溃、网络问题和其他用户的动作时保留这种原子性。
    每当仓库接受一次提交，仓库中的文件系统目录都会创建一种新的状态，叫做一个修订本。每一个修订本都被赋予一个唯一的自然数，并且每一个修订本的数字都比前一个要大。刚刚建立的仓库的初始的版本是 0 ，只包含一个空的根目录。
    图2.7 "仓库"是一个仓库的想象图。设想一个修订版编号的数列，从 0 开始，从左延伸到右。每一个修订版编号都对应一个画下面的目录树，而每一个目录树就是在每一次提交之后的仓库的"快照"。

    图2.7

    （表格开始）
    全局修订本编号：
    Subversion 的修订版编号是针对整个目录树的，而不是某一个独立的文件。这与其他许多的版本控制系统不同。每一个修订版编号都代表了仓库中一个树在某次提交后的一个特定状态。从另一个角度来讲，修订版 N 表示经过了 N 提交之后的仓库目录树。如果某人说"文件 foo.c 的 revision 5"，那么应该理解为"在项目的 revision 5 中看到的 foo.c 文件"。值得注意的事，通常 revisions N 和 revisions M 的某个文件并不一定非得是不同的。由于 CVS 使用每一个文件一个修订版编号的方式，CVS 的用户请阅读附录A Subversion for CVS Users。