You've seen how a repository can be accessed in many different ways. But is it possible—or safe—for your repository to be accessed by multiple methods simultaneously? The answer is yes, provided you use a bit of foresight.
At any given time, these processes may require read and write access to your repository:
Regular system users using a Subversion client (as
          themselves) to access the repository directly via
          file:// URLs
Regular system users connecting to SSH-spawned private svnserve processes (running as themselves), which access the repository
An svnserve process—either a daemon or one launched by inetd—running as a particular fixed user
An Apache httpd process, running as a particular fixed user
The most common problem administrators run into is
      repository ownership and permissions.  Does every process (or
      user) in the preceding list have the rights to read and write the
      repository's underlying data files?  Assuming you have a
      Unix-like operating system, a straightforward approach might be
      to place every potential repository user into a
      new svn group, and make the repository wholly
      owned by that group.  But even that's not enough, because a
      process may write to the database files using an unfriendly
      umask—one that prevents access by other users.
So the next step beyond setting up a common group for
      repository users is to force every repository-accessing process
      to use a sane umask.  For users accessing the repository
      directly, you can make the svn program into a
      wrapper script that first runs umask 002 and
      then runs the real svn client program.  You
      can write a similar wrapper script for the
      svnserve program, and add a umask
      002 command to Apache's own startup script,
      apachectl.  For example:
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/svn-real "$@"
Another common problem is often encountered on Unix-like
      systems.  If your repository is backed by Berkeley DB, for
      example, it occasionally creates new log files to journal its
      actions.  Even if the Berkeley DB repository is wholly owned by
      the svn group, these newly created log files
      won't necessarily be owned by that same group, which then
      creates more permissions problems for your users.  A good
      workaround is to set the group SUID bit on the
      repository's db directory.  This causes all
      newly created log files to have the same group owner as the
      parent directory.
Once you've jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write access to common files are classic ones that are not often elegantly solved.
Fortunately, most repository administrators will never
      need to have such a complex configuration.
      Users who wish to access repositories that live on the same
      machine are not limited to using file://
      access URLs—they can typically contact the Apache HTTP
      server or svnserve using
      localhost for the server name in their
      http:// or svn:// URL.
      And maintaining multiple server processes for your Subversion
      repositories is likely to be more of a headache than necessary.
      We recommend that you choose a single server that best meets your
      needs and stick with it!