\chardef\kindofpagetextareas\plusone
\enableregime[utf]
\setuplayout[middle]
\setupcolors[state=start]
\usetypescript[palatino][ec]
\setupbodyfont[palatino,11pt]

\setupwhitespace[medium]

% needed to activate the buggy stuff...
\definetextbackground[listing][background=color]

\starttext
appropriate moment, rather than
        the client \quotation{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 {\bf svn
        checkout}.

If the client's network request writes new data to the
        repository (e.g. {\bf svn commit}), then a new
        revision tree is created.  If the client's request was
        authenticated, then the authenticated user's name is stored as
        the value of the \type{svn:author} property on the
        new revision (see \in{Section}[svn.reposadmin.basics.revprops]).  If
        the client was not authenticated (in other words, the server
        never issued an authentication challenge), then the revision's
        \type{svn:author} property is empty.
        \footnote{
This problem is actually a FAQ, resulting from
        a misconfigured server setup.
}

\subsection[svn.serverconfig.netmodel.credcache]{Client Credentials Caching}

Many servers are configured to require authentication on
        every request.  This can become a big annoyance to users, who
        are forced to type their passwords over and over again.

Happily, 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—in {\tt ~/.subversion/auth/} on
        Unix-{}like systems or
        {\tt \%APPDATA\%/Subversion/auth/} on Windows.
        (The runtime area is covered in more detail in \in{Section}[svn.advanced.confarea].)  Successful credentials are
        cached on disk, keyed on a combination of hostname, port, and
        authentication realm.

When the client receives an authentication challenge, it
        first looks for the appropriate credentials in the user's disk
        cache; if not present, or if the cached credentials fail to
        authenticate, then the client simply prompts the user for the
        information.

Security-{}conscious people may be thinking to themselves,
        \quotation{Caching passwords on disk?  That's terrible!  You
        should never do that!} Please remain calm, it's not as
        dangerous as it sounds.
\startitemize
\item\relax The {\tt auth/} caching area is
            permission-{}protected so that only the user (owner) can
            read data from it, not the world at large.  The operating
            system's own file permissions are protecting the
            password.
\item\relax On Windows 2000 and later, the Subversion client uses
            standard Windows cryptography services to encrypt the
            password on disk.  Because the encryption key is managed
            by Windows and is tied to the user's own login
            credentials, only the user can decrypt the cached
            password.  (Note: if the user's Windows account password
            is reset by an administrator, all of the cached passwords
            become undecipherable.  The Subversion client will behave
            as if they don't exist, prompting for passwords when
            required.)
\item\relax For the truly paranoid willing to sacrifice all
            convenience, it's possible to disable credential caching
            altogether.
\stopitemize

To disable caching for a single command, pass the
        {\tt -{}-{}no-{}auth-{}cache} option:

\stoptext
