在某些情况下，你需要理解Subversion客户端如何与服务器通讯。Subversion网络层是抽象的，意味着Subversion客户端不管其操作的对象都会使用相同的行为方式，不管是使用HTTP协议(http://)与Apache HTTP服务器通讯或是使用自定义Subversion协议(svn://)与svnserve通讯，基本的网络模型是相同的。在本小节，我们要解释网络模型基础，包括Subversion如何管理认证和授权信息。
Subversion客户端花费大量的时间来管理工作拷贝，当它需要远程版本库的信息，它会做一个网络请求，然后服务器给一个恰当的回答，具体的网络协议细节对用户不可见，客户端尝试去访问一个URL，根据URL模式的不同，会使用特定的协议与服务器联系(见版本库的URL)。
用户可以运行svn --version来查看客户端可以使用的URL模式和协议。
When the server process receives a client request, it often demands that the client identify itself. It issues an authentication challenge to the client, and the client responds by providing credentials back to the server. Once authentication is complete, the server responds with the original information that the client asked for. Notice that this system is different from systems such as CVS, where the client pre-emptively offers credentials (“logs in”) to the server before ever making a request. In Subversion, the server “pulls” credentials by challenging the client at the appropriate moment, rather than the client “pushing” them. This makes certain operations more elegant. For example, if a server is configured to allow anyone in the world to read a repository, then the server will never issue an authentication challenge when a client attempts to svn checkout.
If the particular network requests issued by the client
result in a new revision being created in the repository,
(e.g., svn commit), then Subversion uses the
authenticated username associated with those requests as the
author of the revision. That is, the authenticated user's
name is stored as the value of the
svn:author property on the new revision
(see “Subversion Properties”一节). If
the client was not authenticated (in other words, if the server
never issued an authentication challenge), then the revision's
svn:author property is empty.
Many servers are configured to require authentication on
every request. This would be a big annoyance to users if
they were forced to type their passwords over and over again.
Fortunately, the Subversion client has a remedy for
this—a built-in system for caching authentication
credentials on disk. By default, whenever the command-line
client successfully responds to a server's authentication
challenge, it saves the credentials in the user's private
runtime configuration area
(~/.subversion/auth/ on Unix-like systems
or %APPDATA%/Subversion/auth/ on Windows;
see “运行配置区”一节 for more details
about the runtime configuration system). Successful
credentials are cached on disk and keyed on a combination of the
server's hostname, port, and authentication realm.
当客户端接收到一个认证请求，它会首先查找用户磁盘中的认证凭证缓存，如果没有发现，或者是缓存的凭证认证失败，客户端会提示用户提供需要的信息。
十分关心安全的人们一定会想“把密码缓存在磁盘？太可怕了，永远不要这样做！”
Subversion开发者认识到这种关注的正确性，所以Subversion使用操作系统和环境提供的机制来减少泄露这些信息的风险，下面是在大多数平台上这种含义的列表：
在Windows 2000或更新的系统上，Subversion客户端使用标准Windows加密服务来加密磁盘上的密码。因为加密密钥是Windows管理的，与用户的登陆凭证相关，只有用户可以解密密码。(注意：如果用户的Windows账户密码被管理员重置，所有的缓存密码就不可以解密了，此时Subversion客户端就会当它们根本不存在，在需要时继续询问密码。)
类似的，在Mac OS X，Subversion客户端在登陆keyring(使用Keychain管理)保存了所有的版本库密码，使用户用帐号密码保护。用户选择的设置可以强加额外的政策，例如在需要用户密码时要求输入用户帐号密码。
对于其他类Unix系统，没有标准的加密服务。然而auth/缓存区只有用户(拥有者)可以访问，而不是全世界都可以，操作系统的访问许可可以保护密码文件。
当然，对于真正的妄想狂，没有任何机制是完美的。这类人希望用无限的安全来牺牲便利性，Subversion提供了各种方法来完全关闭凭证缓存。
你可以关闭凭证缓存，只需要一个简单的命令，使用参数--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 …
Or, if you want to disable credential caching permanently,
you can edit the config file in your
runtime configuration area and set the
store-auth-creds option to
no. This will prevent the storing of
credentials used in any Subversion interactions you perform on
the affected computer. This can be extended to cover all
users on the computer, too, by modifying the system-wide
runtime configuration area (described in “配置区布局”一节).
[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 <http://svn.domain.com:443> Joe's repository END
一旦你定位了正确的缓存文件，只需要删除它。
One last word about svn's
authentication behavior, specifically regarding the
--username and --password
options. Many client subcommands accept these options, but it
is important to understand using these options does
not automatically send credentials to the
server. As discussed earlier, the server “pulls”
credentials from the client when it deems necessary; the
client cannot “push” them at will. If a username
and/or password are passed as options, they will only be
presented to the server if the server requests them. These
options are typically used to authenticate as a different user
than Subversion would have chosen by default (such as your
system login name) or when trying to avoid interactive
prompting (such as when calling svn from a
script).
A common mistake is to misconfigure a server so
that it never issues an authentication challenge. When
users pass --username and
--password options to the client, they're
surprised to see that they're never used; i.e., new
revisions still appear to have been committed
anonymously!
这里是Subversion客户端在收到认证请求的时候的行为方式最终总结：
First, the client checks whether the user specified
any credentials as command-line options
(--username and/or
--password). If so, the client will try
to use those credentials to authenticate against the
server.
If no command-line credentials were provided, or the
provided ones were invalid, the client looks up the server's
hostname, port, and realm in the runtime configuration's
auth/ area, to see if appropriate
credentials are cached there. If so, it attempts to use
those credentials to authenticate.
Finally, if the previous mechanisms failed to
successfully authenticate the user against the server, the
client resorts to interactively prompting the user for
valid credentials (unless instructed not to do so via the
--non-interactive option or its
client-specific equivalents).
If the client successfully authenticates by any of these methods, it will attempt to cache the credentials on disk (unless the user has disabled this behavior, as mentioned earlier).