Developing applications against the Subversion library APIs
is fairly straightforward. Subversion is primarily a set of C
libraries, with header (.h) files that live in the
subversion/include directory of the source
tree. These headers are copied into your system locations (for
/usr/local/include) when you build
and install Subversion itself from source. These headers
represent the entirety of the functions and types meant to be
accessible by users of the Subversion libraries. The Subversion
developer community is meticulous about ensuring that the public
API is well-documented—refer directly to the header files
for that documentation.
When examining the public header files, the first thing you
might notice is that Subversion's datatypes and functions are
namespace protected. That is, every public Subversion symbol name begins
svn_, followed by a short code for the
library in which the symbol is defined (such as
fs, etc.), followed by a single underscore
_) and then the rest of the symbol name.
Semi-public functions (used among source files of a given
library but not by code outside that library, and found inside
the library directories themselves) differ from this naming
scheme in that instead of a single underscore after the library
code, they use a double underscore (
Functions that are private to a given source file have no
special prefixing, and are declared
Of course, a compiler isn't interested in these naming
conventions, but they help to clarify the scope of a given
function or datatype.
Another good source of information about programming against the Subversion APIs is the project's own hacking guidelines, which can be found at http://subversion.tigris.org/hacking.html. This document contains useful information which, while aimed at developers and would-be developers of Subversion itself, is equally applicable to folks developing against Subversion as a set of third-party libraries. 
 After all, Subversion uses Subversion's APIs, too.