When a client connects to an svnserve process, the following things happen:
The client selects a specific repository.
The server processes the repository's
conf/svnserve.conf file, and begins to
enforce any authentication and authorization policies it
Depending on the defined policies,
the client may be allowed to make requests anonymously, without ever receiving an authentication challenge, OR
the client may be challenged for authentication at any time, OR
if operating in “tunnel mode”, the client will declare itself to be already externally authenticated (typically by SSH).
The svnserve server, by default, only knows how to send a CRAM-MD5  authentication challenge. In essence, the server sends a small amount of data to the client. The client uses the MD5 hash algorithm to create a fingerprint of the data and password combined, then sends the fingerprint as a response. The server performs the same computation with the stored password to verify that the result is identical. At no point does the actual password travel over the network.
If your svnserve server was built with SASL, then it not only knows how to send CRAM-MD5 challenges, but likely knows a whole host of other authentication mechanisms. See the section called “Using svnserve with SASL” to configure SASL authentication and encryption.
It's also possible, of course, for the client to be externally authenticated via a tunnel agent, such as SSH. In that case, the server simply examines the user it's running as, and uses it as the authenticated username. For more on this, see the section called “Tunneling over SSH”.
As you've already guessed, a repository's
svnserve.conf file is the central
mechanism for controlling authentication and authorization
policies. The file has the same format as other configuration
files (see the section called “Runtime Configuration Area”): section names
are marked by square brackets (
]), comments begin with hashes
#), and each section contains
specific variables that can be set (
value). Let's walk through these files and learn how
to use them.
 See RFC 2195.