### 网络模型 这部分是讨论了Subversion客户端和服务器怎样互相交流，不考虑具体使用的网络实现，通过阅读，你会很好的理解服务器的行为方式和多种客户端与之响应的配置方式。 ### 请求和响应 Subversion客户端花费大量的时间来管理工作拷贝，当它需要版本库信息，它会做一个网络请求，然后服务器给一个恰当的回答，具体的网络协议细节对用户不可见，客户端尝试去访问一个URL，根据URL模式的不同，会使用特定的协议与服务器联系（见[版本库的URL]( "版本库的URL")），用户可以运行**svn --version**来查看客户端可以使用的URL模式和协议。 当服务器处理一个客户端请求，它通常会要求客户端确定它自己的身份，它会发出一个认证请求给客户端，而客户端通过提供*凭证*给服务器作为响应，一旦认证结束，服务器会响应客户端最初请求的信息。注意这个系统与CVS之类的系统不一样，它们会在请求之前，预先提供凭证（“logs in”）给服务器，在Subversion里，服务器通过请求客户端适时地“拖入”凭证，而不是客户端“推”出。这使得这种操作更加的优雅，例如，如果一个服务器配置为世界上的任何人都可以读取版本库，在客户使用**svn checkout**时，服务器永远不会发起一个认证请求。 如果客户端请求往版本库写入新的数据（例如**svn commit**），这会建立新的修订版本树，如果客户端的请求是经过认证的，认证过的用户的用户名就会作为`svn:author`属性的值保存到新的修订本里（见[“未受版本控制的属性”一节]( "未受版本控制的属性")）。如果客户端没有经过认证（换句话说，服务器没有发起过认证请求），这时修订本的`svn:author`的值是空的。 ### 客户端凭证缓存 许多服务器配置为在每次请求时要求认证，这对一次次输入用户名和密码的用户来说是非常恼人的事情。 令人高兴的是，Subversion客户端对此有一个修补：存在一个在磁盘上保存认证凭证缓存的系统，缺省情况下，当一个命令行客户端成功的在服务器上得到认证，它会保存一个认证文件到用户的私有运行配置区―类Unix系统下会在`~/.subversion/auth/`，Windows下在`%APPDATA%/Subversion/auth/`（运行区在[“运行配置区”一节]( "运行配置区")会有更多细节描述）。成功的凭证会缓存在磁盘，以主机名、端口和认证域的组合作为唯一性区别。 当客户端接收到一个认证请求，它会首先查找磁盘中的认证凭证缓存，如果没有发现，或者是缓存的凭证认证失败，客户端会提示用户需要这些信息。 十分关心安全的人们一定会想“把密码缓存在磁盘？太可怕了，永远不要这样做！”但是请保持冷静，首先，`auth/`是访问保护的，只有用户（拥有者）可以读取这些数据，不是整个世界，如果这对你还不够安全，你可以关闭凭证缓存，只需要一个简单的命令，使用参数`--no-auth-cache`： ~~~ $ svn commit -F log_msg.txt --no-auth-cache Authentication realm: <svn://host.example.com:3690> example realm Username: joe Password for 'joe': Adding newfile Transmitting file data . Committed revision 2324. # password was not cached, so a second commit still prompts us $ svn delete newfile $ svn commit -F new_msg.txt Authentication realm: <svn://host.example.com:3690> example realm Username: joe [...] ~~~ 或许，你希望永远关闭凭证缓存，你可以编辑你的运行`配置`文件（坐落在`auth/`目录），只需要把`store-auth-creds`设置为`no`，这样就不会有凭证缓存在磁盘。 ~~~ [auth] store-auth-creds = no ~~~ 有时候，用户希望从磁盘缓存删除特定的凭证，为此你可以浏览到`auth/`区域，删除特定的缓存文件，凭证都是作为一个单独的文件缓存，如果你打开每一个文件，你会看到键和值，`svn:realmstring`描述了这个文件关联的特定服务器的域： ~~~ $ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 joe K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domain.com:443> Joe's repository END ~~~ 一旦你定位了正确的缓存文件，只需要删除它。 客户端认证的行为的最后一点：对使用`--username`和`--password`选项的一点说明，许多客户端和子命令接受这个选项，但是要明白使用这个选项*不会*主动地发送凭证信息到服务器，就像前面讨论过的，服务器会在需要的时候才会从客户端“拖”入凭证，客户端不会随意“推”出。如果一个用户名和/或者密码作为选项传入，它们*只会*在服务器需要时展现给服务器。通常，只有在如下情况下才会使用这些选项： - 用户希望使用与登陆系统不同的名字认证，或者 - 一段不希望使用缓存凭证但需要认证的脚本 这里是Subversion客户端在收到认证请求的时候的行为方式： 1. 检查用户是否通过`--username`和/或`--password`命令选项指定了任何凭证信息，如果没有，或者这些选项没有认证成功，然后 1. 查找运行中的`auth/`区域保存的服务器域信息，来确定用户是否已经有了恰当的认证缓存，如果没有，或者缓存凭证认证失败，然后 1. 提示用户输入。 如果客户端通过以上的任何一种方式成功认证，它会尝试在磁盘缓存凭证（除非用户已经关闭了这种行为方式，在前面提到过。） 这个问题实际上是一个FAQ，源自错误的服务器配置。 再次重申，一个常见的错误是把服务器配置为从不会请求认证，当用户传递`--username`和`--password`给客户端时，他们惊奇的发现它们没有被使用，如新的修订版本看起来始终是由匿名用户提交的！